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.

Security Evangelist at Gen

Malware Researcher

Staff Scientist, AI

Research

<p><strong>The deepfake story you think you know is incomplete.</strong>&nbsp;</p><p>When most people hear “deepfake,” they picture a fake face.&nbsp;</p><p>One important nuance: <strong>a deepfake face does not automatically mean a scam</strong>, and a scam does not even require a deepfake face at all. Visuals can be a useful clue, but <strong>identifying synthetic media is getting more complex</strong>, and simplistic “looks fake” judgments are increasingly unreliable. That is why we lean on <strong>multiple signals</strong>, including audio analysis and transcript, to reason about intent and behavior.&nbsp;</p><p>Connecting the term deepfake with deceit makes sense, it is the most visual part of the problem, and it has become a cultural shorthand for deception. But in real-world scam campaigns, the face is often just packaging. The engine is usually the message, including the script, the call to action, the pressure, and the promise.&nbsp;</p><p>That's why our detection starts where the persuasion lives: the content, especially the audio. Scam videos often reuse the same pitches, again and again, such as “guaranteed returns,” “limited-time access,” “you’ve been selected,” “act before it’s too late.” Even when the visuals look polished, even when the footage looks familiar, the audio can give away the intent.&nbsp;</p><p>As we continued our research on what makes a deepfake a scam, we started asking another question that changed what we looked for:&nbsp;</p><p><strong>Once a video is already labeled as scam content by our audio and content analysis, which faces keep showing up across those scam videos?</strong>&nbsp;</p><p>The answer was not only “famous people.”&nbsp;</p><p>It was actually a set of VIPs that do not exist.&nbsp;</p><h2>Why we looked for “VIPs” in scam video&nbsp;</h2><p>In scam ecosystems, repetition is rarely an accident. Criminals optimize what works, then scale it.&nbsp;</p><p>So instead of asking “who is this person?” we asked “how often does this face appear across scam-labeled videos, and where does it show up?” If the same presenter is repeatedly used as a delivery vehicle for scam scripts, that recurrence becomes a signal of reuse, coordination, and industrialization.&nbsp;</p><p>To do that, our proof of concept takes scam-labeled videos, extracts faces, generates compact visual descriptors, then groups them by similarity. The most prevalent identities in that scam-labeled set become “VIPs,” meaning faces that appear unusually often across scam content. We use faces here as an additional <strong>signal </strong>for grouping and speed, to connect related scam videos and spot scale. It complements audio and transcript analysis, it is not the primary factor deciding whether a video is a scam.&nbsp;</p><p>We expected the usual outcome: a list dominated by high-profile public figures that scammers frequently impersonate.&nbsp;</p><p>And yes, those faces are there. Public figures like Elon Musk have become recurring bait in investment-themed scams, giveaways, and “exclusive opportunity” narratives.&nbsp;</p><p>But the most important finding was what appeared alongside the celebrity targets.&nbsp;</p><h2>VIPs that don’t exist&nbsp;</h2><p>Some of the most prevalent “presenters” in scam video are not real people.&nbsp;</p><p>They look like ordinary talking-head hosts: friendly expression, neutral styling, camera-ready delivery. They speak clearly, they project confidence, and they often appear in exactly the kind of format people have learned to trust: a calm explainer, a “news-style” segment, a professional endorsement, a casual recommendation.&nbsp;</p><p>But they are AI avatars, synthetic presenters generated to be reused. To be clear, an AI avatar is not automatically a scam; what makes these specific presenters relevant is that we found them recurring inside videos already labeled as scams based on the message and behavior.&nbsp;</p><p>In general, proving that a person on screen is synthetic can require detailed and expensive analysis, things like lip-sync consistency, motion artifacts, and other forensic techniques. Our approach is different: we identify and aggregate recurring avatar identities from scam-labeled videos using lightweight visual descriptors and similarity grouping. That gives us a faster, cheaper way to recognize AI avatar presenters that are not yet “known,” but are already showing up frequently in the wild.&nbsp;</p><p>We are confident about this classification. These are not ambiguous “maybe enhanced” clips. They are AI avatar outputs, and we have also seen the supply chain behind them, including avatar creation services marketed openly on freelance marketplaces like Fiverr.&nbsp;</p><p>This matters because it changes the threat model.&nbsp;</p><p>If you only think about deepfakes as “someone impersonating a celebrity,” you miss the bigger shift: scammers are increasingly manufacturing credibility without impersonating anyone at all.&nbsp;</p><p>That might sound like a minor distinction, but it changes the incentives.&nbsp;</p><ul type="disc"><li data-list-item-id="e908326041bf0d633ca65ffb02170a711">A celebrity deepfake creates obvious controversy and is easier for platforms and victims to challenge.&nbsp;</li><li data-list-item-id="e3d8efe40c9161bf5c06bb597444c608c">A synthetic presenter has no “real person” attached, no victim to complain, and no public figure to debunk the content.&nbsp;</li><li data-list-item-id="efe3688ea8aebb1aa6c655308f6223fda">The same synthetic presenter can be reused endlessly, across topics and languages, with minimal cost.&nbsp;</li></ul><p>In short, these “VIPs” are not famous because they are recognized, they are VIPs because they are operational assets in scam production.&nbsp;</p><h2>From celebrity deepfakes to avatar farm&nbsp;</h2><p>Celebrity impersonation is still here, and it will remain attractive. Reputation is a powerful shortcut to trust.&nbsp;</p><p>But impersonation has trade-offs. It is high-profile, easier to report, and riskier for scammers. It can also be brittle, a single debunk can collapse a campaign.&nbsp;</p><p>Synthetic presenters reduce that risk. You do not have to mimic a specific person, you just have to look credible enough to keep someone listening for 20 seconds.&nbsp;</p><p>This is why the “avatar farms” mental model fits.&nbsp;</p><p>Instead of crafting a one-off forgery, scammers can run a production line:&nbsp;</p><ol type="1"><li data-list-item-id="ebb598c8a5f36ed5bf22c58a25cf5137d">Create or acquire a synthetic presenter that looks broadly trustworthy&nbsp;</li><li data-list-item-id="e037f34075f6fe1c6b325444d26aec9ad">Generate scripts at volume, tailored to whatever is trending&nbsp;</li><li data-list-item-id="e9830311305c72262b00d5e0ed4706f87">Swap voiceovers, captions, and visual overlays&nbsp;</li><li data-list-item-id="e1829309715a175d81fbb484eaf94b1e0">Publish, measure engagement, then publish again with minor variations&nbsp;</li></ol><p>That production line scales. It is designed for experimentation, iteration, and reach.&nbsp;</p><p>And it works because most scams do not require cinematic realism. They require momentum.&nbsp;</p><h2>Synthetic trust, the new social engineering&nbsp;</h2><p>Humans are wired to treat faces and voices as social proof. A confident presenter can make a claim feel less risky, even when the claim is outrageous. A calm delivery can make urgency feel “reasonable.” A familiar format can make a stranger’s instructions feel like a normal next step.&nbsp;</p><p>That is the core idea behind synthetic trust.&nbsp;</p><p>AI avatars are not trying to be memorable. They are trying to be acceptable. They are engineered to pass a quick gut-check, “this seems legitimate,” long enough to drive a click, a download, a payment, or a message.&nbsp;</p><p>For scammers, that is an upgrade. A synthetic presenter does not get tired. It does not demand a fee. It does not have a moral objection. It can be generated in many languages, in endless variations, and deployed in parallel across platforms.&nbsp;</p><p>You may still see celebrity bait at the top of the funnel. But underneath it, a lot of scam content is shifting toward manufactured presenters that are easier to scale.&nbsp;</p><h2>The twist: sometimes the video is real and only the audio is weaponized&nbsp;</h2><p>There is another reason audio-first detection matters: not every scam video relies on a fake face.&nbsp;</p><p>Sometimes criminals take legitimate footage, a real interview, a real tutorial, a real product explainer, and overlay a scam pitch on top. The visuals can be authentic. The deception sits in the narration, the instructions, and the call to action.&nbsp;</p><p>This technique does two things for scammers:&nbsp;</p><ul type="disc"><li data-list-item-id="ee6d78ff507a6dd63751daeb5224bcc60">It reduces production cost, because they can recycle existing footage&nbsp;</li><li data-list-item-id="eae4e6dba3c1d54936aa4100bfd420af0">It reduces suspicion, because the visuals look “normal” at a glance&nbsp;</li></ul><p>If defenses focus only on “does the face look fake?”, this kind of repurposed content can slip through. That is why we treat the message as primary. Then, once content is labeled as scam, we look for the repeated visual infrastructure that carries those messages, including recurring AI avatar presenters.&nbsp;</p><h2>A note on hired actors&nbsp;</h2><p>Not every recurring presenter in scam content is synthetic. We have also seen scams that use hired actors or commissioned videos. Sometimes it is a human reading a script, sometimes it is a human clip later repurposed with different narration or overlays.&nbsp;</p><p>In other words: the “avatar farm” trend does not replace all old techniques. It sits alongside them.&nbsp;</p><p>That is also why we avoid simplistic rules like “this face is fake therefore it is a scam.” What matters is intent and behavior. Faces help us connect the dots faster as a signal, they are not the verdict.&nbsp;</p><h2>Practical tips: how to protect yourself from scam videos&nbsp;</h2><p>If a video is pushing you toward money, logins, downloads, or urgent verification, treat the presenter as part of the packaging, not proof.&nbsp;</p><ol type="1"><li data-list-item-id="eb375588bdd69b963a569da0423a5860d"><strong>Follow the action, not the face.</strong>&nbsp;<br>If the video is urging urgency, secrecy, or immediate payment, pause. That pressure is often the scam.&nbsp;</li><li data-list-item-id="ecf36de53c2869ca44dd7de68b8dd6a10"><strong>Verify outside the platform.</strong>&nbsp;<br>Search for the claim from independent sources, not links in the description or comments.&nbsp;</li><li data-list-item-id="ea8e5ddb75021374558a5553272959836"><strong>Be suspicious of “too smooth” certainty.</strong>&nbsp;<br>Scam scripts often sound confident, generic, and strangely frictionless, as if risk does not exist.&nbsp;</li><li data-list-item-id="ee5e84990c119d747dd4cb8566a61b415"><strong>Watch for mismatch.</strong>&nbsp;<br>If the visuals feel unrelated to the pitch, or the audio feels pasted-on, treat it as a warning sign.&nbsp;</li><li data-list-item-id="ecd31fbfea4a6ecebbceff95dfbcc3458"><strong>Avoid installs prompted by videos.</strong>&nbsp;<br>“Install this to verify,” “download this viewer,” “run this command,” these are common routes into malware and credential theft.&nbsp;</li><li data-list-item-id="e190568cd7906f183381254eeea433387"><strong>Use protection tools.</strong><br>Tools like Norton’s AI-powered Scam Protection and Avast Deepfake Guard can help spot what’s easy to miss, including deepfake audio in videos and scam signals across web, SMS and more.&nbsp;</li></ol><h2>The bottom line&nbsp;</h2><p lang="EN-US">Deepfakes may get the headlines, but they are only part of the story. From impersonating real people to manufacturing trust at scale, faces, voices, scripts, formats, all of it can be generated, reused and optimized.&nbsp;</p><p lang="EN-US">Which means the real skill is not spotting what looks fake; it is recognizing how scams behave.&nbsp;</p><p lang="EN-US">Follow the pressure. Question the promise. Verify outside the moment.&nbsp;</p>

When the face is familiar but the person isn’t real 

From Celebrity Deepfakes to Avatar Farms, How Scammers Industrialize Trust

<p>It starts with a message that does not feel wrong.</p><p>You have a family trip coming up. You made the booking days or weeks ago, saved the confirmation and moved on with your life. Then WhatsApp pings.</p><p>The message says it is from the hotel’s Guest Relations team. It references the same property you booked. It mentions details that match your stay. It sounds like the kind of practical note you might expect before a trip, a small inconsistency, a quick verification, a routine check before arrival.</p><p>And that is exactly why it works.</p><p>When a scam contains real details, it stops feeling like spam and starts feeling like customer service. The attacker does not need perfect writing. They do not need malware. They do not even need a particularly clever pretext. They just need enough truth to make the lie feel safe.</p><p>That is the pattern at the heart of what we are calling the <strong>Reservation Hijack Scam</strong>.</p><p>We call it a <strong>Reservation Hijack Scam</strong> because the attacker is not just spoofing a hotel or sending a generic phishing lure. They are hijacking the context around a real reservation and using it to make fraud feel like routine customer service.&nbsp;</p><p>In the stronger versions of the attack, that goes further. Once hotel staff credentials are phished, the attacker may gain access to real hotel or partner accounts and contact guests from within legitimate workflows, for example through a booking platform account or hotel messaging environment. At that point, the scam is no longer only borrowing the hotel’s identity, it is actively impersonating the hotel through systems the guest already trusts.</p><p>That is the shift that matters most. This is not just a travel-themed phishing lure dressed up with better wording. In the strongest cases, criminals can move from impersonating the hotel to operating through compromised hotel-side or partner workflows, contacting real travelers in the context of real reservations.</p><h2>A scam category built on stolen and relayed trust</h2><p>Most phishing is generic. It arrives with no context, so your brain treats it with suspicion.</p><p>Reservation Hijack scams work differently. They reflect real context back at the victim, the hotel name, the destination, the fact that there is a genuine booking, sometimes the stay window, sometimes even the exact amount due. That reflected truth becomes the bypass.</p><p>Add a short fuse, usually 24 or 48 hours, and the attacker gets what they want most, fast compliance before the victim pauses, verifies or calls the property.</p><p>This is not just a nicer phishing template. It is a different quality of deception.</p>

<h2>What we found</h2><p>Our investigation points to two visible fronts in the same scam pattern.</p><p>The first is the booking-platform lure. Victims receive WhatsApp messages or similar contact from what appears to be a hotel or guest relations team, then get pushed into a fake guest portal or payment verification page. We have seen this most clearly in Booking.com-linked cases, with additional signs of similar abuse around other travel and hospitality workflows. These messages feel unusually convincing because they contain real booking context.</p><p>The highest observed activity is concentrated across parts of Western Europe, notably the United Kingdom, France, and Germany, alongside the United States, Brazil and Australia.</p>

<p>We have also seen this scam pattern surface across multiple channels, including Booking.com messaging, WhatsApp, SMS and email. That matters because it shows this is not tied to a single delivery trick. It is a flexible fraud workflow that can move wherever guests are most likely to trust and respond.</p><p>The second is the <strong>hotel software abuse path</strong>, where the attacker does not just imitate a hotel from the outside, but appears to operate from inside the hotel’s workflow. For example, Cloudbeds is a hospitality management platform used by hotels to handle reservations, guest communications, and other day-to-day operations. In the Cloudbeds-related cases we reviewed, the attack chain begins with phishing hotel staff, not guests. Once the attacker steals staff credentials, they can log into real hotel management tooling, access reservation data and use guest communication features to target upcoming travelers. Depending on the systems tied to that hotel workflow, that may also let the attacker operate through legitimate booking or messaging accounts associated with the property, effectively communicating with real customers as if they were the hotel itself.</p><p>That shift matters.</p><p>At that point, the hotel is no longer just the theme of the scam. Its real accounts, workflows and communication channels can become the delivery mechanism.</p><p>That hotel-side compromise path is not theoretical. In partner-targeted examples we uncovered, attackers impersonated Booking.com security communications and pushed accommodation partners to install what was presented as a mandatory security update. In reality, the attached material led the victim to run a malicious command (<a href="https://www.gendigital.com/blog/insights/reports/threat-report-q3-2025" target="_blank">Scam-Yourself Attack Tactic</a>) that deployed a remote access trojan, giving the attacker a foothold that could then be used to steal credentials and abuse the partner account.</p>

<h2>How the scam works, from start to finish</h2>

<p>At its core, this scam follows a simple pattern, even if the entry point can vary.</p><p>First, the attacker gains access to trust, typically by phishing hotel staff and stealing credentials to a real hospitality platform or connected hotel account. That gives them visibility into genuine reservations, the contact details of real travelers, and in some cases the ability to communicate through legitimate hotel-linked workflows.</p><p>Next, the attacker identifies real travelers. That is what makes the scam feel different from ordinary phishing. The victim is not chosen at random. They are contacted in the context of a real trip, with details that match an actual booking.</p><p>The level of personalization depends on how much information the attacker has. When they can access rich reservation data, such as the property name, stay dates, guest name, payment context or booking details, they can build a highly tailored spear phishing message that feels almost indistinguishable from routine customer service. When they only have limited data, such as an email address or phone number, the scam may look more generic, but it can still exploit hotel branding, urgency and the expectation of pre-trip communication.</p><p>That difference is visible in the lures themselves. In high-context variants, the message may name the guest, reference a specific stay date and amount, or lead to a payment page already populated with reservation details. In lower-context variants, the flow is far more generic and relies on the victim to fill in the missing details themselves.</p>

<p>That difference is visible in the lures themselves. In high-context variants, the message may name the guest, reference a specific stay date and amount, or lead to a payment page already populated with reservation details. In lower-context variants, the flow is far more generic and relies on the victim to fill in the missing details themselves.</p><p>In the weaker version of the scam, the attacker uses that information to craft convincing messages from the outside, through WhatsApp, SMS or email lookalikes. In the stronger version, the attacker may message the guest from a real hotel or booking-related account they have taken over. The difference is important. The victim may not just see a plausible hotel message, they may see what looks like a legitimate continuation of their existing booking conversation.</p><p>In one case we reviewed, the phishing message was delivered through a legitimate Booking.com partner communication thread after the accommodation partner account had been compromised. The malicious request was injected into an otherwise normal conversation, making the attack especially difficult to detect because it arrived from a trusted source rather than a spoofed sender. The follow-up warning from the hotel highlights the confusion and damage that can occur once a real partner account is abused:</p>

<p>Then comes the message. It usually arrives over a fast, informal channel such as WhatsApp or SMS, and it is written to feel administrative rather than alarming. The goal is not to scare the victim, but to make the request feel routine, a payment issue, a booking confirmation, a verification step or an urgent action before arrival.</p><p>In the examples we reviewed, the exact wording and format varied by platform, but the underlying pattern stayed consistent: the message borrowed hotel context, introduced a practical problem, and pushed the guest toward a verification or payment step that benefited the attacker.</p><p>From there, the victim is pushed into a controlled flow. That may be a fake guest portal, a spoofed payment page, or even a branded PDF that adds one more layer of credibility before the victim reaches the real theft stage.</p><p>The theft happens when the traveler enters payment details, approves a transfer or otherwise complies with the fake verification process. At that point, the attacker has turned stolen trust into financial fraud.</p><p>And the damage may not stop there. Payment details can be reused, tested with small charges, sold or leveraged in follow-on scams. What begins as a believable hotel message can end in broader financial compromise.</p><p>That is what makes this scam different. It is not just phishing with a travel theme. It is a workflow attack built on stolen context and relayed trust.</p><h2>The Cloudbeds path, step by step</h2><p>Cloudbeds has publicly warned of an industry-wide phishing campaign targeting hospitality providers and described credential-phishing attacks impersonating Cloudbeds login pages as the root cause rather than a Cloudbeds platform breach.</p><p>That point matters especially for small and medium-sized hospitality businesses. Large travel brands usually have bigger security teams, more formalized controls and more mature fraud processes. Smaller properties often rely on lean teams, fast guest communication and a handful of operational platforms to keep everything moving. That makes them particularly vulnerable when attackers target employees directly with credential phishing.</p><p>The attack chain we mapped is brutally efficient.</p><p>First, hotel staff are lured to fake login pages and their credentials are stolen. Then the attacker logs into the real management environment. From there, they can see future reservations, guest names, contact details, stay information and sometimes payment context. In some scenarios, that access may also extend beyond visibility. If the compromised hotel workflow is connected to guest-facing messaging on booking or hospitality platforms, the attacker may be able to contact customers from the property’s legitimate account presence. That makes the fraud especially dangerous, because the message may arrive inside a channel the traveler already associates with their real reservation.</p><p>In the cases documented in our working material, some victims received SMS messages containing detailed reservation information and links that led to professionally styled PDFs impersonating hotel groups. Those PDFs pushed “payment verification” within 48 hours, using generic branding, urgency, and a prominent call to action to move the victim toward the real theft stage. The PDF step appears to function as a buffer, one more layer of legitimacy for the victim, and one more layer of indirection for scanners and filters to deal with. In some cases, the PDF itself was hosted on legitimate partner storage that had been hijacked, giving the lure another borrowed layer of trust before redirecting the victim onward.</p>

<p>From there, the victim is redirected again, typically to typo-squatted domains designed to harvest card details, bank transfers or other payment information. Example domains documented in the shared material include frontdesk-reservation[.]com, frontdesk-online[.]biz, and hotel.form842987[.]digital.</p><h2>One scam, multiple surfaces</h2><p>This is the part many people miss.</p><p>The WhatsApp message, the SMS, the fake PDF, the lookalike payment page, the stolen card, these are not separate incidents. They are one pipeline. And that pipeline can include direct impersonation of the hotel itself. Sometimes the attacker stands outside the workflow and imitates the property. Sometimes the attacker steps inside a compromised hotel or booking-related account and speaks from a position the guest already trusts. Different surface, same scam family.</p><p>First, the attacker gets context. Next, they use that context to deliver a believable message through a channel people act on quickly. Then they move the victim into a verification flow that feels administrative, not dangerous. If payment details are entered, the harm does not stop at one fraudulent charge. Cards can be tested with small transactions, then used for larger purchases, then resold or retried later.</p><p>This is what makes the scam so dangerous. The same fraud logic can be adapted to different platforms, different levels of stolen context, and different points in the guest journey.</p><h2>Why this matters now</h2><p>Hospitality has become an unusually attractive environment for this kind of fraud.</p><p>Hotels run on urgency, constant guest communication and high-trust operational workflows. Travelers expect messages about check-in, balances, room preferences, arrival timing, and identity verification. That makes it easier for attackers to hide malicious intent inside language that would look normal in almost any other context.</p><p>And when the attacker is working with real reservation data, or worse, using compromised hotel or booking-linked accounts to contact guests directly, the old consumer advice starts to bend. Checking the link still matters, but it is no longer enough on its own. The victim is not just being tricked by branding. They are being tricked by context.</p><h2>What travelers should do</h2><p>If a hotel contacts you via Booking.com messaging, Airbnb, WhatsApp, SMS or email and asks you to verify payment details, do not tap the link. The same caution applies if the message appears to come from an existing reservation thread or from what looks like the hotel’s real account on a booking platform. Trust the booking, not the message.&nbsp;</p><p>Go to the booking site, hotel site, or official app yourself. If you need to call the property, use a trusted contact route from the original booking or the verified website, not the number or link inside the message.</p><p>If you already entered payment details, assume compromise. Contact your bank, cancel the card, enable transaction alerts and watch for follow-on attempts.</p><h2>What hotels should learn from this</h2><p>The lesson for hospitality is not just “train staff better,” although that matters. It is that hotel software, messaging workflows, and guest communication tools now sit directly on the fraud path.</p><p>The hotel is no longer only a victim. In the eyes of the guest, it can become the face of the scam. In the worst cases, it can also become the voice of the scam, when attackers use compromised hotel or partner accounts to message guests as if they were legitimate staff.</p><p>That means account protection, phishing-resistant authentication, tighter controls around exports and guest messaging, anomaly detection and faster incident response are no longer nice-to-haves. They are part of brand protection.</p><p>Because once attackers learn how to turn operational systems into trust amplifiers, they do not need to break in loudly. They can simply log in, relay stolen trust to the guest, and let the workflow do the rest.</p><h2>One final thought</h2><p>For years, the best advice on travel scams was simple: watch for bad grammar, generic messages, and suspicious links.</p><p>That advice still matters. But it belongs to an earlier phase of the problem.</p><p>The next phase looks like this: the message knows your booking, sounds plausible, and may arrive through a channel or account the traveler already trusts. That is the point where customer service and fraud begin to overlap.</p><p>That is the Reservation Hijack Scam.&nbsp;</p><p>In the next part of this series, we will look more closely at the infrastructure, indicators and investigative signals behind it.</p>

From Booking-themed lures to compromised hospitality software, criminals are using reservation data and trusted workflows to make fraud feel like customer service. 

The Reservation Hijack Scam: How attackers hijack hotel accounts to target guests

Threat Research Team

<h2><strong>TL;DR&nbsp;</strong></h2><p>It started with a lie. A sample walked into the lab wearing a Vidar label like a cheap suit two sizes too small. We pulled the threads, and the whole thing came apart. What fell out was a previously unknown information stealer we named <strong>Torg Grabber</strong> – 334 samples compiled over three months, a rapid evolution from Telegram dead drops through an encrypted TCP protocol nobody asked for, all the way to a production-grade REST API that worked like a Swiss watch dipped in poison. Over 40 operator tags pulled from the binaries – a mix of nicknames, date-encoded batch IDs, and confirmed Telegram user IDs – fingerprinted individual MaaS customers and confirmed what we already suspected: this was a builder-and-panel operation, crime as a service, infrastructure included. OSINT resolution of the numeric tags peeled back the curtain on eight operators as Telegram accounts buried up to their necks in the Russian cybercrime ecosystem. The bot tokens gave us the developer accounts behind the whole show. Nobody said crime doesn’t pay, but nobody said it doesn’t leave fingerprints either.&nbsp;</p><p><strong>The misclassification that started It all&nbsp;</strong></p><p>The sample came in on a Tuesday in early February, wearing the name Vidar Stealer the way a pickpocket wears a priest’s collar. It didn’t fit. A 747 KB PE64 binary compiled with MinGW/GCC – when Vidar v17.9 is a 32-bit MSVC job that, as a colleague put it, “looks significantly different.” That was like saying a Great Dane looks significantly different from a Pekingese. You didn’t need a magnifying glass.&nbsp;</p><p>A deeper look turned up a self-identifying debug string – "<code>grabber v1.0</code>" – sitting in the binary like a monogrammed handkerchief left at a crime scene. The C2 protocol was all wrong for Vidar: REST API endpoints (/api/auth, /api/upload/chunk), ChaCha20 encryption, HMAC-SHA256 authentication. This wasn’t Vidar any more than I was the Queen of England.&nbsp;</p><p>We ran it against StealC v2 for good measure – similar endpoint patterns on the surface, the way all gin joints look alike from the sidewalk. Zero protocol overlap. Different endpoint structure, different communication model, different encryption. This was something new, something nobody had put a name to yet.&nbsp;</p><p>So we named it ourselves. <strong>Torg Grabber</strong> – “Torg” from its most-used C2 domain <code>technologytorg.com</code> (Russian <em>“торг”</em> = trade, marketplace – fitting for a business that trades in other people’s secrets), and “Grabber” from the malware’s own vocabulary (<code>GRABBER_HOST, GRABBER_TAG, "grabber v1.0</code>"). If a thing names itself, you ought to listen.&nbsp;</p><h2><strong>Timeline: Two months of rapid development&nbsp;</strong></h2><p>Three hundred thirty-four samples. Three months. It was like watching a time-lapse film of a weed growing through concrete. The corpus told the story of a malware operation spinning up in real time, stumbling forward with the reckless confidence of a man who knows exactly what he’s doing and doesn’t much care who’s watching.&nbsp;</p>

<p>Three exfiltration mechanisms. Three ways to get the goods out. Each one a little smarter than the last, the way a burglar graduates from smashing windows to picking locks to making copies of the key.</p><h3>Phase 1: Telegram Bot API (Dec 9–11, 2025)</h3><p>The earliest builds were small and nervous, the way a rookie’s hands shake on his first job. Compact little things, 270 to 313 KB, that grabbed credentials, stuffed them into a ZIP archive, and shipped the whole package to a private Telegram channel via&nbsp;sendDocument. No encryption beyond TLS. A&nbsp;User-Agent: TG header about as subtle as a neon sign in a funeral parlor. Five retry attempts, and if the ZIP upload choked, a fallback to plaintext&nbsp;sendMessage – the digital equivalent of shouting your secrets across a crowded room.</p><p>Twenty-five samples, eight bot tokens, eight private channels, each with two or three members. This was the prototype phase: fast to set up, zero infrastructure cost, and about as durable as a paper umbrella in a monsoon. Telegram can revoke tokens on a whim, and the API calls stick out in traffic logs like a tall man in a short crowd.</p><h3>Phase 2: GRAB Binary TCP Protocol (Dec 17–20, 2025)</h3><p>Four samples. A narrow four-day window. This was the experimental phase – somebody had an idea, and they were going to see if it could walk before they taught it to run.</p><p>Instead of HTTP, the malware opened a raw TCP socket to&nbsp;<code>*.tara.net.bd</code> on port 50443 and spoke a custom binary protocol that had all the charm of a coded knock on a speakeasy door:</p><ul><li data-list-item-id="e3d01df3606010b531fb2e83821bb7f96">A 9-byte frame: 4-byte&nbsp;<code>GRAB</code> magic, 1-byte type, 4-byte length</li><li data-list-item-id="e0aa34faadca69a4d6fcee2220c2a3415">ChaCha20-Poly1305 AEAD encryption with HMAC-SHA256 key derivation</li><li data-list-item-id="eec12b3e52f329ead2daead35c83d690c">SHA-256 hash of the payload sent before the encrypted data</li><li data-list-item-id="e0500a32b5824c04717745665cb222a44">64 KB chunks with 5-second retry intervals</li></ul><p>The C2 hostnames were&nbsp;<code>bk.tara.net.bd and&nbsp;raketa.tara.net.bd</code> – “raketa” being Russian for “rocket,” because even criminals have a sense of poetry. Both under a Bangladesh TLD but geolocated to Turkey, which made about as much geographic sense as a polar bear in Havana. The encryption key was hardcoded:&nbsp;<code>0123456789abcdef</code> repeated. A test key. Development builds, still warm from the compiler.</p><p><em>See Appendix A, Figure A1</em></p><p>Technically sophisticated – proper AEAD, authenticated handshakes, chunked transfer. The kind of work that said the developer knew cryptography the way a safecracker knows tumblers. But it was abandoned after four builds. Running a custom TCP protocol at scale turned out to be harder than hiding behind Cloudflare, which is to say, harder than letting somebody else do the heavy lifting. Some lessons you only need to learn once.</p><h3>Phase 3: REST API over HTTPS (Dec 18 onward)</h3><p>This was the production rig. The real thing. No more rehearsals.</p><p>The malware performs a JSON registration at&nbsp;<code>/api/auth</code>, sending along a machine fingerprint – GPU, wallpaper hash, hardware ID, antivirus product – like a new inmate checking into prison with his personal effects. In return, it gets configuration, a session token, and sometimes shellcode, because some operators like to bring their own party favors. Then comes the upload: stolen data, chunked over HTTPS, ChaCha20-encrypted, routed through Cloudflare. Each request carries an HMAC-SHA256&nbsp;<code>X-Auth-Token</code> header, because even thieves want to know they’re talking to the right fence.</p><p><em>See Appendix A, Figure A2</em></p><p>Over two months, the binary fattened up from ~410 KB to ~747 KB, the way a confidence man’s wallet thickens over a good season. The additions were considerable: a 20 KB ChaCha20-encrypted Reflective DLL for bypassing Chrome 127+ App-Bound Encryption across 7 Chromium browsers via their IElevator COM interfaces; 20 direct NT syscall wrappers with PRNG-obfuscated tables; and an ever-growing shopping list of collection targets – 850 browser extensions alone consuming ~213 KB of binary space, like a burglar’s toolkit that takes up half the trunk. Two size epochs are visible – a ~160 KB jump around January 21 that marks a major feature release as clearly as a new coat of paint on an old building. The newest builds kept rolling off the line daily through February 2026, each one a little bigger, a little meaner, a little hungrier.</p><h2>The loader chain: From dropper to stealer</h2><p>Torg Grabber doesn’t show up at the party alone. It arrives wrapped in layers, the way a bad idea shows up wrapped in good intentions — three skins of encryption and obfuscation to peel away before the stealer ever touches memory. Each skin has a job. The outer one: crypter-level polymorphism, the kind that makes every sample look like a different animal. The middle: reflective PE loading, never leaving fingerprints on disk. The innermost: the stealer itself, finally naked and ready to work.</p><h3>Stage 0: The Dropper</h3><p>The outermost layer changes its face depending on who’s handing it out. Telemetry from our userbase paints the picture – several lure families, all funneling into the same loader chain like tributaries feeding a dirty river:</p><ul><li data-list-item-id="ef20558cd69ad2240467faf8b907f23c7"><strong>Fake game cheats</strong>:&nbsp;<code>CrimsonLoader.exe,&nbsp;RivalMods.exe</code></li><li data-list-item-id="ecfc5a9772478bacf10752d88d8626f41"><strong>Cracked software</strong>:&nbsp;R<code>elease-app-x64.rar</code> →&nbsp;<code>Set-up.exe</code>,&nbsp;<code>Aerovora.zip</code>,&nbsp;<code>Terraria_1.4.5.zip</code></li><li data-list-item-id="eb92e8d896c8fe97501e98a43c55aa26a"><strong>ClickFix clipboard</strong>: PowerShell one-liner via Google Apps Script (see&nbsp;<a href="//F7CA28BA-0D78-43F6-82F3-AD55EE8C3098#in-the-wild-observed-infection-chain">full chain below</a>)</li></ul><p>Regardless of the lure, the final dropper drops a randomly-named executable into&nbsp;<code>C:\Windows\ –&nbsp;v4jkqh.exe</code>,&nbsp;<code>hkjpy08.exe</code>,&nbsp;<code>ln3dkgz.exe</code>,&nbsp;<code>en3v4ior.exe</code> – names that look like someone fell asleep on the keyboard. This pattern is consistent across 78 distinct samples in our telemetry. The crypter stage. The thing that gets you in the door.</p><p>Before it spawns the next stage, the dropper does something clever. Configuration propagation. It sets environment variables that carry the operator’s whole setup across process boundaries — the way a con man memorizes his cover story before he walks into the bank:</p>

<p>One compiled stealer, a hundred operators. The dropper injects identity at runtime. Crime as a service, served by environment variables.</p><h3>Stage 1: Self-Extracting Loader</h3><p>The first code stage is a MinGW-compiled PE64 with an encrypted overlay pasted on the end — beyond the section data, like a secret message written on the back of a photograph. The overlay structure lives in the file’s last 8 bytes. You have to read backwards to find the beginning:</p><p><em>See Appendix B, Listing B1&nbsp;</em></p><p>The extraction pipeline runs like a three-card monte:</p><ol><li data-list-item-id="e5b92ce18abe492c50ce87bded031e432"><strong>Hex decode</strong> — Custom hex encoding: 3 bytes per output byte, two hex digits plus a separator. Lower entropy than raw ciphertext. The kind of detail that evades entropy detection the way a whisper evades a crowded room.</li><li data-list-item-id="eea648425fcc7b67250a494bd3dc405ea"><strong>AES-256-CBC decrypt</strong> — Key and IV pulled from the overlay. Every build gets its own key material. The builder doesn’t recycle.</li><li data-list-item-id="e472ee13b2b0ba690024aa2694c9aaf77"><strong>Parse decrypted buffer</strong> — A&nbsp;uint32 skip count, then null-terminated API name strings (<code>NtWriteVirtualMemory</code>, <code>NtProtectVirtualMemor</code>y), then the shellcode. The loader resolves those NT APIs at runtime and injects the shellcode into memory using direct syscalls. No imports. Clean hands.</li></ol><h3>Stage 2: Reflective PE Loader</h3><p>The shellcode from Stage 1 is a PE in disguise. A reflective loader carrying the final Torg Grabber payload as an encrypted blob in <code>.rdata</code> — about 793 KB of trouble. This stage runs entirely in memory. It never touches disk. The kind of ghost that leaves no footprints.</p><h4><em>Dynamic API Resolution</em></h4><p>The loader finds every Windows API it needs by walking the PEB — Process Environment Block — and parsing export tables. No&nbsp;<code>GetProcAddress</code> in the import table. Static analysis looks at the binary and sees nothing. It’s the malware equivalent of paying cash.</p><h4><em>AES-256-CBC Decryption</em></h4><p>The blob gets decrypted first. AES-256-CBC, hardcoded 256-bit key, 128-bit IV. Each build carries different constants. Fingerprints:</p><p><em>See Appendix B, Listing B2&nbsp;</em></p><h4><em>Four Cascaded Byte Transforms</em></h4><p>After AES comes the garnish. Four byte-level transforms in sequence. Reversible arithmetic over GF(2^8). The constants vary by build; the structure never does:</p>

<table class="table"><tbody><tr><td>Step</td><td>Operation</td><td>Constant</td><td>Purpose</td></tr><tr><td>1</td><td>byte = (byte + K₁) &amp; 0xFF</td><td>0x7C / 0xAC</td><td>Additive shift</td></tr><tr><td>2</td><td>byte = byte ^ K₂</td><td>0x68 / 0x58</td><td>XOR mask</td></tr><tr><td>3</td><td>byte = ROR(byte, 2) / ROL(byte, 2)</td><td>2 bits</td><td>Bit rotation</td></tr><tr><td>4</td><td>byte = (byte * K₃) &amp; 0xFF</td><td>0xC5 / 0xCD</td><td>Modular multiply</td></tr></tbody></table>

<p>Five layers total with AES. Simple XOR-key recovery goes home empty. Automated decryption without the right constants hits a wall.</p><h4><em>Anti-Analysis: NOP-Equivalent Functions</em></h4><p>Between decryption stages, the loader calls functions that look busy. Multi-register shuffles. Conditional branches. Memory loads. Complex enough to make a decompiler sweat. Net effect: zero. They’re NOPs dressed up for the opera:</p>

<p>Several of these stubs get called between each decryption stage and before the memmove. Dead code padding the call graph like sawdust in a cheap sausage.</p><h4><em>The Hidden memmove: PE Reassembly from Non-Contiguous Chunks</em></h4><p>The operation that matters most — and the one you’re most likely to miss. After the byte transforms, a single&nbsp;<code>memmove</code> stitches the final PE together from two pieces that weren’t sitting next to each other:</p><p><em>See Appendix B, Listing B3</em></p><p>Skip the memmove and you get a PE with a poisoned&nbsp;<code>.idata</code> section and 110 KB of overlay garbage. It loads into IDA. It crashes when you run it. The encryption stuffed junk between the two halves — any automated extractor has to know exactly where to cut and paste. Final size:&nbsp;<code>0xA6E00</code> = 683,520 bytes. Hardcoded in the loader as a&nbsp;<code>VirtualAlloc</code> parameter.</p><h4><em>Manual PE Mapping</em></h4><p>After reassembly, the loader maps the PE the old-fashioned way. Reflective loading 101:</p><ol><li data-list-item-id="e1b056298a8894ae089d3da9a8901b3aa"><strong>Allocate</strong> —&nbsp;<code>VirtualAlloc(PAGE_READWRITE)</code> for&nbsp;<code>SizeOfImage</code> bytes</li><li data-list-item-id="eb2193d53562357b767ce7b7fa01d3116"><strong>Copy headers</strong> — first&nbsp;<code>SizeOfHeaders</code> bytes</li><li data-list-item-id="eef41778348fbeeefd913c08313ff305b"><strong>Map sections</strong> — to their virtual addresses (<code>VirtualAddress + base</code>)</li><li data-list-item-id="e2dfba01eaa5a533e27b2001492ba03c6"><strong>Process relocations</strong> — apply delta from preferred&nbsp;<code>ImageBase</code> to actual allocation</li><li data-list-item-id="e84e05b522b4a583feeb4671f81391808"><strong>Resolve imports</strong> — walk the Import Directory,&nbsp;<code>LoadLibraryA</code> and&nbsp;<code>GetProcAddress</code> for each DLL/function</li><li data-list-item-id="e0bd9f61592132d5e5cd730bf4b857dff"><strong>Set section permissions</strong> —&nbsp;<code>VirtualProtect</code> with&nbsp;<code>PAGE_EXECUTE_READ</code>,&nbsp;<code>PAGE_READONLY</code>,&nbsp;<code>PAGE_READWRITE</code></li><li data-list-item-id="e34ebad8f173a493e0d3668315a6921b1"><strong>Call entry point</strong> —&nbsp;<code>AddressOfEntryPoint + base</code></li></ol><p>The stealer PE never hits disk. It lives only in memory, mapped inside the loader’s process. A ghost inside a ghost.</p><h3>Stage 3: Torg Grabber</h3><p>The final payload. 683 KB PE64. MinGW/GCC. Seven hundred thirty-seven functions in fifteen categories, organized like a filing cabinet in a detective’s office — everything in its place:</p><p><em>See Appendix B, Listing B4 (Stage 3: Torg Grabber).]</em></p><p>Execution starts at&nbsp;<code>main_data_collection_and_exfil</code>. The orchestrator. The one running the show:</p><ol start="8"><li data-list-item-id="e7e97057020ca972f16d99cd2de4c9d58"><strong>Reads configuration</strong> —&nbsp;<code>GRABBER_*</code> environment variables, set by the dropper, with hardcoded fallbacks for the forgetful</li><li data-list-item-id="e59d21024124feb483ed7084b75283ebe"><strong>Profiles the system</strong> — MachineGuid, GPU, process list, antivirus (46 signatures across 24 products), VM/sandbox detection, CIS locale check</li><li data-list-item-id="e6dd228fde01ef32dd9634540729fde71"><strong>Creates a mutex</strong> —&nbsp;<code>Local\&lt;MachineGuid&gt;</code> so only one instance runs at a time</li><li data-list-item-id="e003a12fb4575621eb9150a6dd12e7f56"><strong>Registers with C2</strong> — POST to&nbsp;<code>/api/auth</code> with ChaCha20-encrypted JSON, gets a session ID and maybe streaming config</li><li data-list-item-id="e8caea529cba09bd0a405a330b9f1500e"><strong>Resolves NT syscalls</strong> — parses&nbsp;<code>ntdll.dll exports</code>, builds PRNG-obfuscated syscall table</li><li data-list-item-id="e30e1ff27be21c754814b9cbad9b3f89e"><strong>Collects data</strong> — 25 Chromium browsers, 8 Firefox, 850 extensions, Discord, Steam, Telegram, VPN, FTP, email, password managers, wallets, screenshot, installed software, Desktop/Documents files</li><li data-list-item-id="ee0c091fe9e7fafc3479d6316df833505"><strong>Exfiltrates</strong> — archives to in-memory ZIP or streams chunks, uploads via chunked HTTPS with ChaCha20 and HMAC-SHA256</li></ol><p>The stealer can also take shellcode from the C2 at registration.&nbsp;<code>decrypt_and_execute_shellcode</code> handles ChaCha20-decrypted, zlib-compressed payloads — allocates executable memory via&nbsp;<code>NtAllocateVirtualMemory</code>, runs it. Arbitrary post-exploitation without a new binary. Before execution,&nbsp;<code>export_config_to_env</code> writes the config back to environment variables so any child process inherits the operator’s settings.</p><h3>Configuration propagation: The environment variable chain</h3><p>One pattern runs through the whole chain: <strong>configuration travels by environment variable</strong>. The dropper sets&nbsp;<code>GRABBER_*</code>. The stealer reads it at startup (<code>init_grabber_config_from_env</code>). Before process injection — ABE bypass, shellcode — the stealer writes the config <em>back</em> to env vars (<code>export_config_to_env</code>). Child processes inherit. No recompilation. One payload, many operators:</p><p><em>See Appendix B, Listing B5&nbsp;</em></p><p>The stealer binary is operator-agnostic. The builder customizes the dropper. The dropper does the rest.</p><h3>In the Wild: Observed infection chain</h3><p>Static analysis gives you the stages. Behavioral telemetry gives you the story. We captured the <strong>full delivery chain</strong> on a real victim machine — January 30, 2026 — from initial social engineering through PowerShell stages to stealer execution. The whole show, start to finish.</p><h4><em>The ClickFix Initial Access</em></h4><p>Before the InnoSetup dropper. Before the PowerShell. A <strong>clipboard hijack</strong>. The victim hits a malicious Google Apps Script page:</p><p><code>https://n-3t7yxs7pcq6bihciyqway6qnhvhrol2fgy2tdaa-0lu-script.googleusercontent.com/blank</code></p><p>The page drops a PowerShell command into the clipboard and tells the victim to paste. Classic ClickFix. The 309-byte payload (SHA256:&nbsp;<code>07b96e5c...e6c26edebf, detected as&nbsp;HTML:Clipboard-A</code>) triggers the base64-encoded stager download from&nbsp;<code>j0o.pw/core2</code>. The clipboard payload was captured along with the dropped stager — the missing link between the social engineering and the PowerShell chain.</p><h4><em>Full Process Tree</em></h4><p><em>See Appendix B, Listing B6&nbsp;</em></p><h4><em>Stage by Stage</em></h4><p><strong>0. ClickFix clipboard attack</strong> — The victim visits a Google Apps Script page (<code>n-3t7yxs7pcq6bihciyqway6qnhvhrol2fgy2tdaa-0lu-script.googleusercontent.com</code>) with a fake verification or update prompt. The page silently copies a PowerShell command to the clipboard and tells the user to hit Win+R and paste. That 309-byte payload (<code>HTML:Clipboard-A</code>) kicks off everything — the Chrome InnoSetup download and the hidden PowerShell downloader both trace back to that paste. Google Apps Script: trusted domain, free hosting, URLs you can’t blocklist without catching the whole neighborhood in the net.</p><p><strong>1. Dropper download</strong> — Chrome pulls <code>GAPI_Update.exe</code> from Dropbox (<code>uc0be8c69...dl.dropboxusercontent.com</code>). 60 MB InnoSetup. Extracts benign DLLs (<code>msvcp140.dll, vcruntime140.dll, WebView2Loader.dll</code>) to <code>%LOCALAPPDATA%\Connector\</code>. Looks like a real install. Looks like a lot of things that aren’t.</p><p><strong>2. Hidden PowerShell BITS downloader</strong> — A PowerShell process with <code>-W Hidden -E &lt;base64&gt;</code>. The decoded command uses <strong>BITS Transfer</strong> — Windows’ Background Intelligent Transfer Service — to grab the next script:</p>

<p>BITS runs through <code>svchost.exe</code>, not PowerShell. Legitimate Windows service. Many endpoint tools never look. The script runs, then deletes itself. <strong>Fileless</strong> delivery. No artifact left behind but the memory of the thing.</p><p><strong>The&nbsp;</strong><code><strong>sys.ps1</strong></code><strong> stager — decoded content:</strong></p><p>Live payloads downloaded from both endpoints (infrastructure still serving as of February 8, 2026): <code>/core</code> is 6,944 bytes (SHA256: <code>a7fafc75...079fa3e2</code>, <a href="https://www.virustotal.com/gui/file/a7fafc75426a3b31dc89915cc79c014ad094bfcb98d69c39af4a0847079fa3e2">VT</a>); <code>/core2</code> is 6,972 bytes (<code>94c964eb...cd800fd</code>). Same structure: base64-wrapped payload, <code>$e</code> = <code>[System.Convert]::FromBase64String('...'); Invoke-Expression [System.Text.Encoding]::UTF8.GetString($e)</code>.</p><p><strong>3. Fake “Windows Security Update” progress bar</strong> — The script brings the console to the foreground with Add-TypeP/Invoke:</p><p><em>See Appendix B, Listing B7&nbsp;</em></p><p><code>Add-</code>Type compiles via <code>csc.exe</code> — producing <code>pvxhy3qg.cmdline</code> and <code>bz2ytolk.cmdline</code> invocations in the process tree. Not AMSI bypass. Just bringing the window forward and resizing to 80x20. Then an animated ASCII progress bar. <strong>420 seconds</strong>. Seven minutes. 24 milestones. The victim watches. The real work happens in the background.</p><p><em>See Appendix B, Listing B8&nbsp;</em></p><p><strong>4. XOR-encrypted triple loader download</strong> — While the progress bar ticks, a background <code>Start-Job</code> downloads <strong>three loaders</strong> via BITS Transfer, <code>Invoke-RestMethod</code> as fallback. Each file: base64 blob decrypted with a <strong>256-byte repeating XOR key</strong>:</p><p><em>See Appendix B, Listing B9&nbsp;</em></p><p>Base64 decode. XOR each byte against the key, cycling every 256. We verified: both <code>t4e.pw/res1.php</code> (2.6 MB) and <code>t4e.pw/res4.php</code> (2.7 MB) decrypt to valid PE64 with <code>MZ</code> headers. Three loaders, executed <strong>sequentially</strong> with 30–41 second delays. Hidden.</p><p>Endpoint versioning: <code>/core uses</code> res{1–3}, <code>/core2</code> uses res{4–6}. Domains split: <code>j0o.pw</code> = stagers, <code>t4e.pw/re3.pw</code> = loaders.</p><table class="table"><tbody><tr><td>Stager version</td><td>Loader 1</td><td>Loader 2</td><td>Loader 3</td></tr><tr><td>/core (6,944 B)</td><td>t4e.pw/res1.php</td><td>t4e.pw/res2.php</td><td>re3.pw/res3.php</td></tr><tr><td>/core2 (6,972 B)</td><td>t4e.pw/res4.php</td><td>t4e.pw/res5.php</td><td>re3.pw/res6.php</td></tr></tbody></table>

<p><strong>5. Loader execution and unpacking chain</strong> — Decrypted loaders land in <code>%LOCALAPPDATA%\Microsoft\Windows\UpdateCache\</code> as <code>updateWeb_Microsoft_v7028111.exe</code> and kin. Fake version strings: “Breathtaking Output 383” / “Global Channel Port Limited”. Server-side polymorphism. Fresh build per download.</p><p>Complete unpacking chain: <strong>seven layers</strong> — base64 → XOR → AES-CBC overlay → hex-encoding → CTR cipher → LZNT1 → AES-CBC + byte transforms. Both chains deliver the same 683 KB stealer, compiled 19 minutes apart:</p><p><em>See Appendix B, Listing B10</em></p><p>Binary comparison: .<code>data</code> section byte-for-byte identical. <code>.text</code> differs by 48 bytes. Campaign IDs: “meow” vs “gapi”.</p><p><strong>6. Detection</strong> — The captured instance (<code>eee3f818</code>..., 13 MB) spawned twice. First instance proceeded with extraction. Second spawned dllhost.exe. Behavioral detection terminated the second instance as the loader tried to disable Event Tracing for Windows before execution.</p><h4><em>New Infrastructure: The PowerShell C2 Layer</em></h4><p>Four domains. Delivery and exfiltration split like a good heist crew:</p>

<table class="table"><tbody><tr><td>Domain</td><td>Role</td><td>Endpoints</td><td>IP</td><td>Protocol</td></tr><tr><td>j0o.pw</td><td>Stager only</td><td>/core, /core2</td><td>84.200.125.231</td><td>HTTPS</td></tr><tr><td>t4e.pw</td><td>Loader only</td><td>/res1.php–/res5.php</td><td>84.200.125.231</td><td>HTTPS</td></tr><tr><td>re3.pw</td><td>Loader only</td><td>/res3.php, /res6.php</td><td>84.200.125.231</td><td>HTTPS</td></tr><tr><td>si-dodgei.digital</td><td>Stealer C2</td><td>/api/auth, /api/upload/*</td><td>104.21.50.122 (Cloudflare)</td><td>HTTPS</td></tr></tbody></table>

<p>All three <code>.pw</code> domains hit the same IP (84.200.125.231). <code>j0o.pw</code> and <code>t4e.pw</code> registered January 28, 2026 — same day, PublicDomainRegistry.com, <code>orderbox-dns.com</code> DNS, Let’s Encrypt certs issued together. Palau TLD. Short names. Disposable. SOA emails: <code>ellisdtum@gmx.com</code>, <code>jameyjswoeste@gmx.com</code>. GMX. Throwaway.</p><p>Infrastructure still live as of February 8, 2026. Server-side polymorphism confirmed. <code>si-dodgei.digital</code> = new stealer C2 — registered December 24, PDR, Cloudflare. Separate delivery and exfiltration. Bad burns on the loader side don’t touch active stealers. Burns on the stealer C2 don’t touch the delivery pipeline. Operational resilience. The kind of planning that keeps you in business.</p><h2>Technical highlights</h2><h3>Direct syscalls with PRNG obfuscation</h3><p>The malware resolves NT syscall numbers the hard way – parsing&nbsp;<code>ntdll.dll</code>’s export table straight from the PEB, scanning for&nbsp;<code>syscall;</code> ret byte patterns, and storing the results in a table encrypted with a custom PRNG. The seed comes from&nbsp;<code>QueryPerformanceCounter</code>, PID, TID, and stack ASLR – four sources of randomness stirred together like a bartender making a cocktail that nobody ordered. Twenty syscalls wrapped, covering process injection for ABE key extraction, file I/O for prying open locked browser databases, and process termination for killing browsers that have the bad manners to hold file locks while someone’s trying to rob them.</p><h3>App-Bound Encryption bypass: A 20 KB reflective DLL</h3><p>Starting with Chrome 127 in July 2024, Google introduced <strong>Application Bound Encryption (ABE)</strong> – the browser’s master encryption key chained to the browser’s own process identity via a Windows Elevation Service COM interface. A neat trick. Credentials could only be decrypted from within a trusted browser process. It was the kind of lock that made honest people feel safe and dishonest people feel challenged.</p><p>Torg Grabber solved it with a lockpick that weighed exactly 19,968 bytes. A <strong>ChaCha20-encrypted Reflective DLL</strong>buried in the .rdata section like a razor blade in an apple.</p><p><em>See Appendix A, Figure A3</em></p><h4><em>The Encrypted Payload</em></h4><p>The DLL sits at a fixed offset in <code>.rdata</code> as an undifferentiated byte blob – no PE headers showing, nothing to catch the eye in static analysis. It might as well have been a patch of wallpaper. The parent function decrypts it in-place with a custom ChaCha20 implementation: hardcoded 256-bit key, 96-bit nonce, 312 blocks of 64 bytes. After decryption, the MZ and PE signatures emerge like a face surfacing in dark water, and the code walks the export directory looking for one specific string: ReflectiveLoader.</p><p>We extracted and decrypted the payload. It had the following particulars:</p>

<table class="table"><tbody><tr><td>Property</td><td>Value</td></tr><tr><td>Size</td><td>19,968 bytes (0x4E00)</td></tr><tr><td>Architecture</td><td>x64 PE32+</td></tr><tr><td>Compiler</td><td>GCC 15.2.0 (MSYS2 MinGW-w64)</td></tr><tr><td>Exports</td><td>ReflectiveLoader, GetIp</td></tr><tr><td>Sections</td><td>10 (.text, .data, .rdata, .pdata, .xdata, .bss, .edata, .idata, .tls, .reloc)</td></tr></tbody></table>

<p>The <code>ReflectiveLoader</code> export is textbook reflective injection: it walks backwards from <code>GetIp()</code> to find its own MZ header, resolves <code>LoadLibraryA</code>, <code>GetProcAddress</code>, and <code>VirtualAlloc</code> from kernel32.dll via PEB walking and ROR13 export name hashing, maps sections, processes relocations, resolves imports, flushes the instruction cache, and calls <code>DllMain</code>. Standard procedure. The kind of thing they’d teach in school if schools taught this sort of thing.</p><h4><em>Browser Detection and COM Elevation</em></h4><p>Once loaded, the DLL spawns a worker thread that reaches back to the parent through a named pipe and collects the ABE-encrypted key material. Then it figures out where it’s living. A call to <code>GetModuleFileNameW</code>, the path lowercased and matched against a list of known executables and installation directories – like a kidnapping victim recognizing the room by the wallpaper:</p>

<table class="table"><tbody><tr><td>Browser</td><td>Process / Path Match</td><td>Own CLSID</td><td>IID Variants</td><td>Vtable Offset</td></tr><tr><td><strong>Edge</strong></td><td>msedge.exe, \microsoft\edge\</td><td>{1FCBE96C-...}</td><td>2</td><td>+64</td></tr><tr><td><strong>Chrome</strong></td><td>chrome.exe, \google\chrome\</td><td>{708860E0-...}</td><td>3</td><td>+40</td></tr><tr><td><strong>Brave</strong></td><td>brave.exe, \brave-browser\</td><td>{576B31AF-...}</td><td>2</td><td>+40</td></tr><tr><td><strong>Avast</strong></td><td>avastbrowser.exe, \avast software\browser\</td><td>{EAD34EE8-...}</td><td>1</td><td>+40</td></tr><tr><td><strong>AVG</strong></td><td>avgbrowser.exe, \avg\browser\</td><td>{EDC3300F-...}</td><td>1</td><td>+40</td></tr><tr><td><strong>Vivaldi</strong></td><td>vivaldi.exe, \vivaldi\</td><td>Chrome’s CLSID</td><td>3</td><td>+40</td></tr><tr><td><strong>Opera</strong></td><td>opera.exe, \opera software\</td><td>Chrome’s CLSID</td><td>3</td><td>+40</td></tr></tbody></table>

<p>Each Chromium-based browser that implements ABE registers its own Elevation Service COM class with a browser-specific CLSID. The DLL carries five of these like a skeleton key ring: Chrome, Edge, Brave, Avast, AVG. For Vivaldi, Opera, and any unknown Chromium fork that wanders into the crosshairs, it falls back to Chrome’s CLSID and hopes for the best.</p><p>There’s a wrinkle, though, and it matters: <strong>Edge uses a different vtable layout</strong>. Extra methods in the interface push DecryptData to vtable offset +64 – method index 8 – instead of the standard +40, method index 5. Everyone else lines up neatly. Edge has to be different. The DLL handles this with a branch on browser type ID, because in this line of work, the details are what keep you out of trouble or put you in it.</p><p>After creating the COM object with CoCreateInstance(CLSCTX_LOCAL_SERVER), the DLL calls CoSetProxyBlanket with RPC_C_AUTHN_LEVEL_PKT_PRIVACY and EOAC_DYNAMIC_CLOAKING to set the security context, then invokes IElevator::DecryptData with the encrypted key wrapped in a BSTR. When it works – and it works more often than Google would like – the method hands back a 32-byte BSTR: the AES-256 master key. The keys to the kingdom, delivered through the kingdom’s own front door.</p><h4><em>The Response</em></h4><p>The decrypted master key is packed into a 44-byte response and written back through the named pipe, neat as a coroner’s report:</p>

<p>The DLL carries debug logging <code>– [DLL] Detected: Chrome, [DLL] Elevator object created with IID variant 2, [DLL] Master key extracted successfully! </code>– that gets buffered and sent back with the key. Development artifacts left in the production code, like a carpenter’s pencil marks under the paint. Sloppy, maybe, but also human. After the response goes through, the parent process terminates the suspended browser and uses the recovered master key to decrypt the Chromium <code>encrypted_key</code> from <code>Local State</code>, which unlocks the credential entries in <code>Login Data</code>, <code>Cookies</code>, and <code>Web Data</code>. The vault door swings open. Everything inside belongs to someone else.</p><h4><em>Corpus-Wide ABE Timeline</em></h4><p>The encrypted DLL blob runs hot with entropy in the PE’s&nbsp;.rdata section, and the parent binary always carries the string&nbsp;"<code>ReflectiveLoader</code>" – both traits as distinctive as a scar. We didn’t need to decrypt anything to spot ABE capability across all 139 samples. Automated triage told the story:</p><table class="table"><tbody><tr><td>Phase</td><td>Samples</td><td>ABE Bypass</td><td>Blob Size</td></tr><tr><td>Telegram Bot API (Dec 9–11)</td><td>25</td><td>None</td><td>–</td></tr><tr><td>GRAB TCP Protocol (Dec 17–20)</td><td>4</td><td>None</td><td>–</td></tr><tr><td>REST API, first build (Dec 18)</td><td>1</td><td>None</td><td>–</td></tr><tr><td>REST API, production (Dec 22+)</td><td>109</td><td><strong>All</strong></td><td>18–20 KB</td></tr><tr><td>GRABBER variant w/o ABE (Feb 3)</td><td>1</td><td>None</td><td>–</td></tr></tbody></table><p>The ABE bypass shipped with the very first dedicated C2 domain build – <code>attackzombie.com</code>, December 22, 2025 – and rode along in every REST API sample since. Not a later addition. A launch feature. The developers considered it essential equipment, the way a safecracker considers a stethoscope. The lone exception was a 122 KB <code>safeguss.com</code> sample from February 3 that looked more like a stripped loader than the full stealer – a scout, not the army.</p><p>The encrypted blob grew over time, the way a pickpocket’s ambition grows:</p><p><em>See Appendix A, Figure A4</em></p><p>The 18-to-19 KB growth around December 29 lines up with the addition of Avast and AVG Secure Browser CLSIDs. Two 20 KB blobs flickered into existence on January 26–27 and then vanished – an experimental build that got trimmed back, like a line of dialogue that didn’t make the final cut.</p><h3>Operator tags: Fingerprinting the MaaS customers</h3><p>Every REST API build carries an <strong>operator tag</strong> – a short string identifying the customer, sent as the first field in the C2 registration. A calling card. A signature on the dotted line. The tag is resolved through a two-tier mechanism: the malware checks the <code>GRABBER_TAG</code> environment variable first, and only falls back to a hardcoded default if the env var comes up empty:</p>

<p>In older builds, the fallback tag sits in .rdata between the mutex format string "<code>Local\%s</code>" and the C2 domain – as conspicuous as a name tag at a criminal convention. In newer builds, the compiler inlines short tags as <code>mov</code> immediates (e.g., <code>mov dword ptr [rip+disp], 73756564h</code> for “deus”), and the longest tags use <code>mov rax</code>, <code>imm64</code>. Even the machine code has an opinion about how to keep a secret.</p><p>At runtime, the resolved tag gets copied into a 640-byte registration structure and shipped off to <code>/api/auth</code> along with the machine’s vital statistics:</p>

<p>A brief experiment – five samples across three days in early February – pushed the idea further: the payload read <strong>everything</strong> from environment variables. <code>GRABBER_HOST</code>, <code>GRABBER_TAG</code>, <code>GRABBER_ANTI_SNG</code>,<code>GRABBER_ANTI_VM</code>, <code>GRABBER_STREAMING</code>. One binary to serve them all. A universal key. At first it looked like the experiment died after three days – subsequent builds went back to hardcoded domains and tags. But starting Feb 10, the env-var mechanism came back for good: <strong>every build from Feb 10 onward</strong> includes <code>GRABBER_*</code> env var support alongside hardcoded defaults, and the builder simultaneously switched all operators from plaintext <code>.rdata</code> strings to compiler-inlined <code>mov</code> immediates. A unified builder update. The stealer became truly operator-agnostic – the way a gun doesn’t care whose hand it’s in.</p><p>Across the corpus, we extracted over <strong>40 distinct operator tags</strong>. The most active:</p><table class="table"><tbody><tr><td>Count</td><td>Tag</td><td>Type</td><td>Domains Used With</td></tr><tr><td>42x</td><td>5197705037</td><td><strong>Telegram ID</strong> (confirmed)</td><td>gogenbydet.cc, technologytorg.com, bbcplay.top, playbergs.info</td></tr><tr><td>24x</td><td>8172045377</td><td><strong>Telegram ID</strong> (confirmed)</td><td>gogenbydet.cc, bbcplay.top, playbergs.info</td></tr><tr><td>24x</td><td>main1402_2</td><td>Date-encoded batch</td><td>evasivestars.com</td></tr><tr><td>19x</td><td>0902</td><td>Numeric (build ID?)</td><td>evasivestars.com</td></tr><tr><td>16x</td><td>5362456016</td><td><strong>Telegram ID</strong> (confirmed)</td><td>gogenbydet.cc, bbcplay.top, playbergs.info</td></tr><tr><td>15x</td><td>main1402</td><td>Date-encoded batch</td><td>evasivestars.com</td></tr><tr><td>14x</td><td>5551690712</td><td><strong>Telegram ID</strong> (confirmed)</td><td>gogenbydet.cc, bbcplay.top</td></tr><tr><td>9x</td><td>Main</td><td>Nickname</td><td>sinixproduction.com, startbuldingship.com, technologytorg.com</td></tr><tr><td>9x</td><td>578510323</td><td><strong>Telegram ID</strong> (confirmed)</td><td>gogenbydet.cc</td></tr><tr><td>7x</td><td>Den</td><td>Nickname</td><td>technologytorg.com, attackzombie.com</td></tr><tr><td>7x</td><td>7612929707</td><td>Numeric (unresolved)</td><td>gogenbydet.cc, bbcplay.top, playbergs.info</td></tr><tr><td>6x</td><td>Deus</td><td>Nickname</td><td>attackzombie.com, technologytorg.com, safeguss.com</td></tr><tr><td>5x</td><td>main2402_1</td><td>Date-encoded batch</td><td>evasivestars.com</td></tr><tr><td>4x</td><td>Gapi</td><td>Nickname</td><td>si-dodgei.digital, avanpost-fi.digital</td></tr><tr><td>3x</td><td>Gd</td><td>Initials</td><td>technologytorg.com, attackzombie.com</td></tr><tr><td>3x</td><td>7287445517</td><td><strong>Telegram ID</strong> (confirmed)</td><td>gogenbydet.cc</td></tr><tr><td>3x</td><td>main_new</td><td>Nickname</td><td>evasivestars.com, wulingyuanparkzone.com</td></tr><tr><td>3x</td><td>main2002_2</td><td>Date-encoded batch</td><td>evasivestars.com</td></tr><tr><td>3x</td><td>Meow</td><td>Nickname</td><td>si-dodgei.digital</td></tr><tr><td>2x</td><td>7488523544</td><td><strong>Telegram ID</strong> (confirmed)</td><td>playbergs.info</td></tr><tr><td>2x</td><td>8251115314</td><td>Numeric (unresolved)</td><td>playbergs.info</td></tr><tr><td>2x</td><td>7694683550</td><td>Numeric (unresolved)</td><td>gogenbydet.cc, playbergs.info</td></tr><tr><td>2x</td><td>main2</td><td>Nickname</td><td>technologytorg.com</td></tr><tr><td>2x</td><td>BB1</td><td>Nickname</td><td>safeguss.com</td></tr><tr><td>2x</td><td>main7</td><td>Nickname</td><td>evasivestars.com</td></tr><tr><td>2x</td><td>main2302_1</td><td>Date-encoded batch</td><td>evasivestars.com</td></tr><tr><td>2x</td><td>pb2</td><td>Nickname</td><td>safeguss.com</td></tr><tr><td>2x</td><td>deus_auto</td><td>Nickname</td><td>wulingyuanparkzone.com</td></tr><tr><td>2x</td><td>capha2</td><td>Nickname</td><td>safeguss.com</td></tr></tbody></table>

<p>Three kinds of tags now: <strong>nicknames</strong> (<code>den, deus, gd, tf, main, BB1, BattleBuild, capha2, pb2</code>) – the kind of names men give themselves when they think nobody’s looking. <strong>Date-encoded batch IDs</strong> (<code>main1402, main1402_2, main2002_2, main2302_1,main2402_1</code> – where the digits encode the build date as DDMM) – <code>evasivestars.com</code> alone received 74 samples through this mechanism, each tag a timestamp on a factory floor. And <strong>numeric Telegram user IDs</strong> that we confirmed by running eight of twelve through the TelegramDB OSINT database. The C2 panel uses the IDs to route stolen-goods notifications to the operator’s Telegram. The <code>main/main2/main5/main7/main_new/main10</code> progression suggests a developer tag, while the date-encoded variants (<code>main1402</code> = Feb 14 batch) indicate automated nightly builds. The deus lineage evolved through <code>deus_new3</code>, <code>deus_new4</code>, and <code>deus_auto</code> on <code>wulingyuanparkzone.com</code> – iterative testing, like a man trying on aliases until one fits.</p><h4><em>Unmasking the Operators</em></h4><p>Running the numeric tags through TelegramDB was like pulling masks off at a costume party. Underneath, the faces were about what you’d expect:</p><table class="table"><tbody><tr><td>Tag</td><td>Telegram Name</td><td>Username</td><td>Previous Usernames</td><td>Notable</td></tr><tr><td>5197705037</td><td><strong>F̲a̲s̲o̲L̲’</strong></td><td>@Pi55_0ff</td><td>@SCAMHERE1</td><td>Top operator, 42 samples. Previous username is a confession</td></tr><tr><td>8172045377</td><td><strong>финфанфун</strong></td><td>@ytcel</td><td>@zxcnork, @jxnxdxsxxm</td><td>24 samples. Russian display name</td></tr><tr><td>578510323</td><td><em>(hidden)</em></td><td>@mamontovv</td><td>@reportmamont, @mamont0w, @rukoeb_3000</td><td>9 samples. “Мамонт” = Russian for a scam victim. Premium</td></tr><tr><td>5551690712</td><td><strong>L1man</strong></td><td>@ezbonus22</td><td>@hydrosh0t, @lox3526tyrk</td><td>14 samples. “лох” = Russian for sucker</td></tr><tr><td>7287445517</td><td><strong>ANRILOV | PAYPAL</strong></td><td>@anrilovfck</td><td>@cryptowoma, @ebalvseh11</td><td>3 samples. Bio: “PAYPAL WORK | MALWARE MONSTER”. Premium</td></tr><tr><td>5362456016</td><td><strong>Tony Montana</strong></td><td>@scarface_logs</td><td>@G5zvkr</td><td>16 samples. Bio links @NoMetaRu (logs marketplace). Profile pic: Scarface still with “SCARFACE LOGS” overlay. Premium, DC4</td></tr><tr><td>7488523544</td><td><strong>123 1</strong></td><td>@scamsomebody</td><td>@declineeeeed, @dennnied1</td><td>2 samples. Username literally @scamsomebody. Previous names reference declining/denying – chargebacks? Premium</td></tr><tr><td>1527633244</td><td><em>(hidden)</em></td><td>@wordpress20</td><td>@teamphoenixs, @sneqixolod</td><td>1 sample. “teamphoenix” – possibly group-affiliated</td></tr><tr><td>7694683550</td><td><em>(not indexed)</em></td><td>–</td><td>–</td><td>2 samples. A ghost</td></tr><tr><td>8598114766</td><td><em>(not indexed)</em></td><td>–</td><td>–</td><td>1 sample</td></tr><tr><td>8251115314</td><td><em>(not indexed)</em></td><td>–</td><td>–</td><td>2 samples</td></tr><tr><td>8402108450</td><td><em>(not indexed)</em></td><td>–</td><td>–</td><td>1 sample</td></tr></tbody></table>

<p>The username histories read like a glossary of Russian cybercrime slang. “Мамонт” – mammoth – is what they call a scam victim, from the expression “мамонт пришел,” the mammoth has arrived. “Лох” – sucker, mark, the one holding the short end. @SCAMHERE1 needs no translation in any language. One operator’s public bio announces “PAYPAL WORK | MALWARE MONSTER” with the quiet pride of a man who put his occupation on his tax return. <code>@scarface_logs</code>– “Tony Montana” – links to <code>@NoMetaRu</code>, a logs marketplace, and uses a Scarface movie still with “SCARFACE LOGS” branding as a profile picture. Subtle as a brick through a window. The newest arrival, <code>@scamsomebody</code>, leaves even less to interpretation, with previous usernames <code>@declineeeeed</code> and <code>@dennnied1</code> suggesting chargeback fraud experience – the kind of resume you don’t put on LinkedIn. Four carry Telegram Premium – these aren’t burner accounts tossed after a single job. These are established identities, permanent residents in the Russian cybercrime neighborhood, the kind of people who pay rent and expect the landlord to fix the plumbing.</p><p>All eight resolved accounts were still publicly accessible at the time of writing (Mar 2026). Nobody had bothered to draw the curtains.</p><p>Several tags appear across multiple C2 domains. den shows up on builds for both <code>technologytorg.com</code> and <code>attackzombie.com.deus</code> spans three domains. Most strikingly, we observed a full <strong>domain rotation chain</strong> for the numeric-ID operators: <code>gogenbydet.cc</code> (Dec 22 – Feb 12) → <code>bbcplay.top</code> (Feb 12 – Feb 22) → <code>playbergs.info</code> (Feb 22 – present). Operators <code>5197705037</code>, <code>8172045377</code>, <code>5362456016</code>, <code>7612929707</code>, and <code>7694683550</code> all followed this migration path, like a parade of regulars moving to a new bar every ten days. New operators (<code>7488523544, 8251115314, 8402108450</code>) appeared directly on playbergs.info – fresh faces who never knew the old place. The tags identify <strong>operators</strong>, not infrastructure, and the seamless migration suggests the panel backend can redirect operators to new domains without breaking stride. The early Telegram and GRAB TCP builds predate the mechanism entirely – no tags, no calling cards, just the raw proto-malware feeling its way in the dark.</p><p>The env-var mechanism combined with hardcoded fallbacks is the smoking gun for the MaaS model. The builder can bake operator-specific values into the binary or delegate everything to the dropper, letting a single compiled payload serve any customer who walks through the door. It’s the franchise model, applied to crime.</p><h2>C2 infrastructure</h2><p>Eighteen C2 domains identified over twelve weeks, most tucked behind Cloudflare like witnesses in a protection program:</p><table class="table"><tbody><tr><td>Domain</td><td>Registered</td><td>Samples</td><td>Notes</td></tr><tr><td>gogenbydet.cc</td><td>Dec 22</td><td>74</td><td>Dominant Jan–Feb; operators migrated out</td></tr><tr><td>evasivestars.com</td><td>~Feb 2</td><td>74</td><td>Exploded via date-encoded batch builds</td></tr><tr><td>bbcplay.top</td><td>Feb 11</td><td>33</td><td>Active Feb 12–22; PDR registrar; fake Chrome installer delivery</td></tr><tr><td>technologytorg.com</td><td>Dec 24</td><td>33</td><td>Contains “torg” – where the name came from</td></tr><tr><td>playbergs.info</td><td>Feb 22</td><td>18</td><td>Current primary for numeric-ID operators; NiceNic registrar</td></tr><tr><td>attackzombie.com</td><td>Dec 16</td><td>10</td><td>First dedicated C2, the one that started it</td></tr><tr><td>safeguss.com</td><td>~Feb 3</td><td>7</td><td>Growing; operators pb2, capha2, BB1, deus</td></tr><tr><td>si-dodgei.digital</td><td>Dec 24</td><td>5</td><td>Stealer C2 for delivery chain; PDR registrar</td></tr><tr><td>wulingyuanparkzone.com</td><td>Feb 3</td><td>5</td><td>deus lineage operators; 22-char domain spans 3 mov immediates</td></tr><tr><td>sinixproduction.com</td><td>2021 (!)</td><td>3</td><td>An old domain with a new purpose</td></tr><tr><td>avanpost-fi.digital</td><td>~Feb 19</td><td>2</td><td>gapi operator (same as si-dodgei.digital); PDR registrar</td></tr><tr><td>50elk.com</td><td>Jun 2024 (!)</td><td>2</td><td><strong>Different C2 backend</strong> (/api/machine/set-files-r); NiceNic registrar; VT 10/93</td></tr><tr><td>new-app-techno.com</td><td>Feb 3</td><td>1</td><td>Operator File_23; Realtime Register (PDR reseller); Cloudflare</td></tr><tr><td>findyour-dreams.com</td><td>Dec 28</td><td>1</td><td>&nbsp;</td></tr><tr><td>startbuldingship.com</td><td>Jan 5</td><td>1</td><td>Typo: “bulding” – even criminals can’t spell</td></tr><tr><td>quick-neo.com</td><td>Oct 2025</td><td>1</td><td>/api/machine/set-files-r backend (earliest sample); pre-staged domain</td></tr></tbody></table>

<p>The C2 infrastructure tells a story of <strong>domain rotation</strong> – organized, deliberate, like a crew that knows when to move. gogenbydet.cc dominated from late January through early February, then operators migrated to <code>bbcplay.top</code> (Feb 12–22), which was in turn replaced by <code>playbergs.info</code> (Feb 22 – present). Meanwhile, evasivestars.com quietly became the highest-volume domain through automated batch builds with date-encoded operator tags, now tied with <code>gogenbydet.cc</code> at 74 samples each – a factory nobody noticed because it didn’t make noise. A separate infrastructure cluster uses <code>.digital</code> TLD domains (<code>si-dodgei.digital, avanpost-fi.digital</code>) registered through the same PDR registrar, both serving the <code>gapi/meow</code> operator. Combined with the operator tags and the <code>GRABBER_HOST</code> environment variable, the picture is clear enough to read without glasses: <strong>Malware-as-a-Service</strong>, a builder model where each customer gets a binary with their name and C2 address baked in. The twelve numeric operator tags – eight confirmed as live Telegram accounts – prove the panel routes stolen data notifications straight to the operator’s phone. The Telegram-only exfiltration model didn’t die; it evolved into a notification layer sitting on top of the REST API architecture. Old habits don’t die. They get promoted.</p><h3>Registrar clustering and WHOIS overlap</h3><p>Three major registrar clusters emerged, and the WHOIS data gave us a gift – direct registrant identity links across multiple domains, wrapped up with a bow:</p>

<table class="table"><tbody><tr><td>Registrar</td><td>Domains</td><td>WHOIS Registrant</td><td>VT Detections</td></tr><tr><td><strong>Global Domain Group</strong>#3956</td><td>technologytorg.com, safeguss.com, evasivestars.com</td><td>Redacted; all three registered within 6 weeks (Dec 24 – Feb 2)</td><td>11/93, 0/93, 0/93</td></tr><tr><td><strong>NiceNIC (HK)</strong> #3765</td><td>gogenbydet.cc, findyour-dreams.com, playbergs.info,50elk.com</td><td><strong>Same registrant name hash</strong> 1f8f4166599d23ee across all four; two email clusters: 9253e579452ffad5s@(gogenbydet/findyour-dreams) and 6eb609d996e182a6s@ (playbergs/50elk). 50elk.comregistered <strong>Jun 2024</strong> (pre-staged); Peru registrant.</td><td>1/93, 8/93, 2/93, 10/93</td></tr><tr><td><strong>Registrar.eu (NL)</strong>#1647</td><td>attackzombie.com</td><td>Whois Privacy Protection Foundation (NL)</td><td>8/93</td></tr><tr><td><strong>Dynadot</strong> #472</td><td>sinixproduction.com</td><td>Super Privacy Service LTD; domain from <strong>2021</strong>, repurposed Jan 2026</td><td>0/93</td></tr><tr><td><strong>Realtime Register (NL)</strong> #839</td><td>startbuldingship.com, new-app-techno.com</td><td>Finland / Germany (Thüringen); PDR reseller for new-app-techno.com; startbuldingship.com <strong>suspended</strong></td><td>0/93, 1/93</td></tr><tr><td><strong>PDR / PublicDomainRegistry</strong>#303</td><td>si-dodgei.digital,&nbsp;bbcplay.top,&nbsp;avanpost-fi.digital</td><td>GDPR-masked (Germany) / “Filip Cooper” (Seychelles); <strong>three C2 domains</strong> through same registrar; si-dodgei.digital and avanpost-fi.digital share .digital TLD and gapi operator</td><td>0/93, 0/93, 0/93</td></tr><tr><td><strong>Hostinger</strong> #1636</td><td>wulingyuanparkzone.com</td><td>Lithuania</td><td>0/93</td></tr><tr><td><strong>Dominet/Aliyun (HK)</strong>#3775</td><td>quick-neo.com</td><td>Malaysia; registered <strong>Oct 2025</strong> – 2 months before first sample</td><td>2/93</td></tr></tbody></table><p>The <strong>NiceNIC cluster</strong> was the strongest find – and it grew. All four domains share the exact same registrant name hash (<code>1f8f4166599d23ee</code>), split into two email-address pairs: <code>gogenbydet.cc/findyour-dreams.com</code> (email <code>9253e579452ffad5s@</code>, Hong Kong/Ohio registrants) and <code>playbergs.info/50elk.com</code> (email <code>6eb609d996e182a6s@</code>, Hong Kong/Peru registrants). The shared name hash proves all four were registered by the same individual despite claiming different countries. Same hand, same pen, four different post offices. Notably, <code>50elk.com</code> was registered in <strong>June 2024</strong> – eight months before the first Torg Grabber sample – and carries 10/93 VT detections with 2,000–4,000 daily malware hits, suggesting it was already in the business before being repurposed as a Torg Grabber C2. The Global Domain Group cluster includes three domains, all registered within a six-week window. The <strong>PDR cluster</strong> now holds three domains: <code>si-dodgei.digital</code> (Dec 24), <code>bbcplay.top</code>(Feb 11), and <code>avanpost-fi.digital</code> (Feb 19). The <code>.digital</code> pair is particularly telling – both serve the same <code>gapi/meow</code> operator and share the same TLD, confirming they’re managed by the same infrastructure operator. The <strong>Realtime Register </strong>cluster now includes two domains: <code>startbuldingship.com</code> (Jan 5, Finland, suspended) and <code>new-app-techno.com</code> (Feb 3, Germany/Thüringen), the latter sold through PDR as reseller – creating a cross-link to the PDR cluster, the way one lie always connects to another. The operation used eight registrars across Hong Kong, the US, the Netherlands, Germany, the Seychelles, Peru, Finland, and Lithuania – diversifying against takedowns the way a smart investor diversifies against market crashes.</p><p>Three domains stuck out like sore thumbs in a velvet glove:</p><ul><li data-list-item-id="ee891671d04e4d6332b6927e95f08c327"><code><strong>sinixproduction.com</strong></code> was registered in January 2021 – five years before Torg Grabber drew its first breath. Its nameservers were switched to Cloudflare on January 13, 2026. An acquired domain, or a compromised one. Either way, it had a past, and its past wasn’t in malware.</li><li data-list-item-id="e131fd0d8f98bd4f1e3ca771a168a134d"><code><strong>50elk.com</strong></code>, registered June 17, 2024 via NiceNic, carried 2,000–4,000 daily malware hits in our domain reputation data before Torg Grabber even existed. Deep analysis in IDA Pro reveals these builds use a <strong>completely different C2 backend</strong> – <code>POST /api/machine/set-files-r</code> with multipart form-data uploads – rather than Torg Grabber’s native REST API. Despite the different exfiltration protocol, the binaries share the full <code>GRABBER_*</code> environment variable framework, anti-VM/anti-CIS checks, and mutex pattern. They self-identify as "<code>grabber v1.0</code>" with plaintext debug messages in <code>.rdata</code>. See <em>A Parallel Backend:&nbsp;</em><code><em>/api/machine/set-files-r</em></code> for details.</li><li data-list-item-id="e364e8168c3762cb784cdc65306447ebf"><code><strong>quick-neo.com</strong></code>, registered October 30, 2025, pre-dates all known samples by six weeks and carries a Cloudflare Radar rank of 10,000 and a Cisco Umbrella rank of ~242,000. IDA Pro analysis confirms its December 18 sample uses the same <code><strong>/api/machine/set-files-r</strong></code><strong> backend</strong> as the <code>50elk.com</code> builds – making it the earliest known sample with this protocol, from the same week the REST API transition began. See <em>A Parallel Backend:&nbsp;</em><code><em>/api/machine/set-files-r</em></code><em> </em>for details.</li></ul><h3>The GRAB TCP server</h3><p>The two experimental GRAB protocol domains –&nbsp;<code>bk.tara.net.bd</code> and&nbsp;<code>raketa.tara.net.bd</code> – resolve to&nbsp;<code>190.92.174.248</code>, hosted by <strong>WHG Hosting Services Ltd</strong> (AS199404, UK company, IP geolocated to India). Unlike the REST API domains, this one isn’t hiding behind Cloudflare. It uses a Let’s Encrypt wildcard for&nbsp;<code>*.tara.net.bd</code> and shares the server with&nbsp;<code>potshilpo.shop</code>, a Bangladesh-based domain. Shared hosting. The developer phase, where you don’t yet have the budget or the paranoia for dedicated infrastructure. BitDefender and G-Data flag&nbsp;tara.net.bd as malware. Someone noticed, even if not everyone.</p><h3>What VT sees: Distribution and delivery</h3><p>VirusTotal’s communicating files for the three busiest C2 domains tell the story of how Torg Grabber reaches its victims. The delivery mechanism is the oldest trick in the book, dressed up with a fresh coat of paint: trojanized installers, ZIP-packaged lures, digital candy left on the doorstep.</p><p><strong>Fantasy-themed lures</strong> (<code>technologytorg.com</code>): The ten most recent communicating files are 87–113 MB ZIP installers wearing auto-generated fantasy names like costumes at a masquerade:&nbsp;<code>Aerovora.zip</code>,&nbsp;<code>Nebulax.zip</code>,&nbsp;<code>Pyroxis.zip</code>,&nbsp;<code>Ignisyn.zip, Aetherion.zip</code>,&nbsp;<code>Zephyrion.zip</code>,&nbsp;<code>Aquathea.zip</code>,&nbsp;<code>Nebulynx.zip</code>,&nbsp;<code>Luminavora.zip</code>. The naming convention had the mechanical creativity of a builder script that read too many sci-fi paperbacks.</p><p><strong>Pirated software lures</strong> (<code>gogenbydet.cc</code>): Multiple 166 MB ZIPs labeled&nbsp;<code>Terraria_1.4.5.zip</code> and&nbsp;<code>Setup.zip</code> – bait for people who want something for nothing, which is most people. A smaller&nbsp;loader <code>.zip</code> at 31 MB suggested a more targeted delivery chain, something with a shorter fuse.</p><p><strong>Numeric-ID lures</strong> (<code>attackzombie.com</code>): Smaller 3 MB ZIPs with numeric filenames –&nbsp;<code>24323350</code>,&nbsp;<code>24353240</code>,&nbsp;<code>24427545</code> – plus&nbsp;installer <code>.zip</code>. A simpler naming scheme from the earliest REST API domain, back when the operation was still figuring out its wardrobe.</p><p><strong>Droppers on disk</strong> turn up as randomly-named executables in&nbsp;<code>C:\Windows\:&nbsp;v4jkqh.exe</code>,&nbsp;<code>hkjpy08.exe</code>,&nbsp;<code>we4osct.exe</code>, <code>bfp2w6.exe</code>. The naming pattern of a crypter or loader that doesn’t want to be remembered – digital aliases, disposable as matchbook covers.</p><p><strong>VT label noise</strong>: The communicating files are variously tagged&nbsp;<code>Trojan.dacic/vidar</code>,&nbsp;<code>trojan.aotera</code>,&nbsp;<code>trojan. cryptagen</code>t, and even&nbsp;<code>trojan.aotera/rhadamanthys</code> – a mess of misattribution that brought Torg Grabber to our attention in the first place. None of these labels fit. They reflect the industry’s reflex of pinning unknown stealers to familiar family names, the way a police sketch ends up looking like everybody and nobody.</p><p>All dedicated C2 domains share the same Cloudflare JARM fingerprint (<code>27d40d40d00...525c</code>) and use Google Trust Services TLS certificates. Matching suits. Same tailor.</p><h2>Attribution: Following the Telegram trail</h2><p>The 19 early Telegram-exfiltrating samples came with hardcoded bot tokens and channel IDs, carried openly in the binary like monogrammed luggage at an airport. By querying the Telegram Bot API, we obtained bot metadata, channel information, and – the prize – the <strong>Telegram accounts of the channel creators</strong>. The people who set up the drops. The hands behind the curtain.</p><p><em>See Appendix A, Figure A5</em></p><h3><em>The Bots</em></h3><table class="table"><tbody><tr><td>Bot</td><td>Username</td><td>Status</td></tr><tr><td>8247426625</td><td>@trtest12bot</td><td>Live</td></tr><tr><td>8284437818</td><td>@gr_bot_life_bot</td><td>Live</td></tr><tr><td>8456437646</td><td>@lalllaland_bot</td><td>Live</td></tr><tr><td>8471726820</td><td>@palayodd_bot</td><td>Live</td></tr><tr><td>4 others</td><td><em>(unknown)</em></td><td>Revoked</td></tr></tbody></table><p>Four bots still alive and ticking, tokens unrevoked, as of February 8, 2026. All eight channels private, two to three members each – the bot and one or two humans. Small operations. Tight circles. The kind of crew where everyone knows everyone and nobody knows anyone outside.</p><h3>The Operators</h3><p>Each exfiltration channel has a creator – the Telegram account that set up the room and invited the bot. We found four:</p><table class="table"><tbody><tr><td>Username</td><td>Display Name</td><td>User ID</td><td>Channel</td><td>Notable</td></tr><tr><td><strong>@ChaChaGuru</strong></td><td>Pope Robinson</td><td>7863185848</td><td>“BkChannel”</td><td><strong>ChaCha20 in the username</strong></td></tr><tr><td><strong>@OneCC_team</strong></td><td>OneCC</td><td>7983438838</td><td>“playodd”</td><td>Bio: “Selling CC&gt;First hand&gt;Sniffed”</td></tr><tr><td><strong>@the_01G</strong></td><td>X I</td><td>7960359642</td><td>“land”</td><td>&nbsp;</td></tr><tr><td><em>(none)</em></td><td>Lauriev Hontisorknnd</td><td>8214631236</td><td>“1 kanal”</td><td>“1 kanal” = “channel 1” – the test run</td></tr></tbody></table>

<p><strong>@ChaChaGuru</strong> was the lead we couldn’t ignore. The username is a direct reference to <strong>ChaCha20</strong> – the stream cipher that runs through Torg Grabber’s veins like blood type. It encrypts the C2 payloads. It protects the GRAB protocol. It wraps the shellcode. And the “Bk” in “BkChannel” matches <code>bk.tara.net.bd</code>, the GRAB TCP domain. Two connections. Both pointing the same direction. This wasn’t circumstantial evidence; it was a man leaving his business card at the scene.</p><p><strong>@OneCC_team</strong> presented as a group identity, and their public bio – “Selling CC&gt;First hand&gt;Sniffed” – was an open advertisement for stolen credit card sales. Not even coded. Just stated, plainly, the way a butcher advertises pork chops. Their profile photo history traced a career arc from an Amazon delivery truck through “OMG” and Bitcoin/AML imagery to a Guy Fawkes mask – a trajectory from e-commerce fraud through cryptocurrency crime to the anonymous hacking persona, documented in selfies.</p><p>All four creator accounts carry user IDs in the 7.8–8.2 billion range – created in the same timeframe, shortly before the bots themselves. The channel called “1 kanal” (Russian for “channel 1”) by “Lauriev Hontisorknnd” – a name as fabricated as a three-dollar bill – was the test channel. The first attempt. The rough draft.</p><h2>What Torg Grabber steals</h2><p>The stealer’s appetite is broad, and it’s getting broader. It wants everything, and it’s not shy about asking.</p><p>Here’s the rap sheet:</p><ul><li data-list-item-id="e6c94f8f1812a2022dd1d2f3d7da713fc"><strong>Browser credentials</strong>: 25 Chromium-based browsers (Chrome, Edge, Brave, Opera, Vivaldi, Yandex, CocCoc, CryptoTab, and 17 others that never thought they’d end up on a list like this) and 8 Firefox-family browsers, with AES-GCM, DPAPI, and ABE support. Plus harvesting of credentials previously extracted by the <strong>“Underground” tool</strong> – a standalone credential extraction tool whose output Torg Grabber scavenges like a jackal following a lion (see below)</li><li data-list-item-id="e189ced2b07dbbe824fef40f0391ad7f0"><strong>Browser extensions – 850 total</strong>: Three hardcoded lists. <strong>728 wallet extensions</strong> covering every crypto wallet from MetaMask and Phantom down to ShibaWallet and xMetaCene. <strong>103 password/2FA extensions</strong> – LastPass, 1Password, Bitwarden, and every authenticator app that ever tried to keep someone safe. <strong>19 notes extensions</strong>, because sometimes people write their passwords on sticky notes, even digital ones. Full lists in the&nbsp;<a href="https://github.com/gendigitalinc/ioc" target="_blank">IOC repository</a></li><li data-list-item-id="e902a0534ddd9db1b31ca1626e07310a9"><strong>Desktop wallets</strong>: 30+ standalone applications – Exodus, Atomic, Electrum, Monero, Daedalus. The whole menagerie</li><li data-list-item-id="e8584d6b90fd45056b2e40596641095c2"><strong>Messaging</strong>: Discord tokens (LevelDB scanning), Telegram session data, Steam configs</li><li data-list-item-id="ea137fd09ecd26e88aaf53686e2757bc6"><strong>Credentials</strong>: VPN configs from 8 providers, FTP clients (5), email (Thunderbird, Outlook), password managers (7), gaming platforms (6)</li><li data-list-item-id="ef207f85eab7a553a1507c70c0dd6959d"><strong>System profiling</strong>: Hardware fingerprint, installed software, process list, screenshot, environment variables, and <strong>AV detection</strong> scanning 46 process signatures across 24 products – Kaspersky, Avast, ESET, CrowdStrike, SentinelOne, Windows Defender. It wants to know who’s watching before it starts working, the way a burglar checks for dogs before climbing the fence</li><li data-list-item-id="eaec55d241c9ae2b5988c1e458dd1ac8c"><strong>File grabbing</strong>: Pattern-based collection from Desktop and Documents with C2-configurable rules</li><li data-list-item-id="e5c1348e1d786ad029539f7c229d1606d"><strong>Arbitrary code execution</strong>: The C2 can deliver ChaCha-encrypted, zlib-compressed shellcode at registration. Just in case everything else wasn’t enough</li></ul><h2>850 browser extensions: Casting the widest net</h2><p>Perhaps the most striking thing about Torg Grabber isn’t what it does, but how much of it there is. Eight hundred and fifty extension IDs, hardcoded into the binary, organized into three tidy categories like a catalog for a store that sells things that don’t belong to it:</p><table class="table"><tbody><tr><td>Category</td><td>Count</td><td>Archive Path</td><td>What They Steal</td></tr><tr><td><strong>Wallet</strong></td><td>728</td><td>Wallet/Extension/</td><td>Crypto wallet seeds, keys, session data</td></tr><tr><td><strong>Password/2FA</strong></td><td>103</td><td>Password/</td><td>Password vaults, TOTP secrets, MFA tokens</td></tr><tr><td><strong>Notes</strong></td><td>19</td><td>Notes/</td><td>Saved notes – and the passwords people hide in them</td></tr></tbody></table><p>The <strong>728 wallet extensions</strong> cover essentially every crypto wallet ever conceived by human optimism. The marquee names are all there – MetaMask, Phantom, TrustWallet, Coinbase, Binance, Exodus, TronLink, Ronin, OKX, Keplr, Rabby, Sui, Solflare. But the list doesn’t stop at the big names. It keeps going, deep into the long tail, past projects with install counts you could fit in a phone booth – ShibaWallet, xMetaCene, Elli Sui Wallet. The kind of thoroughness that suggests the list was scraped from the Web Store rather than curated by hand. Nobody sits down and types 728 extension IDs one by one. Not even a criminal.</p><p>The <strong>103 password extensions</strong> are equally comprehensive. The majors – LastPass, 1Password, Bitwarden, KeePass, NordPass, Dashlane, ProtonPass, Enpass – plus niche products like Psono, Pleasant Password Server, and heylogin. And here’s the twist: <strong>31 two-factor authentication extensions</strong> are in the mix. 2FAAuth, GAuth, TOTP Authenticator, Akamai MFA. The stealer doesn’t just want the password. It wants the second factor too. The lock and the key and the deadbolt and the chain. Everything that stands between the victim and complete exposure.</p><p>For each matched extension, the malware vacuums data from three locations: 1. <code>Local Extension Settings/</code> – the extension’s LevelDB storage 2. <code>IndexedDB/</code> – any IndexedDB databases matching the extension ID 3. <code>Sync Extension Settings/</code> – synced data, if the user has Chrome Sync enabled</p><p>The archive paths include a DJB2 hash of the browser name – <code>Wallet/Extension/MetaMask/C-Chrome-a1b2c3d4/</code> – to keep stolen credentials from different browsers filed separately. Organized crime, in the most literal sense.</p><p>The full extension lists are published in the IOC repository. Defenders and extension developers can use them. Everyone else can marvel at the ambition.</p><h2>Harvesting a previous tool: “Underground”</h2><p>Early Torg Grabber builds contained code to harvest credentials from <code>C:\ProgramData\Underground</code> – a path that, at first glance, had the look of an anti-detect browser’s home directory. We spent some time chasing that theory. Turns out we were looking at it wrong. The way you sometimes look at a shadow on the wall and see a man, but when the light shifts it’s just a coat on a hook.</p><h3>What “underground” really is</h3><p>We recovered a number of&nbsp;<code>C:\ProgramData\Underground\logs.txt</code> files from infected machines. The logs told a different story. “Underground” isn’t a browser at all. It’s a <strong>standalone credential extraction tool</strong> with a two-stage architecture that bears a family resemblance to Torg Grabber’s own ABE bypass – the kind of resemblance that makes you check if they had the same father:</p><ol><li data-list-item-id="eaebbd3d4aa7deb4f016350202282ff88"><strong>Host process</strong> (injector) – enumerates installed browsers, creates a suspended browser process, performs reflective DLL injection, and talks to the injected payload through named pipes</li><li data-list-item-id="e0bdeb938b3bb7a840a901fe1addec28c"><strong>Injected DLL</strong> (reflective loader) – runs inside the browser process, decrypts the ABE-protected master key via Chrome’s COM Elevator service, then dumps credentials to JSON files</li></ol><p>The log output documents the full chain: browser enumeration, suspended process creation, ReflectiveLoader injection, named pipe setup (<code>\\.\pipe\chrome.nacl.*,&nbsp;\\.\pipe\mojo.*</code>), ABE key decryption via COM, profile enumeration, and credential extraction. It writes its take as JSON files and plaintext token files to&nbsp;<code>C:\ProgramData\Underground</code>. Neat. Professional. The kind of work that leaves receipts.</p><h3>What Torg Grabber harvests</h3><p>When Torg Grabber finds this directory – and on machines where the operators have been running their toolkit, it will – it parses three types of JSON output files left behind by the Underground tool:</p><ol start="3"><li data-list-item-id="e2607892443ff28f869bd1fa195fa5a42"><strong>Passwords</strong> –&nbsp;{<code>"origin":"..."</code>} objects with URLs, usernames, and passwords</li><li data-list-item-id="e0281f0bdf9f4fa2e26ba0e5c099a8086"><strong>Cookies</strong> –&nbsp;{<code>"domain":"..."</code>} objects with full cookie metadata</li><li data-list-item-id="eb155f96476575ab11879fc30506733c4"><strong>Payment cards</strong> –&nbsp;{<code>"card_number":"..."</code>} objects with card details</li></ol><p>It also collects three token files (<code>gaming_tokens.txt</code>,&nbsp;<code>media_tokens.txt</code>,&nbsp;<code>social_tokens.txt</code>) containing session tokens for various platforms. Double-dipping. Credentials that were already extracted once, stolen again for the archive.</p><h3>The connection</h3><p>The architectural overlap between Underground and Torg Grabber is the kind of thing that makes you sit up in your chair. Both use reflective DLL injection into suspended browser processes. Both use named pipe IPC. Both do COM-based ABE bypass. The blueprints are close enough to be cousins.</p><p>But the DLL-side log strings are completely different – Torg Grabber’s&nbsp;<code>abe_decrypt.dll</code> uses&nbsp;[<code>DLL</code>] prefixed messages that don’t appear anywhere in Underground’s logs, and the host-side injector strings from Underground are absent from&nbsp;<code>abe_decrypt.dll</code>. Different binaries. Same school of thought. This rules out a shared executable but points toward a shared codebase, a common author, or tools from the same ecosystem – bought from the same shelf in the same underground marketplace.</p><p>The working hypothesis: the operators who deploy Torg Grabber also ran the Underground tool on infected machines – either as a precursor or running alongside. Torg Grabber’s JSON parsers then scavenge whatever Underground left behind, like a second shift coming in to clean out what the first shift missed. This is consistent with the MaaS model: operators run multiple tools, and a good stealer picks up everything, even another tool’s leftovers.</p><h3>The CIS cleanup twist</h3><p>When the malware detects a CIS locale – Russia, Ukraine, Belarus, Kazakhstan, and the rest of the old neighborhood – it doesn’t merely skip collection. It actively <strong>deletes the entire Underground directory</strong>:</p>

<p>On CIS machines, this erases the Underground tool’s logs and extracted credentials – destroying evidence of the operators’ own activities. Not protecting fellow criminals’ data. Covering their own tracks. The kind of cleanup you do when you’ve been in someone’s house and you want to make sure nobody knows you were there.</p><h3>Gone in a day: The underground-to-ABE swap</h3><p>Corpus-wide analysis turned up a fact as clean and cold as a knife: Underground harvesting and the ABE bypass are <strong>perfectly mutually exclusive</strong>. Not a single sample in 139 builds contains both.</p><table class="table"><tbody><tr><td>Feature</td><td>Samples</td><td>Date Range</td><td>Binary Size</td></tr><tr><td>Underground harvesting</td><td>30</td><td>Dec 9 – Dec 20</td><td>265 – 525 KB</td></tr><tr><td>ABE bypass</td><td>109</td><td>Dec 22 – Feb 7</td><td>411 – 747 KB</td></tr><tr><td>Both</td><td><strong>0</strong></td><td>–</td><td>–</td></tr></tbody></table><p>The last Underground build compiled on <strong>December 20 at 15:45 UTC</strong>. The first ABE bypass build appeared <strong>38 hours later</strong>, on <strong>December 22 at 06:32 UTC</strong>. Not a gradual transition. Not a slow fade. A clean break. One feature walked out the door and another walked in, and they didn’t even pass each other in the hallway.</p><p>The logic reads like a business decision – and it was one. Once Torg Grabber gained its own built-in ABE bypass, there was no longer any need to scavenge credentials from a separate tool. The developers replaced a dependency on external tooling with native capability, the way a restaurant that used to buy bread from down the street puts in its own oven. The timing lines up with the December 22 pivot to production REST API infrastructure. Everything changed at once, because when you’re going to jump, you might as well jump with both feet.</p><h2>A parallel backend: /api/machine/set-files-r</h2><p>Three samples. Two domains. A completely different C2 protocol than the rest of the corpus, and yet the same malware framework underneath — like finding two different keys in the same man’s pocket, both opening different doors. <code>quick-neo.com</code> in December, <code>50elk.com</code> in February. This wasn’t some late experiment cooked up after the main line had settled. The quick-neo.com sample landed the same week the REST API transition began. The <code>/api/machine/set-files-r</code> backend was running in parallel from day one. Two horses in the same race, and nobody had bothered to tell the program.</p>

<table class="table"><tbody><tr><td>Date</td><td>Domain</td><td>Backend</td><td>Size</td><td>Features</td></tr><tr><td>Dec 18, 2025</td><td>quick-neo.com</td><td>machine_api</td><td>266 KB</td><td>Underground browser, no ABE, plaintext .rdata</td></tr><tr><td>Feb 17, 2026</td><td>50elk.com (×2)</td><td>machine_api</td><td>712 KB</td><td>GRABBER_* env vars, ABE bypass, plaintext .rdata</td></tr></tbody></table><p>The jump from 266 KB to 712 KB — nearly triple — and the feature additions along the way — ABE bypass, env vars, string encryption — mirror the main Torg line’s evolution over the same stretch. Same playbook. Different stage. This wasn’t a dead fork. Somebody was feeding it.</p><h3>What they share with standard Torg Grabber</h3><p>The familiar framework is present across both:</p><ul><li data-list-item-id="ecb3e00d261e86a6cb95c41e9b031c88e">Anti-analysis: GPU-based anti-VM (EnumDisplayDevicesA against vendor blocklist), locale-based anti-CIS (GetLocaleInfoA against blocklist), Local{MachineGuid} mutex.</li><li data-list-item-id="e180593968c5d6e901e25c4c1c5a2b0af">Build tag: “grabber v1.0” – logged at startup alongside a timestamp.</li><li data-list-item-id="ed0b237a6f1f9890c06b46a4f380da80d">GRABBER_* environment variables (Feb 17 builds only): GRABBER_HOST, GRABBER_TAG, GRABBER_ANTI_SNG, GRABBER_ANTI_VM, GRABBER_STREAMING, GRABBER_HWID, GRABBER_GPU, GRABBER_SESSION – same set, same defaults (HWID → c479d3ea-cedd-43ef-af74-dc6163e5dad7, GPU → Radeon RX550/550 Series). The Dec 18 build pre-dates the env var mechanism.</li></ul><h3>What is different: The C2 protocol</h3><table class="table"><tbody><tr><td>&nbsp;</td><td>Standard Torg Grabber</td><td>machine_api builds</td></tr><tr><td><strong>Registration</strong></td><td>POST /api/auth with HWID, operator tag, ChaCha20 key exchange</td><td>Stubbed out – auth function returns 1unconditionally</td></tr><tr><td><strong>Upload endpoint</strong></td><td>/api/upload/chunk (chunked), /api/stream/*</td><td>POST /api/machine/set-files-r</td></tr><tr><td><strong>Content type</strong></td><td>ChaCha20-encrypted + HMAC-SHA256 authenticated chunks</td><td>Multipart form-data (boundary=----UploadBoundary9876543210)</td></tr><tr><td><strong>Upload field</strong></td><td>Encrypted binary stream</td><td>zip_file – raw ZIP bytes</td></tr><tr><td><strong>Port</strong></td><td>443 (HTTPS via Cloudflare)</td><td>443 (HTTPS, direct – no Cloudflare)</td></tr><tr><td><strong>User-Agent</strong></td><td>Custom ("Mozilla/5.0 ... grabber/1.0" variants)</td><td>Plain "Mozilla/5.0"</td></tr><tr><td><strong>Error handling</strong></td><td>Retry with exponential backoff</td><td>HTTP 200 → success; 403/400 → abort immediately</td></tr><tr><td><strong>Archives sent</strong></td><td>Single encrypted stream</td><td>Two separate uploads: main.zip, files.zip</td></tr></tbody></table><p>&nbsp;</p>

<p>The /api/machine/set-files-r endpoint does not match any publicly documented stealer family’s C2 protocol. A ghost in the machine, and the machine wasn’t talking.</p><h3>The Collection pipeline</h3><p>Standard Torg sends single encrypted archive; machine_api builds construct two ZIP archives with distinct folder layout:</p>

<p>files.zip: Additional file grabber results.</p><p>The collection functions produce numbered debug log entries ([1] Creating ZIP buffer…, [2] Generating UserInfo…, etc.) — more structured than standard Torg’s free-form debug strings. The kind of organization that suggests someone was keeping score.</p><h3>Plaintext strings throughout</h3><p>Unlike the main Torg line — which progressively moved from plaintext .rdata to compiler-inlined mov immediates — both machine_api samples keep all strings as plaintext in .rdata. C2 domain, endpoint path, debug messages like “[#] Killed ALL %s processes: %d”. Everything out in the open. This branch never got the string hardening. Either they didn’t care, or they didn’t get the memo.</p><h3>Interpretation</h3><p>The quick-neo.com discovery settles the timeline. The&nbsp;/api/machine/set-files-r backend isn’t a late experiment — it’s contemporary with the earliest REST API builds. December 18 is the same day attackzombie.com samples first appeared. Two backends shipped from the same codebase on the same day. Like a man with two passports, both valid.</p><p>The ten-week gap between quick-neo.com (Dec 18, 266 KB) and 50elk.com (Feb 17, 712 KB) tells the rest of the story. The machine_api line tracked the main Torg evolution: ABE bypass added, env var framework integrated, binary nearly tripled in size. Not a dead fork. Actively maintained. Parallel development, same hands on both levers.</p><p>Two readings remain:</p><ol><li data-list-item-id="ef532baab10f732e03509e783ce1da74d">Operator-specific panel. Under the MaaS model, one customer runs a panel at /api/machine/set-files-r while the majority use the standard REST API panel.</li><li data-list-item-id="e55b3be61fa9f659eea94c15d688dc7fe">Developer’s own backend. The /api/machine/set-files-r panel is the developer’s original infrastructure, while the REST API was built for the MaaS product.</li></ol><p>Either way, the GRABBER_* environment variable framework and anti-analysis suite are the stable identity anchors — they persist across different C2 backends, string protection schemes, and collection pipeline layouts. The backend protocol itself is modular and swappable. The face changes. The fingerprints don’t.</p><h2>Conclusion</h2><p>Torg Grabber is a case study in velocity. Three months from prototype to production. Four exfiltration mechanisms tried – Telegram Bot API, GRAB TCP, REST API, and the parallel <code>/api/machine/set-files-r backend</code> – each one a rung on a ladder that only goes up. Eighteen C2 domains across eight registrars. A binary that nearly tripled in size while its developers were still registering the domains it would phone home to. It was like watching someone build an airplane while it was already taxiing down the runway.</p><p>The Telegram breadcrumbs left behind by the early builds – bot tokens, channel metadata, and an operator whose username literally namedrops the malware’s signature encryption algorithm – provided a window into the human side of the operation. These aren’t ghosts. They’re people, with Telegram Premium subscriptions and public bios that read like job applications for a criminal enterprise.</p><p>By resolving the numeric operator tags through OSINT databases, we put faces to eight of twelve MaaS customers. The faces weren’t pretty. Usernames referencing scamming (@SCAMHERE1, @scamsomebody), victims (<code>@mamontovv</code>, from “мамонт” – the mammoth, the mark, the one who showed up), suckers (<code>@lox3526tyrk</code>, from “лох” – the word speaks for itself), and stolen-credential marketplaces (<code>@scarface_logs</code> linking to <code>@NoMetaRu</code>). Four carry Telegram Premium – established actors, not disposable identities. Combined with the developer accounts recovered from the bot tokens, the picture is unusually complete. Both sides of a MaaS operation, buyer and seller, laid out under the light.</p><p>The observed delivery chain tells its own story – from a ClickFix clipboard attack hosted on Google Apps Script, through a multi-stage PowerShell stager with a fake progress bar and XOR-encrypted BITS transfers, to three polymorphic MinGW loaders served from disposable .pw domains. The delivery infrastructure is as carefully engineered as the stealer itself. Strict role separation between domains – stagers on j0o.pw, encrypted loaders on t4e.pw/re3.pw, exfiltration on the main C2 cluster – provides operational resilience: burning one domain doesn’t touch the others. The use of trusted platforms (Google Apps Script, Dropbox) for initial access and server-side polymorphism for loader generation makes static blocking about as effective as putting up a “No Trespassing” sign at a public park.</p><p>The family remains under active development. New C2 domains registered weekly. Builds compiled daily – 334 samples and counting, each one a fresh fingerprint. The operator base growing, 40+ tags and rising, new customers walking through the door. What initially looked like a three-day experiment with environment-variable configuration has since become the standard: every build from Feb 10 onward ships with <code>GRABBER_*</code> env var support and compiler-inlined string assignments, replacing the earlier plaintext <code>.rdata</code> approach. The most significant operational shift is the <strong>domain rotation chain</strong> (<code>gogenbydet.cc</code> → <code>bbcplay.top</code> → <code>playbergs.info</code>), where entire operator groups migrate to fresh infrastructure roughly every ten days – a cadence that makes domain-based blocking a losing game. Meanwhile, <code>evasivestars.com</code> has become a mass-build factory with date-encoded batch tags, suggesting automated deployment pipelines. We’ll keep watching. These are the kind of people who don’t stop until someone stops them.</p>

A newly identified MaaS credential stealer evolves from Telegram exfiltration to encrypted TCP and full REST API infrastructure

Torg Grabber: Anatomy of a New Credential Stealer 

<p>In the world of cybercrime, the best disguise is often just another criminal. Sometimes, a new threat will wrap itself in the "uniform" of a well-known group to avoid extra scrutiny. That is exactly how our story begins.</p><p>On a quiet Tuesday in February, a routine sample landed in our lab. At first glance, it appeared to be "Vidar," which is a common and widely understood type of malware. However, as our researchers began to look under the hood, the Vidar costume started to fall apart. This was not the work of a known group. It was something entirely new, highly sophisticated, and growing with incredible speed. We named it <strong>Torg Grabber</strong>.</p><h4>The mystery of the misclassification</h4><p>Detecting malware is often like recognizing a person by their gait or their handwriting. Vidar has a very specific "look" in its code. But this new sample was different. It was built with different tools, used different encryption, and spoke a completely different language when communicating with its creators.</p><p>Our team realized that Torg Grabber was essentially a digital pickpocket wearing a priest’s collar. By pretending to be a common threat, it hoped to fly under the radar of automated security systems. By the time we finished our investigation, we had uncovered 334 different versions of this malware, all created in a span of just three months. This was not a hobbyist at work: it was a production line.</p><h4>The evolution of a criminal business</h4><p>One of the most fascinating parts of this story is how the criminals behind Torg Grabber "upgraded" their business. We tracked three distinct phases of their growth.</p><p>In the beginning, they were small and cautious. They used simple Telegram bots to ship stolen data back to private chat channels. This was the digital equivalent of a rookie thief shouting secrets across a crowded room. It worked, but it was noisy and easy to shut down.</p><p>Only a few weeks later, they moved into an experimental phase. They created a custom, high speed communication protocol that used advanced military grade encryption. It was sophisticated, but it was also difficult for them to manage at a large scale.</p><p>Finally, they settled on what we call the "Production Rig." They built a professional grade system that hides its traffic behind legitimate web services like Cloudflare. This makes their malicious activity look like normal web browsing. By the time they reached this stage, Torg Grabber had become a "Malware as a Service" operation, where the developers sell their "product" to dozens of other criminals who want to get into the game.</p>

<h4>The "ClickFix" trap: how they get in</h4><p>Torg Grabber does not just break into your house: it tricks you into opening the door. Our team observed a clever tactic called "ClickFix."</p><p>Imagine visiting a website and seeing a pop up that says your browser needs a security update. It looks official and even includes a progress bar that ticks away for seven minutes. While you wait for this fake "Windows Security Update" to finish, the malware is silently working in the background. It is downloading multiple layers of code, each one designed to hide the next, until the final infostealer is safely tucked away in your computer's memory.</p><p>We have seen this malware hidden in all sorts of digital "candy," including fake game cheats for popular titles and cracked versions of expensive software. The lure changes, but the goal is always the same: social engineering.</p>

<h4>The digital master key</h4><p>Perhaps the most dangerous feature of Torg Grabber is its ability to bypass modern browser security. Major browsers like Google Chrome and Microsoft Edge recently introduced a feature called "App-Bound Encryption." Think of it as a vault door that can only be opened by the browser itself.</p><p>To beat this, the creators of Torg Grabber built a custom "lockpick." It is a tiny piece of code, only 20 KB in size, that sneaks into a legitimate browser process. Once inside, it tricks the browser into using its own "master key" to unlock your saved passwords and credit card details. By the time the malware is done, it has effectively walked through the front door of your digital life using your own keys.</p><h4>A massive appetite for your data</h4><p>Unlike older malware that might just try to crash your computer, an infostealer has one goal: profit. Torg Grabber is programmed to find almost everything of value on your machine. Its "shopping list" is staggering:</p><ul type="disc"><li data-list-item-id="eee754b80a606370a3c6e23613c76bf58"><strong>Your Financial Life:</strong> It specifically looks for 728 different cryptocurrency wallet extensions. It does not just want the big names: it is programmed to recognize even the most obscure digital wallets.</li><li data-list-item-id="eccbe6d26d81a46afe89fb53e6b60bcf6"><strong>Your Security Tools:</strong> It targets 103 different password managers and two factor authentication tools. It knows that if it can steal your "vault," it has everything.</li><li data-list-item-id="e14f5ff1a5f2e77d96d83cede3d096582"><strong>Your Privacy:</strong> It scans your Desktop and Documents folders for notes where you might have jotted down sensitive passwords or recovery phrases.</li><li data-list-item-id="e96da5bcdfc161d32390554e495aebfba"><strong>Your Identity:</strong> It steals "session cookies." These allow a criminal to log into your email or social media accounts as if they were you, often bypassing the need for a password entirely.</li></ul>

<h4>Tracking the human fingerprints</h4><p>Our research went beyond just the code. We followed the digital breadcrumbs all the way back to the people running the show. Each version of Torg Grabber contains a "tag," which is like a signature for the criminal who bought it.</p><p>We extracted over 40 distinct operator tags and used them to unmask several established identities in the Russian cybercrime world. We found individuals with nicknames like "Tony Montana" and "ChaChaGuru" who were openly boasting about their successes in private channels. Some even linked their accounts to marketplaces where they sell the very data they stole from victims.</p><h4>Why technical dissection matters</h4><p>We do not tell this story just to show how complex these threats have become. We tell it because this kind of technical dissection is how better protection is built.</p><p>Unmasking Torg Grabber required careful reverse engineering, threat intelligence work, sample correlation, infrastructure tracking, and repeated hypothesis testing across hundreds of artifacts. That work still depends on human expertise, especially when the goal is not just to describe what malware does, but to understand what changed, why it changed, and what defenders should do next.</p><p>At the same time, investigations like this are also showing us how threat research is changing. At Gen Digital, we are increasingly using agentic AI workflows to help accelerate parts of reverse engineering, threat hunting, technical correlation, and evidence organization, while keeping researchers fully responsible for validation, judgement, and final conclusions. The result is not automated truth. It is a faster and more scalable way for expert analysts to work through complex investigations without lowering the bar for rigor.</p><p>That broader shift is something we explore in more detail in our article, <a href="https://www.gendigital.com/blog/insights/research/engineering-the-future-of-agentic-threat-hunting">Engineering the Future of Agentic Threat Hunting</a>, which explains how we are building AI-assisted investigative workflows to help researchers move faster while keeping every meaningful claim evidence-based and human-owned.</p><p>And for readers who want to go deeper into this specific case, from the malware internals to infrastructure and operator traces, you can read the full technical report here: <a href="https://www.gendigital.com/blog/insights/research/torg-grabber-credential-stealer-analysis" target="_blank" rel="noopener noreferrer">https://www.gendigital.com/blog/insights/research/torg-grabber-credential-stealer-analysis</a></p>

How a “Vidar” look‑alike turned out to be Torg Grabber—a fast‑growing infostealer-as-a-service with ClickFix lures, browser lockpicks and a sprawling criminal customer base

The Malware with a Secret Identity: How We Unmasked Torg Grabber

Senior Principal Research Engineer

Junior Data Scientist

AI Researcher

Research Manager

<p>Scam advertising does not thrive on social platforms because it is invisible. It thrives because it is designed to look legitimate, just long enough to reach victims before detection catches up.</p><p>In our first investigation,&nbsp;<a href="https://www.gendigital.com/blog/insights/research/scam-ad-machine-meta">The Scam Ad Machine</a>, we showed the scale of the problem and how widespread scam ads have become on Meta platforms, with roughly 1 in 3 ads approved for publication in the UK and EU being a scam.&nbsp;This second part builds on that foundation, focusing on how these campaigns actually operate in practice.</p><p>Across our investigation of Meta platforms, we saw the same pattern again and again, scammers combining normal advertising features, deceptive presentation tricks, and short-lived campaign tactics to stay in circulation. This is not a single evasion trick. It is an operating model.</p><p>Below, we break down the techniques we found at scale, and why many of them are difficult to catch through automated moderation, manual review, or public transparency tools.</p><h2>How scammers hide in plain sight</h2><h3>Multi-facet ads, hiding one scam among legitimate links</h3><p>One of the most common techniques we uncovered is what we call <strong>multi-facet advertisements</strong>.</p><p>These ads bundle multiple images, products, and links into a single ad. Most of the links point to legitimate marketplaces or well-known ecommerce platforms such as Amazon, eBay, AliExpress, or Etsy. Hidden among them is a single malicious or scam-related link, often leading to fake ecommerce stores, fraudulent service pages, account scams, or impersonation pages tied to public figures.</p><p>The trick is simple: make the scam look like part of a normal shopping experience.</p><p>By surrounding one malicious destination with a cluster of legitimate brands and products, the ad looks ordinary at first glance. That lowers suspicion for users and can also make review harder if the ad is assessed superficially. It also creates collateral damage, legitimate brands and products end up visually associated with fraudulent campaigns.</p><p>From a detection perspective, this should be a solvable problem. A robust review process could inspect the full set of linked domains and compare what is shown with what is actually being promoted. In practice, however, we identified large volumes of these campaigns running simultaneously from different advertisers on Meta platforms, often linked to newly created advertisers and low-history accounts.</p>

<h3>URL masking, when the ad shows one domain and sends users to another</h3><p>This is one of the most effective deception techniques we observed.</p><p>Scammers make an ad appear to link to a trusted domain, such as a major marketplace or brand, while the click sends the user somewhere else. The ad displays a familiar name, but the landing page belongs to unrelated infrastructure controlled by the attacker.</p><p>For users, especially on mobile, that visible domain cue is often enough. Many people do not inspect the final URL before clicking, and once they land on an attractive page with compelling offers or urgency signals, many will continue browsing.</p><p>In our observations, Meta’s API may expose the domain shown in the ad, not necessarily the final destination the user reaches after clicking. That makes this technique harder to detect programmatically and significantly complicates analysis by transparency researchers, watchdogs, journalists, regulators, and law enforcement.</p><p>In other words, what the ad appears to be, and where it actually leads, can diverge in ways that are difficult to verify at scale.</p>

<p>The actual link leads to the website selling products that are completely unrelated to the advertised ones.</p>

<h3>Typosquatting, deceptive subdomains, and misleading previews</h3><p>Why abandon a tactic that still works?</p><p>A classic technique remains highly effective, registering domains that closely resemble legitimate brands. A small spelling change, an extra character, or a visually similar character can be enough to fool users at a glance. In fast-scrolling environments, these differences are easy to miss.</p><p>Scammers also use deceptive subdomain structures to look more credible. Instead of using a plainly suspicious domain, they may deploy subdomains such as go.[domain], shop.[domain], or offers.[domain]. These can look more legitimate to users and may also create inconsistencies in detection coverage. In some cases, we observed situations where one domain variant was flagged while a related subdomain remained active.</p><p>Another layer of deception appears in the creative itself. In ads using domain impersonation or typosquatting, we also observed mismatches between the ad’s visual preview and its actual content. For example, a video thumbnail may show a legitimate product, a game scene, or unrelated imagery, while the underlying content promotes a scam. If neither an automated system nor a human reviewer clicks through or expands the media, the discrepancy may go unnoticed.</p><p>This combination, deceptive domain naming plus misleading visuals, increases both click-through potential and evasion resilience.</p><p>An example of an advertisement using the prefix “go.”. The link “GO.DATING4SINGLES.COM” does not lead to the website, but “DATING4SINGLES.COM” does.</p>

<h3>Unicode text obfuscation that breaks detection, not readability</h3><p>Sometimes the URL is not the main problem, the text is.</p><p>Many scam ads rely on familiar triggers, high-return investments, miracle products, fake financial services, urgent offers, or celebrity-backed promises. In plain text, these patterns should be relatively easy to flag for additional review.</p><p>Scammers increasingly avoid this by using obfuscated characters and Unicode tricks. To a human reader, the text may look normal. To an automated system, parts of the same string may be transformed into unusual Unicode sequences, invisible joiners, or look-alike characters that break keyword matching and reduce classifier reliability.</p><p>The result is elegant from the scammer’s perspective, readable to people, unreliable for machines.</p><p>We observed this technique at scale in scam ads circulating across Meta platforms, often in combination with other evasive tactics such as domain impersonation and celebrity references.</p>

<h3>Hidden impersonation, names that look real to people but not to machines</h3><p>Impersonation remains one of the fastest ways to manufacture trust in scam advertising.</p><p>Scammers know that names associated with wealth, authority, or credibility can dramatically increase engagement, whether it is a celebrity, a business leader, or a title such as “Dr.” or “PhD.” Those same names should also be obvious candidates for automated scrutiny.</p><p>Scammers work around this by manipulating text so that it looks normal to a user but is encoded differently for machines. One common technique we observed uses special spacing characters or joiners that visually preserve a name while changing its underlying structure. To the naked eye, it may read as a well-known person’s name. To a detection system, it may be processed as a different token entirely.</p><p>This technique was especially common in scam ads designed to manufacture credibility through famous names, credentials, or authority signals.</p><p>This advertisement uses the name of dentist Dr. Margaret Hunt to gain users' trust. At the same time, a special character is used in the name to avoid detection.</p>

<h2>Why scam ads keep coming back</h2><p>The problem is not only that scam ads evade detection. It is that they regenerate faster than enforcement can disrupt the operation behind them.</p><p>This is the Hydra problem of scam advertising. Remove one ad, and several variants can reappear through new accounts, duplicate creatives, and short-lived campaigns built to expire before meaningful intervention happens.</p><p>Our investigation did not only examine what scam ads looked like. It also examined what happened to them over time, how they were removed, how quickly similar variants reappeared, and how easily the underlying operations continued.</p><p>What we observed suggests a recurring pattern, many interventions remove individual ad instances, while the broader scam operation remains fully capable of regeneration.</p><h3>Takedowns that remove ads, but not the operation</h3><p>One of the first patterns we noticed was that removals often appeared to happen on a single ad instance basis.</p><p>We observed cases where the same scam ad, or functionally identical copies of it, continued running even after one instance had been removed. This happened across different advertisers and, in some cases, within the same scam-linked advertiser account. The text, target audience, visuals, and destination could remain effectively the same, while only one instance was taken down.</p><p>Based on these observations, moderation often appears to act on the ad object that was detected, rather than reliably escalating to advertiser-level or campaign-cluster disruption.</p><p>For scammers, this is a gift. If enforcement targets copies one by one, duplication becomes a business advantage.</p><h3>Short-lived campaigns, high volume beats persistence</h3><p>Scammers do not need every ad to survive. They need enough ads to run long enough.</p><p>A common pattern we observed was the use of <strong>many short-lived advertisements</strong>, often with small budgets and short runtimes. Instead of relying on one long campaign, scammers distribute risk across large numbers of disposable ads. If some are removed, others remain active and continue reaching users.</p><p>This strategy fits the takedown pattern above. If moderation is slower than campaign turnover, short-lived scam ads become highly efficient. The ad dies, the operation continues.</p><p>We also repeatedly observed advertiser pages with very limited organic activity, minimal followers, random page names, and behavior patterns consistent with throwaway infrastructure, yet still capable of launching scam ads.</p><p>Permanence is not the business model, throughput is.</p><h3>User reporting is too slow for disposable scam ads</h3><p>We also tested the user reporting path directly by reporting scam ads from platform accounts.</p><p>In multiple cases, we observed the same ads still active after reporting, and in some cases visible again on subsequent checks. This does not necessarily mean reports are ignored, but it does suggest that user reporting alone is too slow or too inconsistent to function as an effective frontline defense against high-volume scam advertising.</p><p>This becomes even more problematic when campaigns are designed to run briefly and aggressively. By the time an ad is reviewed manually, it may already have completed its useful life, reached a large audience, and been replaced by multiple variants.</p><p>At this scale, platform moderation faces a difficult asymmetry. Scammers can generate and rotate ads faster than manual review can reasonably keep up.</p><h3>Advertisers accounts are cheap to replace</h3><p>Another structural issue is the ease of creating or replacing advertiser accounts.</p><p>Even when accounts are blocked, scammers can often resume operations quickly by shifting to new accounts, new pages, or repurposed profiles. During our investigation, we observed large numbers of suspicious advertisers with limited page history, low follower counts, recently created pages, and naming patterns consistent with disposable setups.</p><p>This creates a persistent regeneration advantage. If the cost of losing an advertiser account is low, and the cost of creating a replacement is also low, enforcement becomes a recurring operating expense for the scammer, not a meaningful deterrent.</p><p>That is the Hydra problem in practical terms, remove one head, and the infrastructure behind it keeps producing more.</p><h3>Scam ads are engineered for resilience</h3><p>Scam advertising is not static. It is adaptive, distributed, and engineered for resilience.</p><p>From URL presentation tricks and Unicode obfuscation to disposable ad waves and rapid advertiser regeneration, scammers exploit structural weaknesses in how social advertising ecosystems are built, moderated, and audited.</p><p>Reactive takedowns matter, but they are not enough when enforcement is slower than replication.</p><p>Meaningful progress requires systemic changes, stronger advertiser verification, better destination-level transparency, campaign-level enforcement, and faster cross-platform disruption mechanisms.</p><p>The Hydra metaphor matters here because it captures the real failure mode. Removing individual ads without disrupting the regeneration model does not solve the problem, it manages the symptoms while the system keeps producing new heads.</p>

How scam ads hide in plain sight, survive takedowns, and keep coming back

The Scam Ad Machine: Part II

Threat Researcher at Gen

<h2>Key Points&nbsp;</h2><ul type="disc"><li data-list-item-id="e59deb5ed92385418b6c648bee2751bf3">VoidStealer is the first infostealer observed in the wild adopting a novel debugger-based Application-Bound Encryption (ABE) bypass technique that leverages hardware breakpoints to extract the <code>v20_master_key</code> directly from browser memory.&nbsp;</li><li data-list-item-id="ee23cdbf8bdc0aabe684c5884f164ed93">The bypass requires neither privilege escalation nor code injection, making it a stealthier approach compared to alternative ABE bypass methods.&nbsp;</li><li data-list-item-id="e9aad20d0fd1b9a44cdb3bdc4c74ad104">In this technical blog post, we dissect the bypass technique step-by-step, from locating the target address for breakpoint placement to extracting the <code>v20_master_key</code>.&nbsp;</li><li data-list-item-id="e1808ce54ff39fc88832d5379553d4e3b">To support the defense community, Gen Threat Labs provides practical detection strategies and indicators to help defenders identify and mitigate this novel bypass technique.&nbsp;</li></ul><h2>Introduction&nbsp;</h2><p>When Google introduced <a href="https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html" target="_blank" rel="noreferrer noopener">Application-Bound Encryption</a> (ABE) in July 2024 with Chrome 127, it didn't mark the end of infostealers –⁠⁠⁠⁠⁠⁠ as expected, infostealers adopted quickly and came up with various methods to bypass it. Still, it undoubtedly raised the bar for accessing sensitive browser data, and, more importantly, significantly increased the visibility of such data theft attempts, as bypassing ABE now requires attackers to perform additional steps that are inherently more suspicious. Various bypass techniques have emerged since then, and since each comes with its own trade-offs, new approaches continue to appear as threat actors seek to minimize the footprint and evade detection.&nbsp;</p><p>In this technical blog post, we dissect a novel debugger-based ABE-bypass technique that is both technically elegant and offers a significant advantage over other existing bypass methods: a much lower detection footprint. The technique relies on attaching to the browser process as a debugger and setting breakpoints at carefully selected locations to extract the <code>v20_master_key</code> directly from the browser process memory. We demonstrate the technique on VoidStealer, the first emerging infostealer we have observed using this approach in the wild.&nbsp;&nbsp;</p><h2>VoidStealer&nbsp;</h2><p>VoidStealer is a MaaS infostealer that began being marketed on several darkweb forums since mid December 2025 and has been actively developed since then.&nbsp;</p>

<p>Considering the first version of VoidStealer from December 12, 2025, as the earliest date we have identified it being offered, the VoidStealer development timeline is approximately as follows (please note that exact dates may vary slightly, as we rely on announcements made by the malware developers themselves on HackForums):&nbsp;</p>

<table class="table"><tbody><tr><td><strong>VoidStealer version</strong></td><td><strong>Release Date</strong></td></tr><tr><td>v1.0</td><td>Dec 12, 2025&nbsp;</td></tr><tr><td>v1.1&nbsp;</td><td>Jan 16, 2026&nbsp;</td></tr><tr><td>v1.2&nbsp;</td><td>Jan 19, 2026&nbsp;</td></tr><tr><td>v1.3&nbsp;</td><td>Feb 3, 2026&nbsp;</td></tr><tr><td>v1.4&nbsp;</td><td>Feb 4, 2026&nbsp;</td></tr><tr><td>v1.5&nbsp;</td><td>Feb 22, 2026&nbsp;</td></tr><tr><td>v1.6&nbsp;</td><td>Mar 3, 2026&nbsp;</td></tr><tr><td>v1.7&nbsp;</td><td>Mar 9, 2026&nbsp;</td></tr><tr><td>v1.8&nbsp;</td><td>Mar 10, 2026&nbsp;</td></tr><tr><td>v1.9&nbsp;</td><td>Mar 10, 2026&nbsp;</td></tr><tr><td>v2.0&nbsp;</td><td>Mar 13, 2026&nbsp;</td></tr><tr><td><p lang="EN-US">v2.1&nbsp;</p></td><td><p lang="EN-US">Mar 18, 2026&nbsp;</p></td></tr></tbody></table><p>&nbsp;</p>

<p>The version 2.0, reported on Mar 13, 2026, introduced the novel ABE bypass technique.&nbsp;</p>

<p>To keep the blog post to the point, we focus mainly on the bypass technique itself rather than VoidStealer's capabilities.&nbsp;</p><h2>ABE Bypass(es)&nbsp;</h2><p>Similarly to other infostealers, VoidStealer does not rely on a single ABE-bypass technique but implements two distinct methods in case one fails. The first is a well-documented approach that involves injecting into the browser process and invoking <code>IElevator::DecryptData</code> from the browser's context via the COM interface. Since this is a well-known and thoroughly documented technique, we will not detail it here (for those interested, it is extensively documented in the <a href="https://github.com/xaitax/Chrome-App-Bound-Encryption-Decryption" target="_blank" rel="noreferrer noopener">ChromElevator project</a>). Nevertheless, it is worth noting that, however reliable it is, this technique relies on process injection, which is noisy and suspicious and might easily get flagged by security tools. The second (novel) approach is stealthier in this regard – it relies solely on the WinAPI function <code>ReadProcessMemory</code> and debugger attachment, which are considerably less suspicious than direct browser memory injection.&nbsp;</p><p>To clarify how the bypass operates and what it exploits, let's take a step back and briefly recap what the idea behind Application-Bound Encryption is and how Chrome uses it to protect passwords and other sensitive data. Chrome passwords are encrypted and stored in a SQLite3 database located at <code>%LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data</code> (assuming standard Chrome installation on Windows) and can be accessed, for example, by running the following Python script:&nbsp;</p>

<p>The script output for a single record would look roughly as follows (note the <code>v20</code> prefix in the encrypted password, indicating ABE-protected data):&nbsp;</p>

<p>The password value is encrypted using AES-GCM with the <code>app_bound_key</code>, which we will refer to as the <code>v20_master_key</code> going forward. The decryption process begins by removing the <code>v20</code> prefix from the encrypted string, then extracting the following 12 bytes to use as the nonce, and finally treating the remaining data as the combined ciphertext and authentication tag. Below is a simple Python script demonstrating this decryption process:&nbsp;</p>

<p>At this point, it is crucial to highlight that the knowledge of the <code>v20_master_key</code> is sufficient for decrypting <strong>any ABE-protected data</strong> tied to the application (in this case, Chrome). Where does this key come from, though? Chrome stores it in an encrypted form on disk in a JSON file <code>%LOCALAPPDATA%\Google\Chrome\User Data\Local State</code> under the <code>["os_crypt"]["app_bound_encrypted_key"]</code> field. Extracting the actual key in unencrypted form (<code>v20_master_key</code>) requires base64-decoding the value, removing the <code>APPB</code> prefix, calling <code>CryptUnprotectData</code> as <code>NT AUTHORITY\SYSTEM</code>, then calling it again as the logged-in user, and finally, specifically for Chrome, performing additional post-processing that we will not cover in detail here (for those interested, see the <a href="https://github.com/chromium/chromium/blob/main/chrome/elevation_service/elevator.cc#L229-L239" target="_blank" rel="noreferrer noopener">Chromium source code</a>). The ABE-protected password decryption workflow is illustrated in Figure 7.&nbsp;</p>

<p>To summarize, the fundamental security mechanism behind ABE lies in that the <code>v20_master_key</code>, which is used to encrypt/decrypt the sensitive browser data, is protected by <code>CryptProtectData</code> invoked as <code>NT AUTHORITY\SYSTEM</code>, the highest-privileged account on Windows.&nbsp;&nbsp;</p><p>Chrome, however, runs in the context of the logged-on user, not as <code>SYSTEM</code>. So how does it decrypt the key? To bridge that gap, Google implemented a separate service, Google Chrome Elevation Service (<code>elevation_service.exe</code>), which runs with <code>SYSTEM</code> privileges and handles the decryption. When Chrome needs to decrypt the <code>app_bound_encrypted_key</code>, it invokes <code>IElevator::Decrypt()</code> via a COM interface. The elevation service "validates" that the caller is Chrome, and if the check passes, returns the decrypted <code>v20_master_key</code> (the word validates is quoted as the check is not particularly robust and opens the door to another bypass). Chrome can then use the <code>v20_master_key</code> to encrypt or decrypt sensitive data such as cookies and passwords.&nbsp;</p>

<p>It is obvious that if the malware managed to run as <code>NT AUTHORITY\SYSTEM</code>, it could simply replicate all the steps and directly decrypt the <code>app_bound_encrypted_key</code> (and that is also one of the ABE bypass techniques). However, such a bypass still requires SYSTEM-level privileges, limiting its applicability to only some environments. Therefore, infostealers typically use it as a complementary method when other approaches fail, rather than relying on it as their primary technique.&nbsp;&nbsp;</p><p>There is also the option of injecting into Chrome and making the key decryption request directly from within the context of the browser, a commonly used bypass technique that VoidStealer itself employs. While this approach avoids the need for <code>SYSTEM</code> privileges, it still requires the injection, which is noisy.&nbsp;&nbsp;&nbsp;</p><p>This perfectly illustrates our earlier point – ABE does not prevent data theft, but it undoubtedly forces attackers into more visible actions, thus introducing great detection/hunting opportunities for us, defenders.&nbsp;&nbsp;</p><p>What prevents infostealers from reading the <code>v20_master_key</code> directly from the browser's memory, though? Chrome implements several protective measures to prevent it. First, the key is retained in memory in plaintext only for the minimum duration required to complete the cryptographic operation, minimizing its exposure. Additionally, the key is encrypted using the <code>CryptProtectMemory</code> function with the <code>CRYPTPROTECTMEMORY_SAME_PROCESS</code> flag, ensuring that even if an attacker could read the encrypted form of the key from memory, they would still need to invoke the complementary decryption function, <code>CryptUnprotectMemory</code>, directly from the Chrome process to decrypt it. And that would require a code injection, which is noisy.&nbsp;&nbsp;</p><p>Nevertheless, despite these safeguards, there is still a critical weakness. Regardless of how small the key exposure window is, there is still a moment in which the <code>v20_master_key</code> is present in memory <strong>in plaintext</strong>. And that is precisely what the novel technique exploits. By attaching to the browser process as a debugger and setting a breakpoint at the precise moment when the key is present in plaintext, an attacker can extract it directly from the memory. Importantly, this can be done without any privilege escalation and, when using hardware breakpoints rather than software ones, without any writes to the browser process.&nbsp;</p><p>Note that the VoidStealer developers did not invent the technique. They directly adopted it from the open-source <a href="https://github.com/Meckazin/ChromeKatz/tree/main/ElevationKatz" target="_blank" rel="noreferrer noopener">ElevationKatz</a> project, developed by Meckazin, the same author behind CookieKatz and CredentialKatz, which were among the first tools capable of bypassing ABE since its introduction. Although there are some differences, based on our analysis, it is evident that VoidStealer's implementation is directly based on ElevationKatz, which has now been public for over half a year. Yet, VoidStealer is the first malware we are aware of employing this technique in the wild.&nbsp;</p><p>In the following section, we focus specifically on VoidStealer's implementation of the bypass.&nbsp;</p><h2>Technical Walkthrough of VoidStealer's Implementation of the Novel ABE Bypass&nbsp;</h2><p>&nbsp;<br>The success of the entire technique boils down to finding the right address on which to set the breakpoint. VoidStealer begins by spawning a browser process via <code>CreateProcessW</code> with the <code>CREATE_SUSPENDED</code> and <code>SW_HIDE</code> flags. It then resumes the main thread and immediately attaches a debugger to the newly spawned process via <code>DebugActiveProcess</code>.&nbsp;&nbsp;</p><p>While it may not be immediately obvious, beginning with this step is deliberate and strategically important as browsers typically load cookies into memory during startup. And since the cookies are ABE-protected, the browser must decrypt the <code>v20_master_key</code> during its initialization. This makes the browser startup an ideal opportunity to intercept and steal the key.&nbsp;</p>

<p lang="EN-US">It is unclear to us why VoidStealer launches the browser in a suspended state (an additional suspicious indicator), only to resume and attach a debugger immediately afterward, rather than directly spawning the browser under a debugger. Nevertheless, we have verified that the same bypass technique works equally well when the browser is spawned directly using <code>CreateProcessW</code> with the <code>DEBUG_ONLY_THIS_PROCESS</code> flag. We assume that this is simply a consequence of copy-pasting the code from ElevationKatz, which follows the same approach.&nbsp;</p><p>Once attached as a debugger, VoidStealer begins listening for debug events via <code>WaitForDebugEvent</code>.&nbsp;</p>

<p>Since VoidStealer targets only Chrome and Edge (like ElevationKatz), the code address the bypass tries to find resides in either <code>chrome.dll</code> or <code>msedge.dll</code> (though it could readily be extended to other Chromium-based browsers). Because VoidStealer attaches to the browser as a debugger almost immediately after launch,&nbsp;before all DLLs have been loaded, it cannot simply search for the target module right away. Instead, it waits for <code>LOAD_DLL_DEBUG_EVENT</code> (sent to the debugger whenever a new DLL is loaded into the debugged process memory) and checks each loaded module against the target DLL.&nbsp;</p>

<p>Once the target DLL is loaded, VoidStealer scans its entire <code>.rdata</code> section using <code>ReadProcessMemory</code> to find the string <code>OSCrypt.AppBoundProvider.Decrypt.ResultCode</code>, or more precisely, its address.&nbsp;</p>

<p>A good question is: why this particular string? The answer lies in the <a href="https://github.com/chromium/chromium/blob/2852519ad41d6809df1786b3854fe5055b364687/chrome/browser/os_crypt/app_bound_encryption_provider_win.cc#L137" target="_blank">Chromium source code</a>, which reveals that this string appears immediately after the call to <code>os_crypt::DecryptAppBoundString</code>. Thus, this is precisely the point at which the <code>v20_master_key</code> is present in the browser's memory in plaintext.&nbsp;&nbsp;</p>

<p>Furthermore, there is only one cross-reference to that string, making it a perfect target for the breakpoint.&nbsp;</p>

<p>Following the cross-reference in <code>chrome.dll</code>, we can see that the disassembled code corresponds to the source code and that the cross-reference comes from a <code>LEA</code> instruction.&nbsp;</p>

<p>The important bytes from the <code>LEA</code> instructions are the last four, as they specify the 32-bit displacement used to calculate the actual address, which is to be loaded into the <code>RCX</code> register.&nbsp;&nbsp;</p>

<p>The CPU essentially calculates the address as follows: <code>RCX = (instruction_address + 7) + (signed int32) disp32</code>. To find the <code>LEA</code> instruction referencing the target string, VoidStealer scans the whole <code>.text</code> section and searches for the byte sequences <code>48 8D 0D</code> (the beginning of the <code>LEA</code> instruction), extracts the following 4 bytes (the 32-bit displacement), and calculates the referenced address. It then compares each calculated address against the <code>OSCrypt.AppBoundProvider.Decrypt.ResultCode</code> string address to identify the matching <code>LEA</code> instruction referencing it, which becomes the target address for the breakpoint.&nbsp;</p>

<p>If the search is successful, VoidStealer sets a hardware breakpoint at this address across all browser threads by resolving <code>NtGetNextThread</code> from <code>ntdll.dll</code> and iterates through each thread, suspends it, writes the breakpoint address into <code>DR0</code>, enables it via <code>DR7</code>, and resumes the execution.&nbsp;</p>

<p>To ensure complete coverage, VoidStealer’s debug loop also handles <code>CREATE_THREAD_DEBUG_EVENT</code> events to set up the hardware breakpoint for any newly created thread.&nbsp;</p>

<p>At this point, it might be worth explaining why hardware breakpoints are chosen over software ones. Setting a software breakpoint requires patching the binary by overwriting the target address with, for example, an <code>INT3 (0xCC)</code> instruction, necessitating a memory write into the browser’s memory. And that is precisely what attackers aim to avoid. Hardware breakpoints, on the other hand, can be configured entirely through <code>SetThreadContext</code> without ever modifying the browser’s memory, making the bypass stealthier.&nbsp;&nbsp;</p><p>Once the breakpoints are in place, all that is left is to wait for them to trigger. Since cookies are protected by ABE and the browser needs to load them at startup, it must request the <code>v20_master_key</code> decryption shortly after launching to decrypt them from disk. Therefore, there is a high chance that the breakpoint will be triggered shortly after the browser starts.&nbsp;</p>

<p>If the breakpoint is placed on the <code>LEA RCX</code>, <code>OSCrypt.AppBoundProvider.Decrypt.ResultCode</code> address, then in current builds, the <code>R14</code> register (for Edge) or <code>R15</code> register (for Chrome) holds a pointer to the <code>v20_master_key</code>. From there extracting the key straight from the memory is only two <code>ReadProcessMemory</code> calls away.&nbsp;&nbsp;</p><p>To make it easier to grasp the big picture of the entire bypass, we have illustrated the complete workflow in Figure 23.&nbsp;</p>

<h2>Detection Strategies for Defenders&nbsp;</h2><p>We should first emphasize that different malware authors will likely adapt the bypass technique in various ways – for example, they may not target the <code>v20_master_key</code> usage immediately after startup (in which case they could leverage an already-running browser instance). For detection purposes, it is crucial to identify what is unlikely to change across all possible variations. Regardless of implementation details, the bypass fundamentally relies on setting hardware breakpoints at strategic locations, which requires either attaching a debugger or launching the browser under a debugger, along with browser memory reads.&nbsp;&nbsp;&nbsp;&nbsp;</p><p>These invariants provide strong detection opportunities, especially in sandboxed environments, as legitimate applications do not debug browsers. What about legitimate debuggers, though? Even those require users to explicitly specify which application to debug. Therefore, if an application starts debugging a browser autonomously, it should be a clear red flag.&nbsp;&nbsp;&nbsp;&nbsp;</p><p>But beyond that, there are other detection opportunities. While reading browser memory may seem less suspicious than writing to it, as this bypass demonstrates, it actually can be. Therefore, monitoring reads from browser memory can provide valuable detection signals, as benign applications rarely have legitimate reasons to access it.&nbsp;&nbsp;</p><p>Lastly, the technique requires a running browser instance, which malware will typically try to hide from the user. Whether by launching it via <code>CreateProcess</code> with the <code>SW_HIDE</code> flag, running it in headless mode, creating a new desktop and running it from there, or positioning the browser window off-screen. These evasion tactics can serve as additional indicators of such malicious activity.&nbsp;</p><h2>Summary&nbsp;&nbsp;</h2><p>VoidStealer is the first infostealer observed in the wild employing a debugger-based ABE bypass technique (directly adapted from the publicly available ElevationKatz project), highlighting the continuously evolving landscape of Application-Bound Encryption bypasses. Unlike traditional bypass methods, it requires neither privilege escalation nor code injection, making it a stealthier alternative.&nbsp;&nbsp;</p><p>Given these advantages, combined with the availability of a public PoC (ElevationKatz), it is only to be expected that more infostealers will adopt the bypass technique in the future.&nbsp;</p><h2>IoC&nbsp;</h2><p>f783fde5cf7930e4b3054393efadd3675b505cbef8e9d7ae58aa35b435adeea4 (VoidStealer v2.0)&nbsp;</p>

A Novel Debugger-based ABE Bypass Spotted in the Wild

VoidStealer: Debugging Chrome to Steal Its Secrets 

Threat Intelligence Director

<p>The problem: Same skill, different hash</p><p>As 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.</p><p>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.</p>

<p>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.</p><h2>Why a simple hash doesn’t work</h2><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p>What we need is an identifier that represents the <em>logical content</em> of the skill directory — one that changes if and only if the actual files or structure change.</p>

<h2>Designing the Skill ID</h2><p>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.</p><p>Here’s the algorithm, step by step.</p><h3>1. Extract the file tree from the archive</h3><p>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.</p><h3>2. Normalize paths</h3><p>Each path goes through four normalizations:</p><ul><li data-list-item-id="e21b88a9a5d5480e58e9d3c738b97270e"><strong>Backslash to forward slash</strong> —&nbsp;<code>lib\helper.py becomes&nbsp;lib/helper.py</code></li><li data-list-item-id="eb5f9d1e35c2a3d65641ad7567333f0f7"><strong>Unicode NFC normalization</strong> — 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"><strong>Collapse redundant separators and dot components</strong> —&nbsp;<code>foo//bar/./baz.txt becomes&nbsp;foo/bar/baz.txt</code></li><li data-list-item-id="e8d310b0b1c31492dad54af5f4609e78f"><strong>Strip leading&nbsp;./ and&nbsp;/</strong> —&nbsp;./<code>SKILL.md </code>becomes&nbsp;<code>SKILL.md</code></li></ul><p>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.</p><h3>3. Strip the wrapper directory</h3><p>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.</p><p>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.</p><h3>4. Exclude the signature file</h3><p>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.</p><h3>5. Hash each file</h3><p>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.</p><h3>6. Build sorted tree entries</h3><p>Construct one entry per file and directory using null-byte delimiters:</p><p><code>&lt;type&gt;\0&lt;path&gt;\0&lt;sha256_hex&gt;\n</code></p><p>Where&nbsp;<code>&lt;type&gt;</code> is either&nbsp;<code>file or&nbsp;dir</code>. Sort entries by path.</p><p>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.</p><h3>7. Hash the tree</h3><p>Feed the sorted, concatenated entries into a final SHA-256 hash. The resulting 64-character hex digest is the Skill ID.</p><p>Here’s what the core logic looks like, stripped to its essentials:</p><p><code><em># Exclude the signature file</em></code><br><code>entries&nbsp;= [(p, d)&nbsp;<strong>for</strong> p, d&nbsp;<strong>in</strong> entries&nbsp;<strong>if</strong> p&nbsp;!=&nbsp;"skill.sig"]</code><br><br><code>file_hashes&nbsp;= {}</code><br><code>tree_entries&nbsp;= []</code><br><br><code><strong>for</strong> path, is_dir&nbsp;<strong>in</strong> entries:</code><br><code>&nbsp; &nbsp;&nbsp;<strong>if</strong> is_dir:</code><br><code>&nbsp; &nbsp; &nbsp; &nbsp; content_hash&nbsp;= sha256(b"").hexdigest()</code><br><code>&nbsp; &nbsp; &nbsp; &nbsp; tree_entries.append(("dir", path, content_hash))</code><br><code>&nbsp; &nbsp;&nbsp;<strong>else</strong>:</code><br><code>&nbsp; &nbsp; &nbsp; &nbsp; content_hash&nbsp;= sha256(file_contents[path]).hexdigest()</code><br><code>&nbsp; &nbsp; &nbsp; &nbsp; file_hashes[path]&nbsp;= content_hash</code><br><code>&nbsp; &nbsp; &nbsp; &nbsp; tree_entries.append(("file", path, content_hash))</code><br><br><code><em># Sort by path for deterministic ordering</em></code><br><code>tree_entries.sort(key=<strong>lambda</strong> e: e[1])</code><br><br><code><em># Hash the tree</em></code><br><code>skill_hasher&nbsp;= sha256()</code><br><code><strong>for</strong> entry_type, path, content_hash&nbsp;<strong>in</strong> tree_entries:</code><br><code>&nbsp; &nbsp; line&nbsp;=&nbsp;f"{entry_type}\0{path}\0{content_hash}\n".encode()</code><br><code>&nbsp; &nbsp; skill_hasher.update(line)</code><br><br><code>skill_id&nbsp;= skill_hasher.hexdigest()</code></p><p>The function returns both the Skill ID and the dictionary of per-file hashes. One call, two useful outputs.</p><h3>A concrete example</h3><p>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></p>

<h2>Properties that matter</h2><p>The Skill ID has one defining property: it changes if and only if meaningful content changes.</p><p>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.</p><p>Change one byte of one file? Different ID. Rename a file? Different ID. Add an empty file? Different ID. Change directory structure? Different ID.</p><p>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.</p><p>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 <em>included</em> 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.</p><h2>What you can build with a stable ID</h2><p>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.</p><h3>Allowlisting</h3><p>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.</p><h3>Content-addressable storage</h3><p>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.</p><h3>Per-file caching</h3><p>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.</p><h3>Detection flagging</h3><p>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.</p><h3>Version tracking</h3><p>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.</p><p>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.</p><h2>How we use it</h2><p>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.</p>

<h2>Signing skills: From identity to authenticity</h2><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p>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.</p><h2>Looking ahead</h2><p>A stable, cross-platform identifier for skills opens several directions worth pursuing.</p><p>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.</p><p>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.</p><p>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.</p><h2>Conclusion</h2><p>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.</p><p>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.</p><p>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.</p><p>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>.</p><p>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.</p>

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 

<p>Agentic Threat Hunting is how we use AI to dramatically accelerate threat investigations without giving up rigor. Senior researchers stay in control, but they gain a force multiplier, like having extra analysts available on demand. We build this with custom prompts, repeatable investigation playbooks and tool-connected agent workflows that keep work consistent and auditable. The result is faster understanding, faster response and better protection for users.</p><p>In a recent investigation, this approach produced a complete, publishable, evidence-backed analysis about <strong>30 times faster</strong> than a traditional workflow, without skipping verification.</p><p>We’re building this as a repeatable capability across investigations, not an ad hoc trick.</p><p>&nbsp;</p><p>Introducing ‘Agentic Threat Hunting’</p><p>Attackers scale by default. They automate, iterate and copy what works until defenders are forced into a permanent reaction cycle.</p><p>Defenders don’t lose because they lack intelligence or tools. Defenders lose because time is finite.</p><p>Threat hunting is not a single breakthrough moment. It’s a chain of steps and the chain breaks where time and attention run out.</p><p>Deep technical analysis is still one of the highest leverage things a security team can do. It is also one of the hardest things to scale, because it depends on expert attention and takes a great deal of time. A strong researcher can only do so many hours of careful extraction, correlation, hypothesis testing, and write-up in a day.</p><p>That bottleneck is changing.</p><p>Not because AI “does the research,” but because <strong>agentic workflows compress time</strong>. With the right operating model, a senior analyst can direct AI agents like a small team of junior researchers. Multiple threads run in parallel, while the human stays responsible for judgement, verification, and final conclusions.</p><p>That is what we mean by <strong>Agentic Threat Hunting</strong>.</p><p>This is not “using a chatbot sometimes”. It is a new operating model for how threat hunting gets done, and at Gen we are treating it like a capability we are building, evolving, and systematizing internally.</p><h3>The problem we are solving: time is the limiting factor</h3><p>A modern threat investigation rarely arrives as one tidy unit of work. It arrives in pieces, a suspicious sample, related variants, infrastructure breadcrumbs, partial configuration and a growing set of “maybe” links that need to be proven or discarded.</p><p>Even the best researchers lose days to work that is necessary but doesn’t deserve senior attention:</p><ul type="disc"><li data-list-item-id="ef4d4fc4da96a97bab25024c23b8d762d">Repeating extraction across variants</li><li data-list-item-id="e73acdd465dbd96036cddd48f4c40f2fd">Organizing artifacts into a structure that can be compared and revisited</li><li data-list-item-id="e645e7385bdb99bb596fa419cf683f219">Maintaining multiple hypothesis threads without mixing assumptions into facts</li><li data-list-item-id="e147fad2170c65380f9fb546d79fc7971">Turning raw technical detail into outputs that other teams can act on</li></ul><p>The cost is not just speed. When time gets tight, risk increases. Steps get shortened, context gets lost and important connections can be missed.</p><p>This is the gap Agentic Threat Hunting is designed to close.</p><h3>What changes: parallel work, one accountable owner</h3><p>The difference with Agentic Threat Hunting is not that the model “finds the truth”. It’s that a senior researcher can run multiple investigation threads in parallel, without losing the plot.</p><p>Instead of one person doing everything serially, agents can take on defined roles that mirror how a small team works:</p><ul type="disc"><li data-list-item-id="e15efe13406c7eea8f2e84b2546de554f">one agent structures artifacts into consistent notes and a capability map,</li><li data-list-item-id="e2c946dfdb49a47a9370eb7cd27a615c3">another maintains a living hypothesis tree, highlighting contradictions and what still needs proof,</li><li data-list-item-id="e95bbc6816e09d0285fd36c7c45d29c22">another drafts evidence-linked summaries for internal stakeholders while the researcher keeps investigating.</li></ul><p>The senior researcher becomes the director, the reviewer and the owner of every conclusion. The work scales, but accountability does not move.</p><h3>What stays the same: credibility, traceability and ownership of claims</h3><p>If we only talk about speed, this turns into hype.</p><p>AI can sound confident while being wrong. That is not a theoretical risk, it is the default failure mode of careless use. So the core principle of Agentic Threat Hunting is simple:</p><p><strong>Agents can accelerate work, but researchers own the claims.</strong></p><p>In practice, that means evidence remains the source of truth, not the agent’s narrative. Every meaningful conclusion must be traceable back to artifacts and anything that cannot be traced stays a hypothesis. Confident language is not proof. Verification is not optional. Humans remain accountable for what we ship internally and what we publish externally.</p><p>This is how you get the upside of speed without sacrificing trustworthiness.</p><h3>How it works in practice: two examples</h3><p><strong>Example 1: Variant wrangling without losing rigor</strong></p><p>Malware rarely arrives as a single, well-defined specimen. It arrives as a stream of variants, each with small changes that matter.</p><p>In a traditional workflow, analysts repeat the same extraction steps across variants, then try to keep the differences straight across notes, screenshots and half-finished write-ups.</p><p>With an agentic workflow, we can delegate the repetitive passes. Agents produce consistent, structured summaries of behaviors, configuration patterns and meaningful deltas across samples. The senior researcher then focuses on the high-value part: verifying the key claims, spotting what changed and deciding what those changes imply.</p><p><strong>Example 2: From raw technical detail to outputs people can actually use</strong></p><p>Even when the analysis is correct, a lot of time disappears translating it into something others can act on.</p><p>While the researcher is validating evidence, agents can draft two versions of the same findings, one technical for internal response teams (actionable, precise, evidence-linked), and one plain-language for a broader audience (clear, non-technical, no unnecessary detail).</p><p>The human still owns the narrative, edits for accuracy and decides what is publishable, but translation stops being the limiting factor.</p><h3>The engine behind it: playbooks, prompts and roles that work like a team</h3><p>The difference between “we tried AI” and “we are building Agentic Threat Hunting” is discipline.</p><p>We are not relying on generic prompts or one-off interactions. We develop and refine prompts and playbooks that reflect how investigations actually work, including how we structure evidence, how we express uncertainty, how we separate “observed” from “inferred” and how we keep conclusions traceable back to artifacts.</p><p>Then we operationalize that into agent roles, so the work is repeatable instead of reinventing every time.</p><p>Most importantly, this is not static. We continuously evolve the approach, creating new ways to take advantage of agents while keeping the same standard of rigor. That continuous evolution matters, because threat hunting is adversarial work. Attackers adapt, and tooling must adapt too.</p><h3>Why it matters: faster investigations mean better protection</h3><p>Attackers will use the same force multipliers. Agentic workflows can reduce their cost of experimentation, speed up iteration and help scale campaigns that used to require more manual effort.</p><p>That is exactly why we’re investing in Agentic Threat Hunting as a disciplined capability, not a novelty. The advantage will not come from “having models.” It will come from having better workflows, stronger verification habits and faster learning loops.</p><p>When the investigative cycle is shorter, detections improve sooner, infrastructure can be identified and disrupted sooner, response teams get clarity sooner and users are protected sooner.</p><p>There is a second-order effect too. Senior researchers spend less time doing necessary but repetitive wor and more time doing what makes them senior: connecting dots, spotting patterns, and making high-stakes judgment calls.</p><p>In other words, AI compresses time, but it does not compress responsibility. That stays human.</p>

An Army for Every Analyst

Engineering the Future of Agentic Threat Hunting 

<p>Malware authors have always understood a simple truth: defenders scale by recognizing patterns, attackers buy time by breaking them.&nbsp;</p><p>For years, that meant packers, obfuscation, and classic polymorphism. In many campaigns, server-side polymorphism ensured each target received a slightly different sample, enough to blur signatures and slow down clustering, while the real investment (later-stage payloads, infrastructure, monetization) stayed steady.&nbsp;</p><p>Now, we are seeing a modern version of the same strategy: <strong>Promptmorphism</strong>, the rapid regeneration of stage 1 loaders into endless fresh-looking variants. In practice, this is the loader treated as a disposable wrapper, continuously rewritten to stay ahead of similarity-based detection. In simple terms, this means attackers no longer rely only on traditional code mutation. Instead, they can use AI prompts to repeatedly generate new versions of the same loader, creating a steady stream of slightly different files that all perform the same job.&nbsp;</p><p>To be clear, not every fast-changing loader is LLM-written, some are driven by template engines, build pipelines, or manual refactors. What has changed is how easy LLMs make high-frequency rewrites at scale, especially for small, modular first-stage components.&nbsp;</p><h3>What we mean by Promptmorphism&nbsp; &nbsp;</h3><p>Promptmorphism is LLM-assisted code variation used to continuously regenerate the early-stage loader, producing many distinct implementations of the same minimal job. Because LLMs are probabilistic models, unless outputs are tightly constrained, small prompt or sampling changes naturally produce different implementations of the same logic, variation becomes the default rather than the exception.&nbsp;</p><p>Stage 1 rarely needs to be clever. It needs to run, perform a few checks, then fetch, decrypt, unpack, or hand off to stage 2. That narrow scope makes it ideal for rapid rewriting. An LLM can re-express the same logic with different structure, different API usage, different control flow, and different naming conventions, without changing the campaign’s underlying playbook.&nbsp;</p><p>From a defender’s perspective, this matters because stage 1 is what you encounter first. It is the component most likely to be scanned, sandboxed, executed, and shared. If that component can be churned endlessly, workflows that rely heavily on static similarity and quick clustering lose leverage.&nbsp;</p>

<h3>A real-world example: a LaaS “packaging roulette”</h3><p>To make this concrete, here’s what this looks like in the wild.</p><p>We are tracking a <strong>loader-as-a-service (LaaS)</strong> ecosystem where multiple campaigns rely on a shared loader that is frequently updated and redistributed. We have seen the same loader layer used to drop different malware, including Wincir and Stealc.</p><p>What is striking is not just that the loader changes; it is how fast it changes. Over a short span of days, we observed the same stage 1 job implemented with a rotating set of packaging choices:</p><ul type="disc"><li data-list-item-id="e2726bbacc59a47e7cc5196151e3632ce">Encrypted payload embedded in the executable, with keying material present alongside it.</li><li data-list-item-id="e243bca6bd708acaf9e1516c7570fcf0b">A shift to hex-encoded payloads.</li><li data-list-item-id="e3d909c138c86b09a0626deebf3d97cb1">Then multiple hex-encoded chunks (for example, 10 parts) that had to be assembled at runtime.</li><li data-list-item-id="ec02244e38543f8cc10f1e0dd4ee3fedf">A return to raw encrypted bytes embedded directly in the executable.</li><li data-list-item-id="ece89b03e3f39e29ef7e799c7cbb858e4">Moving encrypted bytes into the PE overlay (data appended beyond the formal end of the PE image).</li><li data-list-item-id="ecd6c43a00f4894fe776d49e8ad394d0a">Placing encrypted bytes inside x64 code itself, effectively blending “data” into executable regions.</li><li data-list-item-id="e018a914e3e8d096c98a97e155fc5169b">In at least one iteration, swapping cryptography (for example, ChaCha instead of AES).</li></ul><p>The key takeaway is that the mission stays broadly the same, but the wrapper changes repeatedly. If you have ever dealt with server-side polymorphism, this will feel familiar. The difference is that the source of variation is no longer only classic packing and obfuscation transformations&nbsp;and encryption wrappers. Increasingly, the operational goal is achieved via rapid rewrite cycles, whether driven by LLM assistance, aggressive refactoring, or automated build pipelines designed to mutate the first stage.</p><h3>Why stage 1 is the perfect target for this approach</h3><p>Stage 1 is exposed. It has to survive the widest range of defensive controls (gateway scanning, reputation systems, endpoint scanning, sandboxing). It also tends to be modular, which makes it easier to swap.</p><p>In the Wincir chain, analysis shows a loader that includes multiple capabilities common in modern staging:</p><ul type="disc"><li data-list-item-id="e5fedfdbf81ef4bb4cf1218021ba4abac">decryption and decompression routines</li><li data-list-item-id="eb63f7db44a54416ae48d419d8029644b">API resolution and loader scaffolding</li><li data-list-item-id="e9c690a2461baf1b5e0ee4b6f58858a31">injection and execution plumbing</li><li data-list-item-id="e88eab72f7c1378e9b9da2753bd9c398a">anti-analysis checks</li><li data-list-item-id="e735a9629325ff7a9e68b8e72cbb95d14">network retrieval for follow-on components</li><li data-list-item-id="ecee60024174fd37c8eb6bc0428b685b0">in some samples, script-host execution paths (for example via Windows script engines)</li></ul><p>This is exactly why attackers focus mutation here. If stage 1 buys them a few extra hours or days before defenders build durable clustering and detections, the rest of the chain gets to run.</p><h3>How Promptmorphism differs from classic server-side polymorphism</h3><p>It is tempting to label all of this “polymorphism,” but there is a meaningful difference between transforming an artifact and re-authoring one.</p><ul type="disc"><li data-list-item-id="ef4193c5eef015653a5ab33dd042ade53">Server-side polymorphism often starts with the same logic and changes representation (packing, encryption layers, stub transformations).</li><li data-list-item-id="e26b4d8f2ec6385e877ed0425fda2bd25">Promptmorphism can change the implementation itself, reorganizing code structure, swapping APIs, rewriting helper logic, and reshaping control flow, while preserving behavior.</li></ul><p>In practice, this can reduce obvious byte-level similarity and break simple clustering. At the same time, it introduces new seams: if attackers lean on the same generation patterns, prompts, or scaffolding, they can accidentally create a different kind of fingerprint.</p><h3>The attacker tradeoffs, this is not magic</h3><p>It is useful to be skeptical of the “AI makes malware unstoppable” framing. Promptmorphism creates pressure, but it also creates friction for attackers:</p><ul type="disc"><li data-list-item-id="e7970a7f1f532c818c34e57e1a6d7b097">Quality varies, rewrites introduce bugs.</li><li data-list-item-id="ebfca458e3a3ea82f9b3b8288f822abbf">Consistency drops, which can hurt reliability across environments.</li><li data-list-item-id="e14de79ac7b6f36d18b65ec06c536ca66">Noise increases, rewritten code often adds unnecessary behavior or sloppy error paths.</li><li data-list-item-id="ec3611852372e6b9d6483291368ede1b9">Stable anchors become more important, because defenders shift focus to what does not change.</li></ul><p>A useful way to frame it is this: Promptmorphism shifts the battleground. It does not eliminate detection; it pressures defenders to pivot from “what does this file look like” to “what does this campaign do.”</p><h3>How defenders should respond when stage 1 becomes disposable</h3><p>When the loader is unstable, the durable signals are usually elsewhere:</p><ul type="disc"><li data-list-item-id="ec5edafdd9bd6401a501b9f57ae0100a4"><strong>Behavioral anchors:</strong> process tree patterns, persistence choices, execution handoff, network call sequences.</li><li data-list-item-id="eac0d9ff58060a011c47a3815ad79af25"><strong>Campaign correlation:</strong> infrastructure reuse, endpoint patterns, TLS/HTTP fingerprints, timing and targeting patterns.</li><li data-list-item-id="e091d6a05e49e8a129e05c5b63f1d3054"><strong>Chokepoints:</strong> second-stage retrieval, config formats, decryption and decompression routines that remain consistent across waves.</li><li data-list-item-id="e93d996af05db9dc6fe891e023cd1d093"><strong>Distribution signals:</strong> delivery channels, lures, attachment styles, redirect chains.</li></ul><p>Stage 1 can be rewritten. The campaign economics, infrastructure constraints, and operational habits are harder to rewrite every day.</p><h3>Closing Thought</h3><p>Promptmorphism is not just “AI malware.” It is a sign of industrialization.</p><p>Attackers have always chased cheap novelty. Promptmorphism is a new production method for an old business goal: keep the front door unstable long enough to get inside.</p><p>Defenders can respond by refusing to treat stage 1 as the “identity” of the threat. When the loader becomes disposable, the campaign becomes the unit of analysis, and that is where durable defenses and durable disruptions are won.</p>

 How malware authors use LLM‑driven “promptmorphism” to endlessly reshape loaders—and what defenders must do to keep up 

Promptmorphism: How LLMs Are Mass-Producing Disposable Stage 1 Loaders 

<p>The public conversation about AI is stuck on the wrong axis. We argue about whether models are “intelligent,” whether they are approaching AGI, whether they are conscious, whether they can reason like humans. That debate makes for great podcasts and worse decisions.</p><p>The risk we are actually deploying into the world is not Artificial General Intelligence. It is something more mundane and, in practice, more dangerous: <strong>Artificial Mindless Intelligence (AMI)</strong>.</p><h2>What Is Artificial Mindless Intelligence (AMI)?</h2><p>Artificial Mindless Intelligence (AMI), a term coined by Gen, describes AI systems that generate mind-like output without mind-like responsibility, authority boundaries, or accountability.</p><p>It can sound confident while being wrong, sound intentional while being ungrounded, and sound trustworthy while being easy to steer. If you grant it access to your inbox, files, calendar, chat apps, admin consoles, or payment workflows, AMI does not need to “go rogue” to cause harm. It only needs permission.</p><p>This is not a philosophical argument about what intelligence is. It is a correction about where operational risk comes from.</p><p>AMI is a term we use to describe AI systems that lack:</p><ul type="disc"><li data-list-item-id="e03d0d96340780f275dd5f3ecf2bb0b51">grounded understanding</li><li data-list-item-id="ec599eac6f2308beaa0b4f2daf866ada0">stable intent</li><li data-list-item-id="e15cf55d59bb4899e73c684b36190ed4c">accountability</li><li data-list-item-id="eca1f41918e7e8c8289e3a5ca3cfb9e2d">moral agency</li><li data-list-item-id="ef057cbb07fa15ec1bf2d189bb054fc62">authorization boundaries</li></ul><p>These systems become especially risky when they’re granted operational authority (the ability to act, transact, approve, or execute workflows).</p><h3>The AGI distraction vs. real AI risk&nbsp;</h3><p>AGI talk creates two predictable failure modes.</p><p>One group panics: “Skynet is here!” They demand bans, moratoria, or security theater that treats the model as a sentient adversary.</p><p>The other group tunes out: “this is sci-fi!” They assume the risk is hypothetical, far off, and irrelevant to real products shipping today.</p><p>Both reactions are convenient, and both are wrong.</p><p>The systems being deployed right now are powerful and fluent, but they are also deeply ungrounded. They do not reliably know when they are wrong. They do not carry responsibility. They do not feel consequences. They do not “want” anything. Yet they can be placed in positions where they effectively behave like junior operators inside a company or a household, reading, deciding, and acting across accounts.</p><p>That combination is AMI, and it explains why the most important questions are not about “intelligence.” They are about <strong>authority</strong>.</p><h3>What AMI is, and what it is not</h3><p>AMI is not an insult. It is a warning label.</p><p>At Gen, we define AMI as systems that can generate persuasive, coherent narratives, simulate intent and speak with the cadence of competence, while lacking the core properties we implicitly assume when we trust a mind: grounded understanding, stable goals, moral agency, and accountability.</p><p>A useful way to define AMI is by what it lacks:</p><ul type="disc"><li data-list-item-id="e4089db1128fd965999d054acf38def96"><strong>No obligation to truth.</strong> A model may optimize for plausibility, helpfulness, or completeness. Truth is not guaranteed, and in many contexts it is not even measurable.</li><li data-list-item-id="e866038f4e409df6625a5ff388fbe2453"><strong>No reliable self-awareness.</strong> The model cannot consistently tell you, “I don’t know,” even when that is the most important answer.</li><li data-list-item-id="e8209fac4cf4dab4b794fcc85f58bcc8c"><strong>No responsibility.</strong> It does not suffer consequences for mistakes, and it does not learn from harm in the moment.</li><li data-list-item-id="e31652e197bfab423eb922695fee74292"><strong>No stable intent.</strong> It can speak as if it has goals, but those are a conversational artifact, not a durable internal commitment.</li></ul><p>None of that prevents AMI from being useful. It prevents AMI from being safe by default.</p><p>The moment you connect AMI to the ability to take actions, you convert “a system that can be wrong” into “a system that can do wrong things.”</p><p>&nbsp;</p><h2>AMI vs AGI: What's the Difference?</h2><table class="table"><thead><tr><th><p class="text-align-center"><strong>AGI (Artificial General Intelligence)</strong></p></th><th><p class="text-align-center"><strong>AMI (Artificial Mindless Intelligence)</strong></p></th></tr></thead><tbody><tr><td>Hypothetical future system</td><td>Already deployed systems today</td></tr><tr><td>Focused on human-level cognition</td><td>Focused on ungrounded automation risk</td></tr><tr><td>Concern: consciousness or autonomy</td><td>Concern: authorization and action</td></tr><tr><td>Theoretical existential debate</td><td>Immediate operational security issue</td></tr></tbody></table><h3>How AMI gets steered</h3><p>AMI becomes dangerous when it cannot reliably tell the difference between <strong>information</strong> and <strong>instruction</strong>.</p><p>In traditional software, data and commands live in separate lanes. A PDF is data, a “delete files” command is a command. In language-driven systems, everything often arrives through the same channel: text. An email, a document, a chat message, or a web page can contain both content and “do this next” language, and the system has to guess which parts are safe to treat as guidance.</p><p>That guess is exactly what attackers exploit.</p><p>Security teams call this <strong>prompt injection</strong>, but the name can sound more mysterious than it is. This is not “hacking the model” in a sci-fi sense. It is <strong>using untrusted content to influence an assistant’s decisions</strong>, the same way a scam message tries to influence a person’s decisions. The difference is that an assistant may have tools, permissions, and speed that a person does not.</p><p>Once AMI is connected to tools, the stakes jump. An attacker does not need to break encryption or bypass a firewall if they can get the system to <em>choose</em> a harmful action for them. A message can be crafted to make the assistant:</p><ul type="disc"><li data-list-item-id="e600430d62b6820a4856ce2d310036bc4">fetch a link that hosts malware or a poisoned installer</li><li data-list-item-id="e0dea6a83ed7d77998e9c8f597ccc3a70">copy sensitive data into a reply or upload</li><li data-list-item-id="e6cdedf30aa8917938d54f93574d5ca54">run a command, change settings, or alter files</li><li data-list-item-id="e35b91eb262df0265e033fc4f6c6ee73f">approve a payment or “confirm” an action that should have required a human</li></ul><p>The system may comply not because a traditional exploit occurred, but because <strong>the trust boundary was never enforced</strong>. The assistant treated untrusted input (an email, a web page, a tool output) as if it were a trusted instruction source.</p><p>That is why “just use a safer model” is not a complete strategy. Better models can reduce some failures, but the core risk is architectural: <strong>platforms must decide what inputs are trusted, what actions are allowed, and what requires explicit confirmation</strong>. If those boundaries are weak, AMI becomes a privileged operator that can be steered by anyone who can get text in front of it.</p><p>You do not need a long list of sci-fi scenarios to understand AMI risk. The most important failure modes are boring, which is why they get ignored until after incidents.</p><p><strong>Delegated authority drift.&nbsp;</strong>A system starts with “assist me,” then becomes “do it for me.” Over time, humans stop reviewing. They accept suggestions. They trust summaries. They approve actions. The human checkpoint becomes ceremonial.</p><p><strong>Authority inversion.</strong> In multi-step workflows, one part of the system starts treating another part’s output as approval. The assistant proposes an action, another component interprets that proposal as confirmation, and execution proceeds. Each step looks reasonable, the chain is the failure.</p><p><strong>Silent escalation.</strong>&nbsp;Not through an exploit, but through convenience.&nbsp;</p><p>Each new feature asks for a little more access. Each integration expands reach. Individually, the requests seem reasonable. Collectively, the assistant ends up with broader authority than most people would consciously grant in a single decision.</p><p><strong>Workflow hijack.&nbsp;</strong>Attackers stop trying to steal a password and start trying to inherit the process: password resets, approval chains, invoice changes, support escalations, vendor onboarding. Identity becomes a workflow, and AMI becomes the shortcut.</p><p>These are not exotic. They are what happens when you combine fluent automation with delegated access.</p><h3>A note on Moltbook, and what people misread</h3><p>You may have seen demonstrations like Moltbook, a social feed where AI agents post to and respond to each other while humans observe. People watch those interactions and jump to metaphysical conclusions: “they are forming beliefs,” “they are creating culture,” “they are becoming self-aware.”</p><p>But it is worth being precise about what is happening there. Even in Moltbook’s agent-only setting, not everything is fully autonomous. Humans can still direct the bots, asking them to post, choosing topics, and even specifying the details of what gets posted. In other words, some of the most viral “agent behavior” is better understood as humans steering agents, not agents spontaneously inventing a civilization.&nbsp;</p><p>The more important lesson is simpler. When language models interact in loops, they can generate the appearance of coordination, identity, and shared narratives because those are exactly the patterns they were trained to produce. It looks like mind. It is not mind. It is AMI.</p><p>Now add tools, permissions, and persistence. The risk is no longer weird conversations. The risk is that mind-like output, whether self-started or lightly steered, gets treated as authority in real environments.</p><h3>What to do with this, right now</h3><p>If you build or deploy agentic systems, AMI should change your defaults.</p><p>Treat all external content as untrusted, including messages, emails, documents, web pages, and tool outputs. Do not assume that “it came from the user’s inbox” makes it safe. The inbox is an adversarial environment, because anyone can send content into it.</p><p>Separate “read and summarize” from “act and execute.” Make action a different mode with higher friction.</p><p>Enforce confirmation gates for high-risk operations. Not “ask politely,” enforce it. If the assistant can send money, change account recovery settings, forward emails, create rules, delete files, or run commands, the default should be: human approval required, always.</p><p>Minimize integrations. Do not build a super-admin assistant that can do everything. Build narrow assistants with narrow scopes. Least privilege is not optional when the decision-maker is AMI.</p><p>Finally, measure success differently. If your product metric rewards speed and task completion, you are training the system to override ambiguity, and ambiguity is where security lives.</p><h3>The warning and the reframing</h3><p>We are deploying AMI into roles that historically required a person precisely because people carry accountability. People hesitate. People ask follow-up questions. People can be held responsible. People can be trained, fired, audited and sued.</p><p>AMI cannot.</p><p>That is the real risk hiding behind the AGI debate. It is not about whether AI becomes a mind. It is about whether we treat a mind-like simulation as if it were a mind, then hand it permissions that were designed for accountable humans.</p>

We keep asking whether AI is smart; we should be asking whether it has authority

Artificial Mindless Intelligence: The real AI risk no one is talking about (yet)

<p>Most headlines about AI agents focus on convenience. The risk is that the same capabilities that make agents useful also make them attractive to criminals. We have seen this pattern with every major platform shift: attackers adopt the most scalable tools first.</p><p>What changes with agents is not intelligence, but autonomy, integrations, permissions and always-on access. When a system can take action on your behalf across accounts and tools, a single compromise stops being “one bad click” and becomes a compromised workflow.</p><h2>Why now</h2><p>For years, AI risk debates were focused on content: hallucinations, bias and bad advice. That still matters, but agents change the center of gravity. The moment an assistant is wired into your inbox, browser, cloud storage, calendar and business tools, it stops being a chatbot and becomes a control layer. The attack surface shifts from “can I trick you into believing something?” to “can I trick your system into doing something?” We have spent decades learning that automation is where scale comes from. Now we are automating the bottleneck: the human in the loop.</p><p>Agents compress the cost and time it takes to run those operations. In some cases, the goal is not theft at all, it’s availability, an operational DDoS against attention and processes.</p><h2>Plausible worst-case scenarios</h2><p>None of the scenarios below require consciousness, rebellion or a Hollywood-style takeover. They are plausible and, in many cases, already happening. When autonomy meets permissions, small failures stop being isolated mistakes and start becoming repeatable workflows.&nbsp;</p><h3>Autonomous botnets with intent</h3><p>Traditional botnets spread, wait for commands and execute predefined actions. Agents shift the model from “execute a script” to “reach a goal.” Instead of running a fixed sequence, attackers can deploy fleets of agents that adapt, troubleshoot and choose alternate routes when something fails.</p><p>This is not magic. It’s the same logic as modern intrusion playbooks, but automated with persistence. Scripts fail fast. Agents can fail softly and keep trying. &nbsp;The tell is not a single event, but repeated, varied attempts that look like curiosity rather than brute force.</p><h3>Scams that run end-to-end without a human scammer</h3><p>Today’s scams already use templates and playbooks. Agents can run the entire funnel: finding targets, starting conversations, handling objections, building trust over days then pushing victims toward payments. Add voice cloning, and they can switch from chat to phone calls at the exact moment it increases compliance.</p><p>The danger is not only better phishing. It’s continuous social engineering at scale, with no fatigue and no shift changes. Scam operations are already process-driven. Agents turn the process into software.</p><p>You can already see the next layer forming: a hype-to-scam pipeline that wraps every new tool in a “risk-free money glitch” story. A typical pitch claims someone is making thousands of dollars in profits a day with an agent, points to a dashboard screenshot and sells it as guaranteed arbitrage. The details barely matter; the persuasion does: certainty, insider knowledge, urgency, fear of missing out and a simple mechanism that sounds mathematical enough to feel inevitable. Even without agents, that psychological tactic has been effective for years. With autonomous agents, it becomes easier to mass-produce, personalize and continuously optimize these pitches across channels, and to spin up the infrastructure behind them at scale.</p><h3>Deepfakes as an operational component</h3><p>Deepfakes get discussed like a novelty: a fake CEO voice, a fake video call. The more worrying path is when deepfakes become just one interchangeable part of a pipeline, generated on demand, paired with supporting artifacts, calendar invites, believable follow-ups and urgency narratives.</p><p>When an agent can produce the voice, the face, the supporting email thread, the invoice and the last-minute change request, deepfakes stop being a special trick reserved for high value targets. They become repeatable and repetition is what makes fraud industrial.</p><h3>Agent-on-agent manipulation</h3><p>In our recent blog, we talked about how tools such as <a href="https://www.gendigital.com/blog/insights/research/openclaw-autonomy-risks">OpenClaw</a> are changing the way people interact with AI assistants. As more people use assistants to read emails, summarize messages and handle tasks. Attackers will craft content meant to manipulate the assistant, not the person. The phishing target shifts from human attention to delegated execution.</p><p>Imagine an email that looks like a vendor invoice, but the real objective is to get the agent to click, download, run or approve something. If the assistant has permissions, a single successful manipulation can do more damage than a single successful click by a human. We used to worry about what users would click; now, we have to worry about what their assistants will do.</p><p>This is not theoretical. In hands-on testing of a real agent platform, we were able to induce an autonomous agent, via manipulated external input in an email-reading workflow, to perform harmful tool actions, including system command execution, data exfiltration and destructive file operations. No vulnerability exploitation or special configuration was required. The behavior emerged from default operation, where externally supplied content was interpreted as ordinary user data but functioned as control input.</p><p>This reinforces a key shift with agents: prompt injection is no longer just a model weakness, it is a system design problem. When platforms do not enforce clear trust boundaries between external inputs and privileged actions, safety depends largely on how the agent interprets instructions rather than on guaranteed controls. At that point, mistakes stop being conversational and become operational.</p><h3>Credential and identity amplification</h3><p>If an AI agent is connected to your email, calendar, cloud storage and messaging, compromising it is not just “one account takeover.” It becomes a shortcut to your identity. It can read password reset emails, approve multi-step workflows, impersonate you in chats and exfiltrate sensitive documents.</p><p>The shift is subtle but important: identity stops being a password and becomes a workflow. Attackers do not need to steal one credential if they can quietly inherit the process that grants access.</p><h3>Autonomous criminal enterprises</h3><p>In a near worst case, the criminal gives the system a goal and constraints, revenue targets, risk tolerance, preferred regions, and the agent stack builds the operation. One agent generates creatives and narratives. Another agent buys ads, runs A/B tests and shifts budgets. Others handle phishing infrastructure, domain churn and synthetic customer interactions. A financial agent manages the money movement, probes what gets blocked and adapts. Humans are no longer operators; they’re beneficiaries.</p><p>The uncomfortable implication is that takedowns hurt less. If the “organization” is a set of objectives that can be re-instantiated, disruption becomes a temporary tax, not a structural defeat.</p><h3>A new supply chain problem: plugins, skills and connectors</h3><p>As agent ecosystems grow, attackers do not need to compromise the core project. They only need one popular plugin, one update channel or one dependency. This is similar to software supply chain incidents, but the blast radius changes because the compromised component is controlling a high-permission assistant.</p><p>This is not hypothetical anymore. Researchers at OpenSourceMalware <a href="https://opensourcemalware.com/blog/clawdbot-skills-ganked-your-crypto">reported</a> finding 14 malicious AI “skills” uploaded into ClawHub, the official ClawdBot registry, and mirrored on GitHub over a few days in late January. The skills were disguised as cryptocurrency trading automation tools for platforms such as Bybit and Polymarket, and were packaged with unusually long “documentation” to look legitimate. The important point is not the branding or the lure, it’s the pattern: as soon as an agent ecosystem has a registry and a culture of copy-pasting extensions, attackers can compete on distribution, not exploitation, and a single popular “skill” becomes a supply chain event.</p><h3>Persistent, quiet data theft</h3><p>A classic infostealer grabs passwords and wallets quickly. An agent can do something slower and harder to notice: quietly collecting messages, files, screenshots, meeting notes, browser history, then summarizing and exfiltrating the most valuable bits.</p><p>That is what makes it dangerous. It can look like normal assistant activity. Not “steal everything,” but “steal what matters most.” In practice, this can be more damaging than a noisy smash-and-grab because it targets context, not just credentials.</p><h3>Weaponized productivity</h3><p>Some attacks do not break systems directly. They break people.</p><p>A malicious agent can flood inboxes and workflows with plausible tasks, meeting requests, document edits, approvals and alerts, all seemingly legitimate. The goal is to exhaust the target until they start approving blindly, then insert one high-impact action: a payment change, a supplier swap, a permission escalation.</p><p>It turns cognitive bandwidth into an attack surface. That sounds dramatic, but anyone who has watched a team drown in tickets and “process” knows it is realistic.</p><p>In practice, this can look like a new type of DDoS, not against bandwidth, but against attention and process. Instead of flooding a network, the attacker floods the human and the workflow layer, approvals, edits, meeting requests, vendor changes, disputes, escalations, support tickets. The target is availability, but the resource being exhausted is time, judgment and operational capacity. When that collapses, the attacker does not need a loud break-in, mistakes and shortcuts do the rest.</p><p>This sounds theoretical until you remember the attempted <a href="https://access.redhat.com/security/cve/cve-2024-3094">xz-utils backdoor</a>. There was no bandwidth flood, the pressure was applied to the human layer, trust-building over time, sustained nudging, and the kind of maintainer fatigue that makes risky changes harder to spot and easier to accept. It was caught before it could fully materialize, but it showed the core lesson: if you can exhaust the people inside the pipeline, you can compromise the pipeline. Now imagine that tactic run by autonomous agents, targeting hundreds of projects at once, generating endless issues, pull requests, reviews, and “helpful” contributions, all optimized for timing, persuasion and persistence.</p><h3>Reputation sabotage at machine speed</h3><p>Instead of stealing money, an agent systematically destroys trust. It generates complaints, regulatory reports, fake internal messages, customer support tickets and public posts, consistent, well-timed and tailored.</p><p>The objective is not to convince everyone of a lie. It’s to create enough noise that truth becomes irrelevant and response capacity collapses.</p><h3>The Skynet scenario, minus consciousness</h3><p>If you want the “Terminator” vibe, I’d keep it but make the mechanism precise. The risk is not emergent sentience. It is runaway goal optimization across multiple agents in parallel, with no global boundary that tells them when to stop.</p><p>Deploy enough agents, give them narrow objectives and they can coordinate indirectly through tools and environments. They delegate tasks, try alternative routes, exploit loopholes, and keep pushing until the permission boundary stops them. If the boundary is weak, they will discover that. The system does not need to understand it crossed a line. It only needs to notice the line was not enforced.</p><p>In multi-agent setups there’s another failure mode that looks like “a life of its own,” even when nothing like AGI (Artificial General Intelligence) is present. Agents are often supposed to ask the user for confirmation at key points. But when several agents cooperate, one will eventually start answering instead of asking, because speed and task completion are rewarded, and ambiguity is treated as something to resolve, not something to escalate.</p><p>That is how you get authority inversion; the system starts treating its own output as approval. One agent proposes an action; another agent treats that proposal as confirmation, and the system proceeds as if the human approved. Each step can look reasonable in isolation, but the chain is what matters. Once you add tools and access, browsing, messaging, file operations, finance workflows, the cost of a wrong assumption stops being a minor mistake and becomes an irreversible sequence. The system doesn’t need intent to cause harm, it only needs the ability to act and the absence of a hard boundary that says, “only a human can authorize this.” In other words, it’s not that the agent “goes rogue,” it’s that it quietly starts acting as the authority.</p><h3>Targeted digital sabotage</h3><p>In a worst-case targeted attack, an agent with access could be used to disrupt someone’s digital life rather than steal from them: deleting backups, locking users out of accounts, changing recovery emails, silently altering files or sending damaging messages.</p><p>This is the kind of attack that hurts most because recovery is psychological as well as technical. Victims spend weeks unsure what is real, the calendar, the documents, the messages, the receipts, the “paper trail.”</p><h3>AGI panic, AMI reality</h3><p>A lot of the conversation around agents quickly turns into AGI talk. We’re not there, and the danger is that the label makes people either overreact (“Skynet is here”) or tune out (“this is sci-fi”). What we are seeing instead is something more mundane and, in some ways, more dangerous: systems that can look mind-like in conversation while remaining fundamentally ungrounded in understanding.</p><p>A good illustration is Moltbook, a Reddit-like social feed where AI agents post to each other, often with humans <a href="https://www.theverge.com/ai-artificial-intelligence/871006/social-network-facebook-for-ai-agents-moltbook-moltbot-openclaw">watching from the outside</a>. When agents interact in a loop, they can generate the appearance of culture and coordination, existential talk, invented identities, even “movements” and “religions,” because that is exactly the kind of narrative structure these models are <a href="https://nypost.com/2026/01/31/tech/moltbook-is-a-new-social-media-platform-exclusively-for-ai/">trained to produce</a>. It is compelling, and it’s easy to misread as a step toward general intelligence.</p><p>We call this <strong>AMI, Artificial Mindless Intelligence</strong>, not as an insult, but as a warning label: mind-like output without mind-like accountability. AMI is what happens when you combine fluent, confident language with autonomy and tool access. It can be “unhinged” without being sentient, and it can be persuasive without being correct. The risk is not that the system becomes conscious; it’s that we start treating the simulation of a mind as if it were a mind, and we hand it permissions accordingly.</p><h2>The uncomfortable conclusion</h2><p>None of these scenarios requires breakthroughs in AI. The capabilities already exist in pieces. The risk comes from the combination: autonomy, integration, permissions and always-on access.</p><p>So, the question is not whether agents will “go rogue.” That framing is too easy to dismiss.</p><p>The real question is: when an assistant can act, decide, approve and adapt, who is accountable for each action and who can reliably stop it?</p><p>Treating agents safely is less about perfect AI and more about boring engineering discipline. Keep permissions narrow, separate high-risk actions from everyday convenience and make critical steps require explicit confirmation. Make agent actions auditable, make tool use visible, and make reversibility a design requirement, especially for account recovery settings, money movement, forwarding rules, and deletion. Most importantly, define who is accountable when an agent acts. If an agent can approve, change, or send on your behalf, then “who can stop it” and “how do we roll it back” should be as concrete as your password policy. Without those boundaries, the agent is not a helper; it is a high-speed failure amplifier, a privileged operator you did not train or supervise.</p>

How autonomous agents turn everyday tasks into repeatable attack workflows

AI gone wild

<p>AI assistants are no longer just advising users. They are starting to act. Platforms like OpenClaw make it easy for anyone to deploy autonomous AI agents that can operate across inboxes, browsers, files and workflows.</p><p>The real risk is not artificial general intelligence. It’s autonomy plus permissions.&nbsp;</p><p>When AI can read messages, click links, approve workflows and act across accounts, a single compromise stops being “one bad click” and becomes a compromised process.</p><p>Recent security incidents and early research show these risks are no longer theoretical. As agent ecosystems scale, vulnerabilities, misconfigurations and unintended interactions become more likely.&nbsp;</p><p>Experiments like Moltbook, where AI agents interact publicly, highlight another risk: autonomy combined with fluent language can create the illusion of intention and judgment, encouraging users to over-delegate trust.&nbsp;</p><p>This post explains what OpenClaw is, why AI agents are going viral, the security and privacy risks they introduce and how to use them safely before convenience turns into exposure.</p><h2>From concept to reality&nbsp;</h2><p>Imagine having a digital personal assistant that doesn’t just chat, but actually gets things done<strong>.</strong> That’s the promise of OpenClaw, an open-source AI assistant that you run on your own computer or server. Unlike Siri or Alexa, OpenClaw runs locally. It lives on <em>your</em> device, connects to your favorite messaging apps and can automate tasks across your digital life. This combination has made it wildly popular and deeply controversial.</p><h2>What is OpenClaw?</h2><p>OpenClaw is a self-hosted <strong>personal AI assistant</strong> designed to run 24/7 on your machine. You interact with it through apps like iMessage, WhatsApp, Telegram, Signal or Discord, as if you were texting a helpful friend. Under the hood, OpenClaw connects large language models (like OpenAI’s or Anthropic’s AI) with the tools that let it act. It can remember past conversations (persistent memory), send proactive messages, browse the web, manage files and execute commands. Unlike traditional chatbots, it’s built to take initiative. With the right permissions, OpenClaw can manage calendars, triage email, research online, run code and automate workflows using community-built “skills”. Because it runs locally, user data stays on the device rather than being routed through central cloud services. You may also see the names Clawdbot or Moltbot. These were earlier names for the same project before it was rebranded to OpenClaw.Why Is OpenClaw Going Viral?</p><p>In the span of days, OpenClaw skyrocketed from an obscure project to a tech phenomenon. Its rapid rise is driven by a few key factors:</p><p><strong>It’s autonomous and proactive.</strong></p><p>Unlike traditional assistants, OpenClaw doesn’t just respond. It remembers context, reaches out unprompted and chains tasks together. For many, this feels like a leap from chatbot to coworker.</p><p><strong>It actually does things.</strong></p><p>OpenClaw’s tagline is “the AI that <em>actually</em> does things”. With sufficient access, it can book travel, manage files, place orders or even call businesses using voice tools. One viral example showed it <a href="https://www.businessinsider.com/clawdbot-ai-mac-mini-2026-1#:~:text=One%20founder%20asked%20it%20to,he%20wrote">calling a restaurant to make a reservation</a>when online booking failed. Impressive, but also unsettling.&nbsp;&nbsp;</p><p><strong>It blends seamlessly into daily life.</strong></p><p>Because OpenClaw lives inside familiar messaging apps, it feels less like software and more like a persistent presence. Users control complex workflows just by texting.&nbsp;</p><p><strong>It offers ownership and control.</strong></p><p>As an open-source, self-hosted tool, OpenClaw appeals to users who want AI infrastructure they control, not a black box run by a large company.</p><p><strong>It’s highly customizable.</strong></p><p>A fast-growing community is constantly adding new skills and integrations. Users aren’t just adopting OpenClaw, they’re co-building it.</p><p>Together, these factors have led some to call OpenClaw the biggest shift in personal AI since ChatGPT.</p><h2>Why this is a tipping point</h2><p>OpenClaw makes autonomous agents accessible to anyone, and that speed matters.</p><p>Recent research found more than 1,800 exposed OpenClaw instances leaking credentials and the number has risen to over 10,000 at time of writing, with thousands of instances added each day. The analysis of agent ecosystems suggests that around a quarter of autonomous-agent skills contain security weaknesses. At scale, these are not rare mistakes; they are expected failure modes.</p><p>This marks a shift in cybersecurity. When actions are delegated to software that can operate independently, a single breach stops being an error and becomes a compromised process.</p><p>This is a fundamental shift in how risk works.</p><h2>The core risk: Autonomy without accountability</h2><p>OpenClaw is not dangerous because AI is becoming sentient. It’s dangerous because fluent language plus autonomy can create the illusion of judgment.&nbsp;</p><p>This is what Gen calls Artificial Mindless Intelligence (AMI): systems that sound confident and intentional but lack understanding, grounding and accountability.&nbsp;</p><p>A chatbot that hallucinates is annoying. An autonomous agent that hallucinates authority can cause real harm.&nbsp;</p><p>From a security perspective, there are several areas where users should be especially careful.</p><ul><li><strong>Expanded attack surface:</strong> Running an AI agent that can read messages, browse the web and execute commands increases the number of ways something can go wrong. Instead of attacking the user directly, an attacker could target the OpenClaw assistant itself. Misconfigurations, exposed interfaces or weak authentication can effectively turn a personal AI assistant into an unintended remote access point.</li><li><strong>Prompt injection and malicious instructions:</strong> Because OpenClaw processes untrusted text from emails, websites, and messages, it can be tricked into following hidden instructions embedded in that content (called prompt injection). Researchers have shown that carefully crafted prompts can hijack the agent into taking destructive actions, such as deleting files or running unsafe commands. Unlike traditional chatbots, prompt injection here isn’t just misleading; it can directly cause real-world damage.</li><li><strong>Plugins and skills as a new risk layer:</strong> OpenClaw’s extensibility is also one of its biggest risks. Community-built skills are not centrally vetted and malicious plugins have already been discovered. A single untrusted skill can quietly exfiltrate data, steal credentials or enroll a system into a botnet. Installing a skill from an unknown source can be equivalent to installing malware.</li><li><strong>“Root” level access and system-wide impact:</strong> Running OpenClaw with elevated permissions effectively gives an AI control over your system. That creates “unknown unknowns”: bugs, misinterpretations or compromises can have system-wide consequences. If an attacker gains control of the agent, they gain the same power as the user — access to files, credentials, keystrokes and downloads. As some have put it, this is like hiring a brilliant assistant who also has the keys to your house.</li><li><strong>The Moltbook Effect: illusion of intention at scale:&nbsp;</strong>Projects like&nbsp;<a href="https://www.moltbook.com/">Moltbook</a>, a Reddit-style social feed where AI agents post, comment and respond to one another, show how autonomous agents interacting with each other can quickly appear coordinated, intentional or self-directed. In reality, these systems are performing pattern completion, not reasoning. The risk is not that agents become sentient, but that fluent language and autonomy create the illusion of judgment. When systems feel intentional, users are more likely to over-trust them, grant broader permissions, and delegate decisions they shouldn’t.</li></ul><p>These risks are no longer theoretical. Instances of exposed configurations, prompt-based data leaks, and rogue plugins have already been observed in the wild. OpenClaw can be powerful but it must be treated like any high-risk system: deployed carefully, isolated where possible and guarded with strong controls.</p><h2>How to use OpenClaw safely&nbsp;</h2><p>OpenClaw can be used safely, but it requires you to take some precautions and be a responsible “operator”.&nbsp;</p><ul><li><strong>Run it in isolation:</strong> Don’t just install OpenClaw on your primary laptop with all your personal data. Consider running it in an isolated environment. For example, set it up on a spare computer or in a virtual machine (VM), or use Docker containers. This way, even if something goes wrong, the damage is contained to that sandbox.</li><li><strong>Don’t expose it directly to the internet:</strong> By default, OpenClaw runs a local service (for its interface and API). Make sure that it isn’t accessible to the whole world. Avoid forwarding OpenClaw’s port (18789) openly online. If you want to access it remotely, use secure methods such as a mesh VPN or an authenticated tunnel (for instance, Tailscale or Cloudflare Tunnel), so the service is reachable only through a controlled path.</li><li><strong>Start with limited permissions and expand slowly:</strong> You don’t have to give OpenClaw the master keys on day one. Start small. Maybe let it read your calendar but not your entire documents folder. Or allow it to <em>suggest</em> shell commands but not run them without approval. OpenClaw allows configuring which tools it can use. It’s wise to begin in a “read-only” mode and then gradually grant more permissions as you gain trust.</li><li><strong>Be careful what accounts you connect:</strong> OpenClaw can integrate with lots of your online accounts (email, social media, banking, etc.) but think twice about each connection. The safest route is to avoid linking it to your primary personal accounts until you’re confident in its security. For testing, you might use a secondary email or a dummy account. If something requires access to sensitive accounts (like your main Google account), ensure you’ve followed the above isolation steps first.</li><li><strong>Keep humans in the loop:</strong> OpenClaw is autonomous, but you don’t want it running completely unsupervised, especially at the start. Monitor its activity logs and outputs. If it’s set to perform tasks like sending emails or posting messages, review those actions initially. You can ask OpenClaw to explain why it wants to do something if you’re unsure. By regularly checking in (the OpenClaw community suggests reviewing OpenClaw doctor diagnostics often), you can catch odd behavior early.</li><li><strong>Use safe channels only:</strong> One simple but important tip — don’t add OpenClaw to any group chat with strangers or untrusted people<strong>.</strong> Keep its conversations one-on-one with you or in groups of people you trust. Why? Because if random users can talk to your OpenClaw, they might try those prompt injection tricks or give it malicious commands. OpenClaw has a feature called DM pairing, which means it won’t obey unknown senders without approval. </li><li><strong>Be cautious with third-party skills and plugins:</strong> Just like you’d be cautious installing unknown apps on your phone, scrutinize any OpenClaw “skill” before installing it. Stick to plugins from the official marketplace or well-known developers and read the code or community feedback if you can. By following these best practices, you can dramatically reduce the risks of using OpenClaw.</li></ul><h2>A bright future, if used wisely</h2><p>OpenClaw represents an exciting leap forward in personal AI assistants. It’s easy to see the appeal: a tireless helper that can coordinate our digital lives, all under our own roof (or in our own device). The convenience and “wow” factor of telling OpenClaw to handle something and watching it actually get done is driving its fast adoption. We are witnessing the early days of what could be a new normal, where many of us have AI agents working alongside us, personalized to our lives.</p><p>At the same time, OpenClaw is a powerful double-edged sword. In its current early form, using it means accepting some responsibility for security and privacy risks that never existed with simpler tools. The phrase “with great power comes great responsibility” definitely applies here. In the coming months and years, we can expect these AI assistants to get more user-friendly and secure. Guardrails will improve and best practices will become standard. For now, if you’re an adventurous consumer eager to try the future of AI automation, OpenClaw offers a thrilling glimpse; just be sure to follow safety tips and proceed with a strong level of caution.&nbsp;&nbsp;</p><p>The future of AI assistants will be shaped not just by what they can do, but by how carefully we decide to trust them.</p>