Security Evangelist at Gen

Malware Researcher

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

Threat Researcher at Gen

Research

<h4>Key Points&nbsp;</h4><ul><li data-list-item-id="e43a143fd054561c50dba51071686adff">Gen Threat Labs has been tracking GoFlateLoader, a widespread Golang loader used to deliver multiple infostealers, including Amatera, Remus, Lumma, Vidar and StealC.&nbsp;</li><li data-list-item-id="e3d3b5d0814ea5b26aa75a8d3d6013a39">GoFlateLoader appears both in x86 (32-bit) and x86-64 (64-bit) variants, matching the bitness of the payload it is supposed to execute.&nbsp;</li><li data-list-item-id="e51ccafcfb8c418d894aeb685004a0ba5">The loader is designed for in-memory payload execution and is deliberately inflated with a massive PE overlay to hinder detection</li><li data-list-item-id="ec4bafef8a1113d24bc2b4b3a943228d1">The two main delivery paths are via supposedly cracked software and a <a href="https://research.checkpoint.com/2026/impersonation-click-hijacking-and-tds-inside-a-malware-distribution-ecosystem/" target="_blank" rel="noreferrer noopener">malicious TDS recently documented by Check Point Research</a>, which may redirect users to dedicated landing pages serving password-protected archives containing GoFlateLoader.&nbsp;</li></ul><h4>Introduction&nbsp;</h4>Not every threat that matters is technically sophisticated, and that is also the case with GoFlateLoader, which is a rather simple loader written in Go, whose sole purpose is to decode and execute the payload in memory. What stands out the most is not what the loader does but rather what it does not do – it comes without anti-debugging, anti-VM, or sandbox-evasion checks, and also lacks API hashing or CFG obfuscation, the kind of tricks that loaders almost always come with. Instead, GoFlateLoader relies on one of the simplest yet still effective tricks to stay under the radar – it appends a massive PE overlay at the end of the file, deliberately inflating the binary's size (hence the name GoFlateLoader).&nbsp;Nevertheless, it is important to understand that malware does not necessarily need to be elegant or stealthy. In the end, the only thing that matters to attackers is whether it can successfully deliver the final payload. And if that is the only metric, GoFlateLoader appears to be working fairly well for its operators, as we continue to see it widely distributed across our user base. Since the beginning of April, we have protected more than 33,000 unique users from it, with the most affected countries including Brazil, India, Argentina, Mexico, Turkey and Spain.&nbsp;

<h4>GoFlateLoader’s Execution Flow&nbsp;</h4>If we strip away the obfuscation noise that the Go compiler and the author’s decoy code add, the loader’s execution flow is short and linear:&nbsp;<ul type="disc"><li data-list-item-id="efa51af3b2859fd9c684efca0c82d3b66">Copy the encoded payload blob from the <code>.rdata</code> section onto the stack.&nbsp;</li><li data-list-item-id="e879bb970c6d1a81b8a42512222aceaa4">Decode the payload using a small, multi-stage, custom byte-level transformation into a valid PE.&nbsp;</li><li data-list-item-id="ebff4f340af15b75cbea0d682b26b7645">Parse the PE headers of the decoded payload (image base, image size, sections, data directories, etc.).&nbsp;</li><li data-list-item-id="e37fb26cad3d18a4a0c8bf9b2595d661f">Allocate an RWX memory region using <code>VirtualAlloc</code> with <code>MEM_COMMIT | MEM_RESERVE</code> and <code>PAGE_EXECUTE_READWRITE</code> flags, trying the payload’s preferred <code>ImageBase</code> first and falling back to an OS-assigned address if that fails.&nbsp;</li><li data-list-item-id="ebbde6d77cdc942c0a6bac79f4f8a6c28">Map the decoded payload into the allocated memory region by copying the PE headers first, then walking the section table and writing each section to its target virtual address.&nbsp;</li><li data-list-item-id="ed16738229e0f5c70a981c0c5f9b715f9">Apply relocations (only if preferred base mapping fails).&nbsp;</li><li data-list-item-id="e76cde4bae1be6c21b897c350c6fd15db">Resolve imports by walking the standard <code>IMAGE_IMPORT_DESCRIPTOR</code> table and rebuild the IAT in place via <code>LoadLibrary</code> and<code> GetProcAddress</code>.&nbsp;</li><li data-list-item-id="e786887a3d34fc7ce344ee8375944799e">Transfer execution to the final payload using Go’s <code>syscall.Syscall</code>.&nbsp;</li></ul>&nbsp;This is essentially a textbook example of manual PE loading with the payload reconstructed and executed entirely in memory so that it never touches the disk.&nbsp;&nbsp;

Notably, GoFlateLoader transfers execution to the final payload via <code>syscall.Syscall</code>. In Go, <code>syscall.Syscall</code> has the signature <code>Syscall(trap, nargs, a1, a2, a3)</code>, where <code>trap</code> is the function pointer to invoke, <code>nargs </code>is the argument count, and <code>a1</code>, <code>a2</code>, and <code>a3</code> are the first three arguments passed to the target function. Here, trap is set to point to the final payload’s entry point, <code>nargs</code> is set to <code>1</code>, and since the execution is transferred to that entry point, the remaining arguments serve only as filler values and are never used by the invoked payload. In other words, GoFlateLoader is not issuing a <code>syscall</code> at all, but abusing <code>syscall.Syscall</code> as a generic call gate to hand control to the payload.&nbsp;&nbsp;It is worth emphasizing that GoFlateLoader consistently sets these arguments to the hardcoded values <code>1</code>, <code>2</code>, <code>3</code>, and <code>4</code>, which is unusual enough to stand out as a potential detection opportunity (combined with other patterns).&nbsp;

The loader also carries substantial junk/decoy code, which varies across builds and serves no purpose other than padding the control flow and complicating static analysis.&nbsp;&nbsp;&nbsp;<h4>Inflated PE Overlay&nbsp;</h4>GoFlateLoader’s defining characteristic is its massive size (typically 700-950 MB), caused by an artificially inflated PE overlay appended to the original loader.&nbsp;

This is a deliberate design choice intended to bypass detection, as excessively large executable files may pose challenges for AVs and EDRs, primarily due to performance and resource constraints. As a result, to preserve performance and avoid noticeable impact to end users, these solutions often enforce practical file-size limits for deep scanning and/or emulation.&nbsp;The same logic extends to automated analysis pipelines – bloated files frequently cause timeouts during heuristic analysis and effectively prevent the sample from being uploaded to cloud-based sandboxes or threat intelligence platforms, which enforce their own strict upload limits to manage bandwidth and storage costs. A prime example is VirusTotal, which enforces a strict 650 MB upload limit. The fact that GoFlateLoader consistently sits just above this threshold strongly suggests that VirusTotal is one of the platforms it specifically aims to evade.&nbsp;&nbsp;In most cases, GoFlateLoader’s PE overlays are filled with null bytes, though we have also observed builds with random padding.&nbsp;&nbsp;

Crucially, adding such a PE overlay comes at virtually no distribution cost for attackers, as the inflated data compresses to a fraction of its original size (assuming constant padding).&nbsp;&nbsp;<h4>Delivered Final Payloads&nbsp;</h4>The final payloads distributed through GoFlateLoader are predominantly information stealers, with the most prevalent currently being Amatera, <a href="https://www.gendigital.com/blog/insights/research/remus-64bit-variant-of-lumma-stealer" target="_blank" rel="noreferrer noopener">Remus</a>, and Lumma. Beyond these, we have also observed it distributing Vidar, StealC, and SvitStealer.&nbsp;GoFlateLoader comes in both x86 and x86-64 variants, with each variant matched to the architecture of the payload it is intended to execute.&nbsp;&nbsp;As for how GoFlateLoader binaries are distributed, we have observed at least two notable delivery paths. The first is through supposedly cracked software. The second involves the payload being served via <a href="https://research.checkpoint.com/2026/impersonation-click-hijacking-and-tds-inside-a-malware-distribution-ecosystem/" target="_blank" rel="noreferrer noopener">the malicious TDS recently described by Check Point Research</a>, which redirects users to a landing page that offers a downloadable archive and separately displays the password required to extract it. This approach provides several advantages for the threat actor. First, compression significantly reduces the binary size due to the constant-padded PE overlay. Second, because the archive password is displayed separately on the landing page, it makes it harder for AV and EDR solutions to obtain it and decrypt the archive. As a result, the payload may remain concealed until the victim manually extracts it.&nbsp;&nbsp;&nbsp;<h4>Summary&nbsp;</h4>GoFlateLoader is a reminder that prevalence and sophistication are not the same thing. At its core, it is a rather simple manual in-memory PE loader written in Go, with no novel anti-analysis tricks under the hood. Whatever evasion it achieves comes not from obfuscation or other anti-analysis tricks but from its size – the appended PE overlay is built to slip past size-constrained scanners and automated analysis pipelines. Yet, despite its low level of sophistication, GoFlateLoader remains an active and relevant threat, used to deliver a wide range of prevalent information stealers.&nbsp;&nbsp;Gen products protect our users against both GoFlateLoader and the payloads it delivers.&nbsp;&nbsp;<h4>Indicators of Compromise (IoCs)&nbsp;</h4>Note: The files listed in the IoCs that are not archives all exceed 650 MB in size and are therefore not available on VirusTotal.&nbsp;b88c5744975d2abb447aecc6c090fee9f8580413f4612eecdc6ed1973e8a1739 (password-protected archive containing GoFlateLoader x64 variant loading Remus; pwd: 1234)&nbsp;ed5ae7f36453c5a23e9868a5729d67e0549a11f6dea54f5f52d654a8f51d4902 (archive containing GoFlateLoader x64 variant loading Remus)&nbsp;841c9297cb8a2e0ff89433d13c05bfc760eb2e98e251cb8fa785d2ad7cbac05f (archive containing GoFlateLoader x86 variant loading Amatera)&nbsp;ece7c48eb411b24f26762ede83badb4a644c41d5777129381ac2541804d64fc2 (archive containing GoFlateLoader x86 variant loading Lumma)&nbsp;421ce2d2f49c23bbe9f60ef3b9cd38d7eb912ce02e56a61837656210069bd9e2 (archive containing GoFlateLoader x64 variant loading Vidar)&nbsp;121c2dc793b3873f75a29ec02241f94136de19c049382a50a50d0d5b99507073 (GoFlateLoader x64 variant loading StealC)&nbsp;2415db5081cec9bfd14ad6da1a66169fd96f13a49010c319a73d1ed6fafd4efa (GoFlateLoader x64 variant loading Vidar)&nbsp;d9917ade3b4c125a95b5d3e6343cde26145dfbf569bd7e2a843fd0c6fc8ddc28 (GoFlateLoader x64 variant loading Remus)&nbsp;4cf6893756f441522b94b36f10e5de0e47aeed4743f95c51650746d1ecf97e3d (GoFlateLoader x64 variant loading SvitStealer)&nbsp;8b89d6c9152d3aab97aadd515ecb69ca72654db2f25425759ba4b646853d737d (GoFlateLoader x86 variant loading Lumma)&nbsp;90ce4ff9da23ac150da0a8e17930cab1e369aa349fdc1b65691b70369145664a (GoFlateLoader x86 variant loading Amatera)&nbsp;

 Intentionally Inflated Go Binaries That Use Massive PE Overlays to Bypass Detection

GoFlateLoader: A Widespread Golang Loader Delivering Multiple Infostealers

When we published the first part of this research, we said the investigation was still ongoing. That was not a closing line. We were already looking at the infrastructure, the signals behind the attacks, and the scale of the reservation data abuse we were seeing in our telemetry.&nbsp;Then something else happened.&nbsp;Friends, colleagues, and other contacts started forwarding us messages they had received from Booking.com. The messages warned that unauthorized third parties may have accessed information linked to their reservations. Shortly after, media outlets began reporting the same thing: Booking.com had notified affected customers, reset reservation PINs, and said the accessed information could include names, email addresses, phone numbers, booking details, and information shared with accommodations. Booking.com said financial information was not accessed from its systems.&nbsp;The timing mattered, but not because it started our investigation. It mattered because it publicly confirmed the kind of reservation-data exposure our first article had described from the attack side.&nbsp;<a href="https://us.norton.com/blog/online-scams/reservation-hijacking-scam" target="_blank">Reservation Hijack scams</a> work because criminals do not have to guess. A traveler receives a message about a real booking. The message contains details that make sense: the right accommodation, the right trip context, sometimes the right contact information. The link then opens a fraudulent page built around the same accommodation.&nbsp;A generic <a href="https://us.norton.com/blog/online-scams/what-is-phishing " target="_blank">phishing message</a> has to create trust from nothing. This scam steps into a relationship that already exists between the traveler, the booking platform, and the accommodation.&nbsp;While those public warnings were appearing, Gen Threat Labs continued canvassing the data we had available: blocked URLs, fraudulent landing pages, SMS messages, emails, WhatsApp messages, in-app message evidence, and other signals connected to attacks we had already stopped. We used AI-assisted analysis to connect pieces that would otherwise remain scattered: messages, landing pages, accommodation names, URLs, templates, and infrastructure patterns. Human analysts reviewed the results and separated what we could prove from what we could only suspect.&nbsp;The result is a much clearer picture.&nbsp;We identified more than 350 compromised accommodations linked to the Reservation Hijack scam flows, spread across 50 countries. These were not abstract indicators or generic travel-themed pages. In the cases we analyzed, victims had already received reservation-specific information before being pushed to a fraudulent page customized around the accommodation tied to that booking.&nbsp;That is the difference between ordinary travel phishing and this model. The attackers are not guessing who is traveling. They already have enough reservation context to make the fraud feel normal.&nbsp;And they are doing it at scale.&nbsp;

<h3>How we connected the evidence&nbsp;</h3>The second phase of our investigation was already underway when Booking.com’s customer notifications started circulating publicly.&nbsp;Gen’s view of this activity comes from attacks we blocked before they could complete. No single signal tells the whole story. An SMS or WhatsApp message may show the <a href="https://us.norton.com/blog/emerging-threats/what-is-social-engineering " target="_blank">social engineering</a>. A URL may show the redirect path. A landing page may show the accommodation being impersonated. An in-app message may show where the attacker entered the trusted communication flow. A repeated page structure may link incidents that look separate at first.&nbsp;Put together, those pieces show how reservation data moves from compromise to fraud.&nbsp;AI helped us work through that evidence at scale. We used it to normalize accommodation names, cluster similar messages, compare landing-page structures, connect URLs with page content, and flag repeated patterns across channels. This was not “AI says these attacks are connected.” It was AI-assisted triage followed by human review.&nbsp;From that process, we extracted and cleaned accommodation names from captured fraudulent landing pages and identified 350 compromised accommodations.&nbsp;We use “compromised accommodations” carefully here. It means reservation context tied to those accommodations was compromised and used in an attack flow we intercepted. The source of compromise may vary: a hotel account, a booking platform partner account, an email inbox, a property management system, a guest messaging workflow, or a third-party service provider.&nbsp;The end result for the traveler is the same. Criminals had access to information that should have stayed inside the booking relationship.&nbsp;This is also a conservative number. It only includes attacks where we had enough evidence to connect the flow to a specific accommodation. It does not include people who received a message and never clicked, attacks outside our telemetry, landing pages we did not capture, or cases where the accommodation name could not be reliably extracted.&nbsp;So 350 is not the size of the problem. It is the part we could see clearly.&nbsp;<h3>From scam pattern to repeatable operation&nbsp;</h3>A single compromised hotel account can explain a few victims. A copied phishing kit can explain a short campaign. Hundreds of accommodation-specific scam flows across 50 countries point to something more organized.&nbsp;The model we see is consistent.&nbsp;Reservation context enters the fraud chain, sometimes through compromised accommodation-side accounts, inboxes, partner tools, or data obtained from other criminal actors. That context is then used to contact travelers with details that make the message feel legitimate.&nbsp;The wording, the property, the country change. The logic does not.&nbsp;That is why this follow-up is not simply “we found more cases.” The first article explained <a href="https://www.gendigital.com/blog/insights/research/reservation-hijack-scam">how Reservation Hijack scams work</a>. This one shows how far the model has spread.&nbsp;<h3>A worldwide footprint, led by Europe&nbsp;</h3>The highest number of compromised accommodations in our dataset were linked to Germany, followed by France, the United Kingdom, Italy, Spain, and the United States.&nbsp;Germany accounted for 49 compromised accommodations in the dataset. France followed with 35, the United Kingdom with 31, Italy with 24, Spain with 20, and the United States with 19.&nbsp;Together, the top five European countries, Germany, France, the United Kingdom, Italy, and Spain, accounted for 159 compromised accommodations, about 45% of the full dataset.&nbsp;

The European concentration makes sense. Europe has a dense travel market, a high volume of cross-border bookings, many independent and mid-sized accommodation providers, and a strong dependency on online booking platforms and pre-arrival guest messaging.&nbsp;Those conditions give criminals useful cover. Travelers expect messages before arrival. They expect payment questions, check-in instructions, policy reminders, and booking updates. A well-timed fake message does not feel unusual.&nbsp;But the country distribution also shows that this is not a single-region problem. The activity spreads across 50 countries, with a long tail of destinations beyond the largest clusters.&nbsp;

That long tail matters. It suggests the model is not limited to a few obvious tourist destinations or a handful of famous hotel brands. Once criminals have access to reservation data and a working scam flow, the same approach can be adapted to different countries, languages, property types, and booking habits.&nbsp;The property does not need to be famous. It only needs to be real, tied to a real reservation, and recognizable to the victim.&nbsp;<h3>Not just hotels&nbsp;</h3>Hotels make up the largest share of the dataset, but they are not the whole story.&nbsp;We identified compromised accommodations across several property types: hotels, aparthotels, apartments, inns, motels, lodges, resorts, guesthouses, B&amp;Bs, hostels, villas, bungalows, and capsule hotels.&nbsp;

This is a useful reminder of how fragmented the travel ecosystem really is. A traveler may book a large hotel chain, a family-run guesthouse, a serviced apartment, a hostel, or a villa through similar platforms and messaging flows.&nbsp;From the traveler’s point of view, the trust model is almost the same. They made a booking. They expect communication. They may not know whether the message came from the property, the platform, a channel manager, a property management system, or a compromised account sitting somewhere in between.&nbsp;That is exactly the gap criminals are abusing.&nbsp;<h3>How big could this problem be?&nbsp;</h3>To understand the potential scale of Reservation Hijack scams, we looked at the accommodation properties appearing in our research dataset.&nbsp;In total, we identified 350 accommodation entries linked to reservation hijack scam activity. These were not all the same kind of business. The dataset included hotels, aparthotels, resorts, hostels, guesthouses, villas, apartments and other accommodation types. For each one, we estimated the number of rooms, units, beds or capsules, depending on the property type, and used that to calculate the likely maximum guest capacity.&nbsp;Across the deduplicated dataset, these properties represented an estimated maximum capacity of around 82,000 guests at any given time. Using a conservative occupancy rate of 50% and an average length of stay of 2.5 nights, this translates into approximately 6 million guest stays per year.&nbsp;That does not mean 6 million people were scammed. It does not mean 6 million people had their data exposed. What it shows is the size of the opportunity criminals may be looking at when they compromise accommodation or booking communication channels.&nbsp;A single compromised workflow can give scammers something much more valuable than a random phone number or email address. It can give them context: the name of the accommodation, the dates of the stay, the booking amount, the channel the guest expects to be contacted through, and the right moment to create urgency.&nbsp;That is why Reservation Hijack scams are so convincing. The scam does not feel like spam. It feels like part of the trip.&nbsp;

<h3>The activity does not look random&nbsp;</h3>We are still investigating the infrastructure behind these attacks, so we are not attributing the activity to a named group.&nbsp;But the evidence does not look like hundreds of unrelated actors randomly copying one another.&nbsp;Across the dataset we analyzed, the same fingerprints kept appearing. Many pages used the same internal paths for scripts, images and styles. Several included the same unusual overlay component, repeated internal asset paths, and the same card-validation language, including claims that funds would be reserved and refunded within 10 minutes.&nbsp;The pages were also built to look specific to the victim. Hotel names appeared in page titles and visible content. Prices varied from one case to another. Check-in and check-out dates were inserted into the page. In some cases, page metadata and images were synchronized with the accommodation being impersonated. The evidence points to a repeatable process for turning reservation context into property-specific phishing pages. Taken together, those patterns are consistent with a phishing kit designed to generate accommodation-specific pages at scale, rather than pages built manually for each victim.&nbsp;The phishing pages also included a fake live support chat. To the victim, it looked like part of the booking or payment process, but it was controlled from the phishing infrastructure. The payment step could therefore become a live interaction: someone behind the page could react to the victim’s input, ask for another card, explain away a failed “validation”, push the victim to continue, or try to capture a one-time code while the victim still believed they were talking to booking support.&nbsp;Some of the infrastructure also uses legitimate internet services, including services such as Cloudflare, to place a layer between the visible scam page and the systems behind it. That does not make those services malicious. It means criminals are abusing the same infrastructure that normal websites use, including protective layers that can obscure hosting details, traffic paths, and backend systems.&nbsp;For investigators, this kind of setup makes the infrastructure harder to trace. For travelers, it removes many of the usual warning signs. They see a page that loads normally, shows the right accommodation, includes a support chat, and refers to the trip they actually booked. At that point, many people will treat the request as part of the reservation process, even when it is not.&nbsp;<h3>Correct information is not proof of legitimacy&nbsp;</h3>For years, people have been told to watch for bad spelling, odd sender names, generic greetings, and suspicious links. That advice still helps, but it does not solve this problem.&nbsp;A message can include the right accommodation, the right destination, and details from a real stay, and still be malicious. A page can show the correct hotel name, dates, and a plausible payment amount, and still be fake. A request can arrive at the moment when a traveler expects a check-in or payment message, and still be fraud.&nbsp;Page behavior can create false confidence too. In some of the phishing pages we analyzed, the fake support chat looked like part of the booking or payment process. If the victim had a question, or if the card “validation” failed, the page could keep the interaction going instead of simply collecting data and stopping there.&nbsp;That is what makes Reservation Hijack scams difficult for travelers to judge. The victim is not being tricked only by a fake brand or a fake website. They are being pushed through a process built around real context, at the moment when that context feels normal.&nbsp;Travelers expect hotels and booking platforms to contact them. They expect last-minute requests, check-in instructions, payment checks, ID forms, and confirmation messages. Criminals are not fighting that expectation. They are using it.&nbsp;<h3>What travelers should do&nbsp;</h3>The safest rule is simple: do not treat correct booking information as proof that a message is legitimate.&nbsp;If a message asks you to verify payment details, confirm a reservation, re-enter card information, pay a balance, reset a PIN, or avoid cancellation, do not use the <a href="https://us.norton.com/blog/online-scams/i-clicked-on-a-phishing-link" target="_blank">link in the message</a>.&nbsp;Open the booking platform or hotel app directly. Go to the official website yourself. Use contact details from the original booking confirmation. If needed, call the property using a verified number. Check whether the same request appears inside your official booking account.&nbsp;This applies even if the message mentions the right hotel, the right destination, or details from your stay.&nbsp;Booking.com has told customers that it will not ask guests to share credit card details by email, phone, WhatsApp, or text, or ask for a bank transfer that differs from the payment policy in the booking confirmation.&nbsp;If you already entered payment details into a suspicious page, contact your bank immediately, freeze or cancel the card, and monitor for follow-on fraud. Criminals may reuse the card data later, or sell it to others.&nbsp;<h3>What accommodations should take from this&nbsp;</h3>For hotels and other accommodation providers, this is not only a guest-awareness issue. Guest communication has become part of the attack surface.&nbsp;The systems and workflows between the property and the guest are now valuable targets. That can include hotel staff accounts, booking platform partner accounts, email inboxes, property management systems, guest messaging tools, channel managers, and third-party service providers.&nbsp;The lures we have seen on the accommodation side are not exotic. They look like normal hotel work. Some impersonate Booking.com and claim there is a guest complaint waiting for a response. Others say that a paid reservation needs urgent verification, or that the property’s visibility or ranking may be affected if staff do not act quickly. We have also seen payment and invoice-themed messages designed to make staff open attachments or documents that can lead to credential theft or <a href="https://us.norton.com/blog/malware/signs-of-malware" target="_blank">malware infection</a>.&nbsp;

That is why the first visible sign of a Reservation Hijack scam may not be the message sent to the guest. It may start earlier, with an email to a shared hotel inbox, a fake partner-support notice, a malicious attachment, or a document that looks like part of normal accounting or reservation handling. Once reservation context is obtained, whether directly or through another actor in the criminal ecosystem, it can be used later to make guest-facing scams much more convincing.&nbsp;For accommodation providers, staff training needs to cover the workflows criminals are actually abusing. Urgent complaints, reservation-verification requests, payment advice emails, invoice notifications, security-update prompts, and any message asking staff to open an attachment, enable content, sign in again, or act under time pressure should all be treated as possible entry points into the same fraud chain.&nbsp;The defensive work starts with account protection, but it should not stop there. Accommodation providers need strong <a href="https://us.norton.com/blog/account-safety/multi-factor-authentication" target="_blank">multi-factor authentication</a>, tight control over who can access guest data, monitoring for unusual logins or message patterns, and a clear process for responding when an account may have been abused. The devices used to manage reservations, guest messages, invoices and payment-related emails should also be protected with reliable security protection. Some of the lures we observed were designed to make staff open attachments or documents that could install malware or steal credentials. In those cases, <a href="https://us.norton.com/antivirus" target="_blank">antivirus</a> or endpoint protection may be the last barrier before a compromised inbox becomes a compromised booking workflow.&nbsp;Payment-related communication deserves special attention. If a guest receives a payment or verification request, there should be a reliable way to confirm whether it is real. If an account is suspected of being compromised, guests need to be warned quickly and clearly.&nbsp;The reputational damage can be painful. Even when the property is also a victim, the traveler may remember the incident as “the hotel message that stole my card details.” That makes workflow security part of customer trust.&nbsp;<h3>What the wider travel ecosystem should learn&nbsp;</h3>Reservation Hijack scams sit between several parts of the travel industry. The booking platform may see unusual partner activity. The hotel may see confused guests. The traveler sees a convincing message. The bank sees card fraud. A security company sees the landing page.&nbsp;Each view is partial, and that delay helps the scam continue.&nbsp;The useful signals are often scattered: unusual partner logins, repeated payment-verification language, guest-message spikes, reused templates, fake landing pages, redirects, and infrastructure overlaps. Sharing those signals faster would make it easier to see when separate complaints are really part of the same operation.&nbsp;One compromised accommodation can look like a local incident. Hundreds of compromised accommodations across 50 countries point to a repeatable abuse model.&nbsp;<h3>The next phase of travel fraud&nbsp;</h3>Reservation Hijack scams exploit a simple mistake in how we judge trust online.&nbsp;Travelers think: “This message knows my booking, so it must be real.”&nbsp;Criminals know: “If we have the booking context, the victim will do much of the trust work for us.”&nbsp;The message does not have to be perfect. The website does not have to be flawless. The attacker does not need to convince the victim from zero. They only need to appear inside a relationship that already exists.&nbsp;Our latest data shows that this model has spread well beyond isolated cases. We identified 350 compromised accommodations across 50 countries, covering hotels, apartments, hostels, resorts, guesthouses, villas, and other accommodation types. Together, those properties represent a large travel footprint and millions of estimated annual guest interactions.&nbsp;The investigation is still ongoing. We are continuing to analyze infrastructure, campaign overlaps, and the clues suggesting connected activity behind parts of the operation.&nbsp;For travelers, the lesson is simple.&nbsp;Trust your booking. Do not automatically trust the message.&nbsp;

After our first report, Booking.com began warning customers that reservation data had been accessed. Our continuing investigation shows how criminals are using that data at scale. 

When Hotel Scams Know Your Booking: 350 Compromised Accommodations Across 50 Countries 

Threat Research Team

Attackers replaced selected official download links with malicious installers that deployed a Python bot, r77 rootkit components, and Windows policy-based defense evasion.On May 6, 2026, attackers compromised the official JDownloader website and swapped download links to serve trojanized installers. The JDownloader developers <a href="https://www.reddit.com/r/jdownloader/comments/1t6goqe/is_the_website_hacked/">confirmed the breach</a> within hours, restored clean files, and disclosed a timeline, but acknowledged they didn't know what the malicious installers actually do. We took the malware apart to answer that question.&nbsp;What we found goes well beyond a typical trojanized installer. The payload is a multi-component attack framework: a Python bot protected by PyArmor v9, an r77 rootkit stager with AMSI bypass, and a Windows Defender Application Control (WDAC) policy that blocks 50 security executables from running, including Avast, AVG, Avira, Windows Defender, HitmanPro, and Kaspersky Virus Removal Tool. We reversed the full C2 protocol from the obfuscated Python bytecode and recovered the campaign configuration from the dropper's encrypted strings.&nbsp;<h2>The infection chain</h2>The trojanized installer is unsigned. Windows SmartScreen blocks it, and users who ran it had to manually bypass the warning. Inside, it wraps the legitimate JDownloader installer alongside an XOR-encrypted second-stage PE:

Stage 2 acts as the campaign's quartermaster. It deploys five components from XOR-encrypted resources embedded in its PE (key: <code>fywo</code>):<table class="table"><thead><tr><th>Component</th><th>Purpose</th></tr></thead><tbody><tr><td>PyArmor bot</td><td>The main payload, a Python script with obfuscated bytecode</td></tr><tr><td>PyArmor runtime</td><td>DLL that decrypts the bot's bytecode at execution time</td></tr><tr><td>r77 rootkit stager</td><td>Native x86 PE that hides the bot's process, files, and registry keys</td></tr><tr><td>WDAC Code Integrity policy</td><td>Blocks 50 AV/EDR executables from running after reboot</td></tr><tr><td>Python 3.14.3 installer</td><td>The legitimate Python runtime (needed to run the bot)</td></tr></tbody></table>Before doing any of this, Stage 2 calls <code>WaitForSingleObject</code> with a 300-second timeout — three times in sequence. This 5-minute-per-call delay is designed to outlast automated sandboxes, which typically give samples 2-5 minutes of execution time. One sandbox vendor recorded an 8-minute total wait before any malicious behavior appeared.&nbsp;<h2>Killing your antivirus before it can fight back</h2>The most operationally significant component is the WDAC Code Integrity policy.Windows Defender Application Control (WDAC) policies tell the operating system which executables are allowed to run. The attackers deploy a deny-list policy to <code>%WINDIR%\System32\CodeIntegrity\SIPolicy.p7b</code> that blocks 50 executable paths across six security vendors plus core Windows security services:<table class="table"><thead><tr><th>Target</th><th>Blocked executables</th></tr></thead><tbody><tr><td>Avast</td><td>AvastSvc.exe, AvastUI.exe, afwServ.exe, aswEngSrv.exe, aswidsagent.exe, aswToolsSvc.exe, wsc_proxy.exe, Icarus components, Overseer</td></tr><tr><td>AVG</td><td>All executables under Program Files\AVG\Antivirus</td></tr><tr><td>Avira</td><td>Security, VPN, Fallback Updater, Optimizer Host, Endpoint Protection SDK</td></tr><tr><td>Windows Defender</td><td>MsMpEng.exe, MpCmdRun.exe, MpDefenderCoreService.exe</td></tr><tr><td>Windows Security</td><td>SecurityHealthHost.exe, SecurityHealthService.exe, SecurityHealthSystray.exe</td></tr><tr><td>Windows Update</td><td>MoUsoCoreWorker.exe, wuauclt.exe, wusa.exe</td></tr><tr><td>Others</td><td>HitmanPro, Kaspersky Virus Removal Tool, Farbar Recovery Scan Tool</td></tr></tbody></table>After the next reboot, none of these executables can start. The AV service is effectively dead. It won't run, it can't scan, and Windows Update can't push signature updates. One victim in the Reddit thread reported that Windows Defender disappeared entirely after running the trojanized installer.This is a known but uncommon TTP (MITRE T1562.001). It requires the installer to run elevated, which the SmartScreen bypass dialog would have prompted for. Users who clicked through both warnings — SmartScreen and UAC — gave the malware everything it needed.<h2>&nbsp;</h2><h2>How the dropper provisions the bot</h2>Stage 2's strings are all XOR-obfuscated with the same <code>fywo</code> key used for its resources. After deobfuscation, we recovered 122 strings including registry paths, API names, and encrypted configuration values.The dropper writes the bot's initial configuration to <code>HKCU\SOFTWARE\Python</code>. Both the registry value names and data are RC4-encrypted and hex-encoded — making the registry entries look like random hex strings to casual inspection. We recovered two configuration values:<ul><li data-list-item-id="e15e9100cccadef17d91598e244b0b038">CampaignID a unique identifier for this campaign, used during bot registration with the C2 server.</li><li data-list-item-id="e7a2666057614636498fba93e483028cf">DDRList six dead-drop resolver URLs that the bot uses to discover its C2 servers (detailed in the next section).</li></ul>Notably, the dropper does not write a C2 server list directly. The bot discovers its command-and-control addresses exclusively through the dead-drop resolver mechanism — a design choice that makes the infrastructure resilient to takedowns.&nbsp;<h2>Dead-drop resolvers: how the bot finds its C2</h2>A dead-drop resolver (DDR) is an intermediary, a legitimate web page where the operator publishes encrypted C2 addresses. The bot fetches the page, extracts and decrypts the content, and connects to whatever C2 servers it finds. If the operator needs to rotate infrastructure, they update the DDR page and every infected machine follows automatically.The bot reads its DDR list from the registry, fetches each URL, and RC4-decrypts the page content. Valid payloads start with the prefix <code>VAL:</code> followed by a semicolon-separated list of C2 URLs.We extracted all six dead-drop resolver URLs from the dropper and probed them:<table class="table"><thead><tr><th>URL</th><th>Status</th><th>Decrypted content</th></tr></thead><tbody><tr><td><code>telegra[.]ph/tr02-05-02</code></td><td>Live</td><td>C2 list: parkspringshotel[.]com + auraguest[.]lk</td></tr><tr><td><code>telegra[.]ph/ki06-05-02</code></td><td>Live</td><td><code>VAL:XX</code> — placeholder for future C2 rotation</td></tr><tr><td><code>rentry[.]co/zzk7opdu</code></td><td>Live</td><td>Same C2 list</td></tr><tr><td><code>rentry[.]org/wayc2qqz</code></td><td>Live</td><td><code>VAL:XX</code> — placeholder</td></tr><tr><td><code>codeberg[.]org/etienne74/guix/...</code></td><td>404</td><td>Removed or never created</td></tr><tr><td>`2wxjoz6lkdxkniksujbdknkugweemx7uvxdr4ejgyipce4tnvktvbvqd.onion/t`</td><td>Not probed</td><td>Tor hidden service DDR</td></tr></tbody></table>The operator has two live C2 servers and four reserve dead-drop pages — two stubs ready for C2 rotation and one Tor fallback. If the current C2 infrastructure gets burned, the operator updates a Telegraph or Rentry page and every infected machine picks up the new address on its next poll cycle.Beyond the dead-drop mechanism, the bot has a domain generation algorithm (DGA) as a last-resort fallback. It combines four seeds (<code>XNerWs4I</code>, <code>e55gegnW</code>, <code>RjWN0Y9m</code>, <code>AemOU1co</code>) with 14 TLDs and an ISO-week-based rotation to produce 56 candidate domains per week. We probed all current DGA domains — none are registered. The operator is running purely on dead-drop infrastructure for now, but the DGA ensures the botnet can survive even if all resolver pages and C2 servers are taken down simultaneously.&nbsp;<h2>The C2 protocol: RSA-OAEP wrapping AES-GCM</h2>We reversed the bot's full communication protocol from the PyArmor-protected bytecode. It uses a layered encryption scheme designed to prevent passive interception and session tampering:

The bot wraps a fresh AES-256 key with the hardcoded RSA-2048 public key (OAEP, SHA-256) and sends it to the C2. The server proves possession of the private key by returning <code>"ok"</code> encrypted with AES-GCM. From that point, every message in both directions is AES-256-GCM encrypted with a per-direction sequence counter as authenticated associated data — preventing replay and reordering.After the handshake, the bot registers with the campaign ID provisioned by the dropper. The server returns a <code>bot_id</code> and <code>bot_pass</code> that the bot stores in the registry for subsequent polling. The bot's primary capability is arbitrary Python code execution — the attacker can ship any Python code and the bot will run it and return the output.All identified C2 and staging servers are compromised <a href="https://qloapps.com/">QloApps</a> hotel reservation websites:<table class="table"><thead><tr><th>Domain</th><th>Role</th><th>IP</th><th>PHP</th><th>Location</th></tr></thead><tbody><tr><td><code>parkspringshotel[.]com</code></td><td>C2 panel</td><td>172.96.172[.]91</td><td>8.3.30</td><td>Ghana</td></tr><tr><td><code>auraguest[.]lk</code></td><td>C2 panel</td><td>209.133.215[.]178</td><td>8.3.30</td><td>Sri Lanka</td></tr><tr><td><code>checkinnhotels[.]com</code></td><td>Linux payload staging</td><td>66.29.137[.]25</td><td>7.4.33</td><td>—</td></tr></tbody></table>The two C2 servers share identical JARM fingerprints and run the same PHP version, confirming the same C2 panel software is deployed on both. The third domain, <code>checkinnhotels[.]com</code>, was used to host the Linux payload disguised as an SVG file (<a href="https://www.bleepingcomputer.com/news/security/jdownloader-site-hacked-to-replace-installers-with-python-rat-malware/">BleepingComputer</a>). All three run QloApps — an open-source hotel booking CMS — suggesting the attacker specifically targets this software to build their infrastructure. None of the domains had malicious detections on VirusTotal at the time of discovery. We confirmed both C2 servers remain operationally live as of May 11.<h2>&nbsp;</h2><h2>The r77 rootkit stager</h2>The rootkit stager is a 176 KB native x86 PE based on the open-source <a href="https://github.com/bytecode77/r77-rootkit">r77 rootkit</a>. It contains an embedded .NET assembly that performs four operations:<ol><li data-list-item-id="e9ca3772c2bd6052d86931268e23d036a">AMSI bypass — a PowerShell cradle patches <code>AmsiScanBuffer</code> in memory, disabling Windows' Antimalware Scan Interface before any script payload runs.</li><li data-list-item-id="e01c27cd4c721b2dabe18b819d05c84fe">Reflective DLL injection — injects the r77 hooking DLLs (32-bit and 64-bit variants) into <code>winlogon.exe</code>. These DLLs hook Windows API functions to hide any process, file, or registry key whose name starts with the <code>$77</code> prefix.</li><li data-list-item-id="e254d7da7ebd6dfd7d57f7c5f67760ba3">Registry persistence — stores the stager assembly as a binary blob in <code>HKLM\SOFTWARE\$77stager</code> and reloads it at every boot via .NET reflection.</li><li data-list-item-id="ef200c38559748bd535edaf6a0d5aa3d5">Service creation — installs a Windows service (<code>$77svc</code>) to ensure the rootkit survives reboots independently of the registry mechanism.</li></ol>Once r77 is active, the <code>$77</code> prefix acts as an invisibility cloak. The Python bot calls <code>r77_hide_self()</code> and <code>r77_hide_registry_path()</code> to rename its own process and registry hive with this prefix, making them invisible to Task Manager, <code>regedit</code>, and most security tools.<h2>&nbsp;</h2><h2>The Python bot under PyArmor v9</h2>The final payload is a Python script protected by <a href="https://pyarmor.dashingsoft.com/">PyArmor</a> v9, a commercial bytecode obfuscation tool. PyArmor encrypts each function's bytecode individually and decrypts it at runtime through a native DLL — making static analysis significantly harder than standard Python malware.We built a custom tool to decrypt and disassemble the protected bytecode, recovering 30 functions totaling 7,326 lines of disassembly. The bot is cross-platform (Windows and Linux), uses gevent for asynchronous I/O, and handles the full lifecycle: configuration management, C2 discovery via dead-drop resolvers and DGA, encrypted communication, task execution, and rootkit integration.The bot's primary capability is executing arbitrary Python code received from the C2 server. Combined with the Python 3.14 runtime installed by the dropper, this gives the operator the ability to deploy any follow-on payload — keyloggers, credential stealers, lateral movement tools — without needing to push new binaries to the victim.<h2>&nbsp;</h2><h2>Impact and recommendations</h2>Users who downloaded JDownloader from the official website between May 6 and May 7, 2026, using the "Download Alternative Installer" links (Windows) or the Linux shell installer link are potentially compromised. The <a href="https://jdownloader.org/incident_8.5.2026.html">official incident report</a> lists eight malicious installer hashes across x86/amd64 and multiple JRE versions. The attackers exploited an unpatched CMS vulnerability to swap download links — the actual installer files hosted externally were never modified. In-app updates, macOS downloads, and package manager installs (Flatpak, Winget, Snap) were not affected.The Linux attack chain, [first reported by BleepingComputer](https://www.bleepingcomputer.com/news/security/jdownloader-site-hacked-to-replace-installers-with-python-rat-malware/), follows a different delivery path. We downloaded the trojanized shell installer and its payload to verify the claims and dig deeper.d. The modified install4j script requires root, checks for x86_64 architecture, and downloads a 20 MB tar.gz from <code>checkinnhotels[.]com/img/logo1.svg</code> (disguised with <code>Content-Type: image/svg+xml</code> — still live as of May 11). The archive contains two files: a 3 KB SUID-root helper (<code>systemd-exec</code>) and a 21 MB PyInstaller bundle (<code>pkg</code>). The helper is a minimal ELF that calls <code>setuid(0)</code>, <code>setgid(0)</code>, and <code>execvp()</code> — installed to <code>/usr/bin/systemd-exec</code> with <code>chmod 4755</code>. Persistence is created via <code>/etc/profile.d/systemd.sh</code>, which launches the payload masquerading as <code>/usr/libexec/upowerd</code>.We decrypted the PyArmor-protected Python bytecode from the Linux payload and confirmed it is the same bot source code as the Windows variant — identical RSA public key, DGA seeds, RC4 keys, C2 protocol, and DDR handler logic. The same campaign ID (<code>NdcHsJPM</code>) and all six DDR URLs are written to <code>~/.local/share/</code> as RC4-encrypted files (mirroring the Windows registry approach). The only difference is the Python runtime: the Linux bundle uses Python 3.12 (packaged via PyInstaller) versus Python 3.14 on Windows.The JDownloader developers restored clean downloads on May 9 and published a detailed incident timeline. Users who already had JDownloader installed and received updates through the application's built-in updater were not affected — only fresh downloads from the website during the compromise window were trojanized.If you ran the trojanized installer:<ul><li data-list-item-id="e78c8637f87f47adb2a6c0e9e37ff1466">The WDAC policy may have disabled your antivirus. Check <code>%WINDIR%\System32\CodeIntegrity\SIPolicy.p7b</code> — if it exists and you didn't create it, delete it and reboot.</li><li data-list-item-id="e5a9344602452a9e77dfe81e30c45fd8c">The registry keys <code>HKCU\SOFTWARE\Python</code> (bot config) and <code>HKLM\SOFTWARE\$77stager</code> (rootkit) are strong indicators of compromise — but if r77 is active, its API hooks hide all <code>$77</code>-prefixed registry keys and the bot's own hive from standard tools like <code>regedit</code>. To inspect these, boot from a Windows recovery environment or mount the registry hives offline.</li><li data-list-item-id="edcbc2f271c7b2885893f8f995fe252eb">A clean OS reinstall is the safest remediation. The r77 rootkit's reflective injection into <code>winlogon.exe</code> and AMSI bypass make partial cleanup unreliable.</li></ul>For defenders:<ul><li data-list-item-id="efcd7ce434d65f159da0dbff097d5fb44">The bot uses the default Python User-Agent <code>Python-urllib/3.14</code>. While not unique on its own, it can help correlate connections to the C2 URLs and DDR pages listed below.</li><li data-list-item-id="e35fe4757c01a79131defbd71e6762bfb">Monitor for DNS queries to the DGA pattern: 15-character lowercase alphanumeric hostnames on TLDs including <code>.top</code>, <code>.cfd</code>, <code>.sbs</code>, <code>.cyou</code>, <code>.icu</code>, <code>.casa</code>.</li><li data-list-item-id="e41ab2df0dd210b9e338012701bdf4398">The mutex name <code>Global\0C3C1D37</code> can serve as a host-based indicator.</li><li data-list-item-id="e68e99d7961368cd02568989f8e767d08">Block the dead-drop resolver pages: <code>telegra[.]ph/tr02-05-02</code>, <code>telegra[.]ph/ki06-05-02</code>, <code>rentry[.]co/zzk7opdu</code>, <code>rentry[.]org/wayc2qqz</code>.</li></ul><h2>&nbsp;</h2><h2>Indicators of Compromise</h2>Full IOC list available on <a href="https://github.com/avast/ioc">GitHub</a>.<h3>Hashes (SHA-256)</h3><table class="table"><thead><tr><th>Artifact</th><th>Hash</th></tr></thead><tbody><tr><td>Stage 1 — Windows (analyzed variant)</td><td><code>5a6636ce490789d7f26aaa86e50bd65c7330f8e6a7c32418740c1d009fb12ef3</code></td></tr><tr><td>Stage 1 — Linux shell installer</td><td><code>6d975c05ef7a164707fa359284a31bfe0b1681fe0319819cb9e2c4eec2a1a8af</code></td></tr><tr><td>Stage 2 (C++ dropper)</td><td><code>77a60b5c443f011dc67ace877f5b2ad7773501f3d82481db7f4a5238cf895f80</code></td></tr><tr><td>Stage 3 — Windows (PyArmor bot)</td><td><code>5fdbee7aa7ba6a5026855a35a9fe075967341017d3cb932e736a12dd00ed590a</code></td></tr><tr><td>PyArmor runtime DLL</td><td><code>33318499489cdb82543c0bfea699b98f5928c7a360966df6e958a9cbc2eab3fe</code></td></tr><tr><td>r77 rootkit stager</td><td><code>5c887054cb1dce077943afa955db43306f66795f7cbda8233d8ba25230a23d41</code></td></tr><tr><td>WDAC CI policy</td><td><code>5ee86c177dc5bdba05e3bdc67b07115c66097f825fff257bf0d4a999bbb8a1ea</code></td></tr><tr><td>Linux payload archive (logo1.svg)</td><td><code>6550672cac21e036882921dd934ee06552dc74d3b0a9e1ddc26f952855e11371</code></td></tr><tr><td>Linux SUID helper (systemd-exec)</td><td><code>25744e90bfa44cbcbf1f3d3c3cb90dd79dd32a6e359df9d2660ff251d6d03b46</code></td></tr><tr><td>Linux PyInstaller bot (pkg)</td><td><code>bf47585bd0b39f0731f044b37a95eb7e311ad31b23b50306a113a3aa777dbfab</code></td></tr></tbody></table>Six additional Windows installer variants are listed in the <a href="https://jdownloader.org/incident_8.5.2026.html">official incident report</a>. Full hash list on <a href="https://github.com/avast/ioc/tree/master/JDownloaderRAT">GitHub</a>.<h3>Network indicators</h3><table class="table"><thead><tr><th>Type</th><th>Value</th><th>Context</th></tr></thead><tbody><tr><td>C2 URL</td><td><code>parkspringshotel[.]com/m/Lu6aeloo.php</code></td><td>Active C2</td></tr><tr><td>C2 URL</td><td><code>auraguest[.]lk/m/douV2quu.php</code></td><td>Active C2</td></tr><tr><td>Staging</td><td><code>checkinnhotels[.]com/img/logo1.svg</code></td><td>Linux payload (still live)</td></tr><tr><td>C2 IP</td><td><code>172.96.172[.]91</code></td><td>parkspringshotel.com</td></tr><tr><td>C2 IP</td><td><code>209.133.215[.]178</code></td><td>auraguest[.]lk</td></tr><tr><td>Staging IP</td><td><code>66.29.137[.]25</code></td><td>checkinnhotels.com</td></tr><tr><td>Dead-drop resolver</td><td><code>telegra[.]ph/tr02-05-02</code></td><td>Live, serves encrypted C2 list</td></tr><tr><td>Dead-drop resolver</td><td><code>rentry[.]co/zzk7opdu</code></td><td>Live, serves encrypted C2 list</td></tr><tr><td>Dead-drop resolver</td><td><code>telegra[.]ph/ki06-05-02</code></td><td>Stub, reserved for C2 rotation</td></tr><tr><td>Dead-drop resolver</td><td><code>rentry[.]org/wayc2qqz</code></td><td>Stub, reserved for C2 rotation</td></tr></tbody></table><h3>Host indicators</h3><table class="table"><thead><tr><th>Type</th><th>Value</th></tr></thead><tbody><tr><td>Mutex</td><td><code>Global\0C3C1D37</code></td></tr><tr><td>Registry (bot config)</td><td><code>HKCU\SOFTWARE\Python\*</code> (hex-encoded RC4-encrypted value names)</td></tr><tr><td>Registry (r77)</td><td><code>HKLM\SOFTWARE\$77stager</code>, <code>$77dll32</code>, <code>$77dll64</code>, <code>$77svc</code></td></tr><tr><td>WDAC policy</td><td><code>%WINDIR%\System32\CodeIntegrity\SIPolicy.p7b</code> (GUID <code>{31351756-3F24-4963-8380-4E7602335AAE}</code>)</td></tr><tr><td>Bot process</td><td><code>pythonw.exe</code> (Python 3.14, User-Agent <code>Python-urllib/3.14</code>)</td></tr><tr><td>Tor drop path</td><td><code>C:\ProgramData\tor\tor\tor.exe</code></td></tr><tr><td>Linux SUID binary</td><td><code>/usr/bin/systemd-exec</code></td></tr><tr><td>Linux payload</td><td><code>/root/.local/share/.pkg</code></td></tr><tr><td>Linux persistence</td><td><code>/etc/profile.d/systemd.sh</code></td></tr><tr><td>Linux masquerade</td><td><code>/usr/libexec/upowerd</code></td></tr></tbody></table><h3>MITRE ATT&amp;CK</h3><table class="table"><thead><tr><th>Technique</th><th>ID</th></tr></thead><tbody><tr><td>Supply Chain Compromise: Compromise Software Supply Chain</td><td>T1195.002</td></tr><tr><td>Obfuscated Files or Information</td><td>T1027</td></tr><tr><td>Impair Defenses: Disable or Modify Tools</td><td>T1562.001</td></tr><tr><td>Process Injection: Dynamic-link Library Injection</td><td>T1055.001</td></tr><tr><td>Web Service: Dead Drop Resolver</td><td>T1102.001</td></tr><tr><td>Dynamic Resolution: Domain Generation Algorithms</td><td>T1568.002</td></tr><tr><td>Encrypted Channel: Asymmetric Cryptography</td><td>T1573.002</td></tr><tr><td>Rootkit</td><td>T1014</td></tr><tr><td>Create or Modify System Process: Windows Service</td><td>T1543.003</td></tr><tr><td>Modify Registry</td><td>T1112</td></tr></tbody></table>For customers using Norton, Avast, AVG, Avira or any other security product, the most important question is whether the malicious installer was executed. If you downloaded an affected installer but did not run it, delete the file, download a fresh installer from the official JDownloader site, and run a full scan with up-to-date protection. If you ran the installer, or cannot rule out that you ran it, treat the system as compromised. JDownloader recommends a clean operating system reinstall in this situation, and we agree that this is the safest baseline. The Windows payload includes rootkit behavior, persistence, encrypted configuration and policy-based defense evasion, so a normal scan may reduce risk but cannot guarantee that every persistence mechanism has been removed. Until the system has been rebuilt or inspected from a trusted recovery environment, avoid using it for sensitive activity. Do not log in to email, banking, work accounts, password managers or other important services from that machine. Change important passwords from another trusted device, and monitor accounts for unusual activity.&nbsp;

Malware that hid itself on infected systems and disabled antivirus protection.

Inside the JDownloader Supply-Chain Attack: An r77 Rootkit Bot That Kills Your Antivirus

TLDR: Bedep was a malware family active mainly in 2014 and 2015 that used an unusually sophisticated domain generation algorithm, or DGA, to hide its command-and-control infrastructure. Instead of relying only on the date, it used real foreign exchange rates published by the European Central Bank, making its future domains much harder to predict in advance. Under the hood, the malware used ideas from group theory to generate a fixed set of unique domains without collisions, a rare example of advanced mathematics being applied directly in real-world malware.Most domain generation algorithms are boring. A linear congruential generator, a date seed, some modular arithmetic, a character table -- <code>seed = (seed * 0x41C64E6D + 0x3039) % 2^31</code>, rinse, repeat. You reverse them in an afternoon, pre-compute next month's domains over lunch, and move on.Bedep author implemented a number theory textbook inside a 32-bit DLL, and the result is one of the most mathematically elegant pieces of malware ever shipped.This post is a deep dive into this unique engineering.<h2>What is Bedep?</h2>Bedep is an ad-fraud botnet that was active from late 2014 through 2015, delivered exclusively through the Angler exploit kit. When a Flash zero-day (CVE-2015-0311) was burning, Angler was dropping Bedep. The malware itself was a modular downloader focused on click fraud, but its infrastructure is what made it interesting. In early 2015, new variants appeared with a DGA for C2 resolution. A three-day sinkhole by Arbor Networks (ASERT) caught phone-homes from roughly 82,000 unique IPs, spread across every continent except -- notably -- Russia.Dennis Schwarz originally reversed the DGA at ASERT, who published a proof-of-concept Python reimplementation and a detailed write-up titled "Bedep's DGA: Trading Foreign Exchange for Malware Domains." The original blog post has since been taken down from NETSCOUT's site, but survives on the <a href="https://web.archive.org/web/20160311083109/http://www.arbornetworks.com:80/blog/asert/bedeps-dga-trading-foreign-exchange-for-malware-domains/">Wayback Machine</a>. The PoC lived at <code>github.com/arbor/bedep_dga</code>. Dennis got the algorithm working but noted that parts of it were opaque -- he called the core transform a "blackbox" and flagged the embedded table as "likely something Fermat number related." He was right. Let's open that box.&nbsp;<h2>The ECB trick: Seeding a DGA from the financial markets</h2>Before the math starts, Bedep needs a seed that both the bot and the botmaster can independently derive without communicating. Most DGAs use the date. Bedep uses the date and the global foreign exchange market.The algorithm fetches two XML files from legitimate public services:<ol><li data-list-item-id="ec5890edf5187711796f804fae7ad8577">UTC time from <code>earthtools.org/timezone/0/0</code> -- the current timestamp, converted to "days since year zero."</li><li data-list-item-id="ead6313dc967de96442575ff50339b412">Euro foreign exchange reference rates from <code>www.ecb.europa.eu/stats/eurofxref/eurofxref-hist-90d.xml</code> -- the European Central Bank's daily publication of EUR conversion rates against 31+ world currencies, updated every business day.</li></ol>The time is used to select which day's rates to use. Specifically, Bedep picks "last Tuesday's" exchange rates -- meaning the preceding week's Tuesday until Thursday, after which it rolls forward to the current week's Tuesday. Only rates falling on a Monday boundary (in the algorithm's day-counting scheme) are considered. This gives a roughly weekly rotation with a deterministic selection rule.From the chosen date, Bedep extracts up to 48 currency rates -- USD, JPY, GBP, CZK, BGN, HUF, and so on. Each rate is parsed through a slightly broken custom <code>atof()</code> implementation (off by a bit in the least significant digits -- a quirk, not a feature), packed into a 64-bit IEEE double, and its low 32-bit dword is extracted for use in the algorithm.Here is what a single run looks like, from the PoC output for April 7, 2015:<code>parsed 31 currencies from 2015-04-07 (currency date): &nbsp; &nbsp;USD: 1.0847 &nbsp; &nbsp; &nbsp;JPY: 130.33 &nbsp; &nbsp; BGN: 1.9558 &nbsp; &nbsp;CZK: 27.455 &nbsp; &nbsp; &nbsp;DKK: 7.4714 &nbsp; &nbsp;GBP: 0.7286 &nbsp; &nbsp;HUF: 299.08 &nbsp; &nbsp; &nbsp;PLN: 4.0578 &nbsp; &nbsp;RON: 4.4165 &nbsp; &nbsp;SEK: 9.374 &nbsp; &nbsp; &nbsp; CHF: 1.0438 &nbsp; &nbsp;NOK: 8.73 &nbsp; &nbsp;HRK: 7.619 &nbsp; &nbsp; &nbsp; RUB: 59.8265 &nbsp; TRY: 2.8079 &nbsp; &nbsp;AUD: 1.4192 &nbsp; &nbsp; &nbsp;BRL: 3.3979 &nbsp; &nbsp;CAD: 1.3563 &nbsp; &nbsp;CNY: 6.7241 &nbsp; &nbsp; &nbsp;HKD: 8.4086 &nbsp; &nbsp;IDR: 14091.77 &nbsp; &nbsp;ILS: 4.267 &nbsp; &nbsp; &nbsp; INR: 67.598 &nbsp; &nbsp;KRW: 1183.28 &nbsp; &nbsp;MXN: 16.1919 &nbsp; &nbsp; MYR: 3.9527 &nbsp; &nbsp;NZD: 1.4423 &nbsp; &nbsp;PHP: 48.3 &nbsp; &nbsp; &nbsp; &nbsp;SGD: 1.4724 &nbsp; &nbsp;THB: 35.335 &nbsp; &nbsp;ZAR: 12.8345</code>&nbsp;

Why is this clever? Because the ECB rates are:<ul><li data-list-item-id="e5f3c952abb440c715bcfa626ac9bd4c0">Publicly available -- anyone can fetch the same XML</li><li data-list-item-id="e7730a0d72c71be00a0c3d3feebc10618">Globally consistent -- every bot on every continent gets the same data</li><li data-list-item-id="e1667d4c4edd48ffbda05118e24153bf0">Unpredictable in advance -- nobody can predict next Tuesday's EUR/USD rate</li><li data-list-item-id="e80b9125dab13aae37cb9ed8b88656475">Historically verifiable -- the ECB publishes archives going back years</li><li data-list-item-id="e0d9bf0abba3c6cb7703705ce6203f707">Impossible to tamper with -- the ECB is not going to modify their reference rates to help you sinkhole a botnet</li></ul>And because the malware fetches this from <code>ecb.europa.eu</code>, the request looks like legitimate traffic. A Snort signature (SID 33188) was written to detect it, but it fired constantly on real users checking exchange rates.<h2>The mathematical core</h2>This is where Bedep stops being a clever botnet and starts being a discrete mathematics exercise.<h3>Precomputed subgroup parameters</h3>The DLL embeds a lookup table -- 102 entries of 8 dwords each, stored as JSON in the PoC (<code>transform2_table_varN.json</code>, one per config variant). At first glance it looks like random constants. It is not.The <code>transform2</code> function takes a hash derived from the exchange rates and days-since value, then uses it as an index into this table. Each table entry, after being decoded through config-specific XOR and multiply constants (<code>0x663d81 * entry[0] ^ value3</code> and <code>0x281 * entry[1] ^ value2</code>), yields two critical values:<ul><li data-list-item-id="ee4084ac1a9ee922a9a2585119d02acb9">p -- a prime number</li><li data-list-item-id="e7d298adce011a8fe31f7d5db7f1685ee">q -- an integer such that q divides p - 1</li></ul>This is the subgroup structure. The table stores primes whose group orders (p - 1) have known factorizations with small prime factors. The malware doesn't need to factor p - 1 at runtime -- that hard work was done offline by the author and baked into the DLL. Dennis Schwarz noted these were "likely something Fermat number related," and he was onto something: the primes are chosen so that their totient has a smooth factorization, making generator-finding tractable.The number of domains to generate comes directly from q - 1. For the first config, this works out to 22 domains; for the second, 28 -- totaling 50 domains per weekly rotation.<h3>Finding generators: A textbook primitive root search</h3>With p and the prime factorization of p - 1 in hand, Bedep needs a generator of the multiplicative group ((\mathbb{Z}/p\mathbb{Z})^*) -- or more precisely, of a specific subgroup of order q.The <code>transform8</code> function does this in two stages. First, it runs a trial-division prime sieve: starting from 3, stepping by 2 (skipping evens), it tests each candidate against all previously found primes. It collects up to 37 small primes, then filters for those that actually divide q (the subgroup order). This gives the prime factorization of q.Then <code>transform3</code> finds the primitive root itself. This is the standard algorithm straight from a number theory textbook:<code>def find_primitive_root(p, prime_factors_of_order): &nbsp; &nbsp;for g in range(2, p // 2): &nbsp; &nbsp; &nbsp; &nbsp;is_generator = True &nbsp; &nbsp; &nbsp; &nbsp;for q_i in prime_factors_of_order: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# If g^((p-1)/q_i) ≡ 1 (mod p), then g generates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# a proper subgroup, not the full group. Reject it. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if pow(g, (p - 1) // q_i, p) == 1: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;is_generator = False &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;break &nbsp; &nbsp; &nbsp; &nbsp;if is_generator: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return g &nbsp; &nbsp;return None</code>

The actual code in <code>transform3</code> is this logic rendered in C-style loop structure with manual index tracking, but the mathematics is identical. For each candidate g starting from 2, it checks:[ g^{(p-1)/q_i} \not\equiv 1 \pmod{p} \quad \text{for all prime factors } q_i \text{ of } p-1 ]If g passes all checks, it generates the full group. This is literally the algorithm from Section 11.1 of Shoup's A Computational Introduction to Number Theory and Algebra, implemented in a malware DLL.<h3>Walking the cyclic group</h3>Now comes the payoff. With a prime p, a generator g, and a subgroup order q, the <code>transform7</code> function sets up the DGA's iteration state:<code>modulus &nbsp; &nbsp;= p &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# field_c seed &nbsp; &nbsp; &nbsp; = pow(g, random_e, p) &nbsp; &nbsp; &nbsp; &nbsp;# field_4 -- starting element step &nbsp; &nbsp; &nbsp; = pow(g2, random_f, q) &nbsp; &nbsp; &nbsp; # field_8 -- step exponent</code>

The starting position <code>seed</code> is g raised to a random exponent (derived from <code>rdtsc</code>, the CPU timestamp counter). The step is similarly randomized from a second generator. Both are computed via modular exponentiation.Then, for each domain, the iteration is simply:<code>seed = pow(seed, step, modulus) &nbsp; &nbsp; # one step through the cyclic group domain = seed_to_domain(seed, currencies)</code>

That single line -- <code>pow(seed, step, modulus)</code> -- is the entire DGA engine. Each call advances the state to the next element of the cyclic subgroup.Because the subgroup has order q, and step is coprime to q (guaranteed by the generator construction), this walk visits every non-identity element of the subgroup exactly once before cycling. The number of domains generated equals q - 1, which is precisely the number of non-identity elements. No collisions. No wasted iterations. No off-by-one hoping you hit enough domains.The key insight: the set of group elements visited is deterministic (fixed by p, g, and the exchange rates), but the order of visitation depends on the random exponents from <code>rdtsc</code>. Every infected machine walks through the same set of q - 1 elements, generating the same q - 1 domain names, but potentially in a different order. Same destinations, different paths.<code>flowchart TB &nbsp; &nbsp;subgraph cyclic_group ["Cyclic Subgroup of (Z/pZ)*"] &nbsp; &nbsp; &nbsp; &nbsp;E1["g^1 mod p"] --&gt; E2["g^2 mod p"] &nbsp; &nbsp; &nbsp; &nbsp;E2 --&gt; E3["g^3 mod p"] &nbsp; &nbsp; &nbsp; &nbsp;E3 --&gt; E4["..."] &nbsp; &nbsp; &nbsp; &nbsp;E4 --&gt; Eq["g^(q-1) mod p"] &nbsp; &nbsp; &nbsp; &nbsp;Eq --&gt; E1 &nbsp; &nbsp;end &nbsp; &nbsp;subgraph walk ["DGA Walk (order depends on rdtsc)"] &nbsp; &nbsp; &nbsp; &nbsp;S1["seed_0"] --&gt;|"pow(s, step, p)"| S2["seed_1"] &nbsp; &nbsp; &nbsp; &nbsp;S2 --&gt;|"pow(s, step, p)"| S3["seed_2"] &nbsp; &nbsp; &nbsp; &nbsp;S3 --&gt;|"pow(s, step, p)"| S4["..."] &nbsp; &nbsp; &nbsp; &nbsp;S4 --&gt;|"pow(s, step, p)"| SN["seed_(q-2)"] &nbsp; &nbsp;end &nbsp; &nbsp;S1 -.-&gt;|"= g^e mod p\n(random start)"| cyclic_group &nbsp; &nbsp;S2 -.-&gt;|maps to| E3 &nbsp; &nbsp;S3 -.-&gt;|maps to| Eq</code>

<h2>From Group Elements to Domain Names</h2>Each group element is a 32-bit integer. Turning it into a domain name is the final step, handled by <code>transform11</code>. This is less mathematically elegant and more of a traditional mixing function, but it has a nice property: every character position in the domain uses a different currency rate.The algorithm cycles through the full list of parsed currencies (31 in the example above). For a domain of length 18, that means character 0 is influenced by USD, character 1 by HRK, character 2 by MXN, character 3 by GBP, and so on. Each character is computed by:<ol><li data-list-item-id="e1b4d60fdb8fc1f153baf8a99855a0b35">Multiplying the currency's 3-letter name (packed as a 32-bit int) and its 64-bit floating-point rate by large constants</li><li data-list-item-id="ec05b47f97cd63ed0295b790fd5474c85">XORing and shifting the result with the current seed and the days-since value</li><li data-list-item-id="e2f1e2c5d769b5e8978ca12f1d05cf791">Taking the result modulo 26 (for positions 2+) or modulo 36 (for the last two positions, allowing digits)</li><li data-list-item-id="e589b38ae5aa632fba755388fc26bd71c">Adding the ASCII offset for 'a'</li></ol>The domain length itself is derived from the seed XORed with a rate-dependent value, bounded between 12 and 18 characters. All domains use the <code>.com</code> TLD.A trace from the PoC output shows the mixing in action:<code>seed: 0xa13c9652 &nbsp; &nbsp;mixing in USD's rate &nbsp; &nbsp;mixing in HRK's rate &nbsp; &nbsp;mixing in MXN's rate &nbsp; &nbsp;mixing in GBP's rate &nbsp; &nbsp;... &nbsp; &nbsp;mixing in ZAR's rate &nbsp; &nbsp;domain: rrpohktjlscncqxvt3.com seed: 0x558af439 &nbsp; &nbsp;mixing in USD's rate &nbsp; &nbsp;... &nbsp; &nbsp;domain: wjavcjhazzxyxotkbi.com</code>

Each domain is a fingerprint of the entire exchange rate vector, filtered through one specific element of the cyclic group.<h2>The Full Pipeline</h2>Putting it all together:<code>flowchart LR &nbsp; &nbsp;ECB["ECB XML\n31+ currency rates"] --&gt; DateSelect["Select last\nTuesday's rates"] &nbsp; &nbsp;Earth["earthtools.org\nUTC timestamp"] --&gt; DateSelect &nbsp; &nbsp;DateSelect --&gt; Mix["XOR/multiply\nrates + days_since"] &nbsp; &nbsp;Mix --&gt; TableLookup["Lookup table\n→ prime p, order q"] &nbsp; &nbsp;TableLookup --&gt; GenFind["Sieve primes,\nfind generator g"] &nbsp; &nbsp;GenFind --&gt; GroupSetup["seed = g^rand mod p\nstep = g2^rand mod q"] &nbsp; &nbsp;GroupSetup --&gt; Walk["Iterate:\nseed = seed^step mod p"] &nbsp; &nbsp;Walk --&gt; CharMix["Mix seed with\ncurrency rates"] &nbsp; &nbsp;CharMix --&gt; Domains["22-28 domains\nper config"]</code>

Seven configs were observed in the wild, each with its own embedded table, XOR constants, and currency count (36 or 48). Each malware variant embedded two configs that ran per rotation -- the first generating 22 domains, the second 28, yielding 50 domains total. Across the observed campaign, domains were registered 2-5 days ahead of use through "Domain Context" registrar with Regway nameservers, all resolving to infrastructure at 5.196.181.244 and 46.105.251.1.<h2>Why this matters</h2>Compare Bedep's approach with its contemporaries:<table class="table"><thead><tr><th>Family</th><th>DGA Technique</th><th>Seed</th></tr></thead><tbody><tr><td>Conficker.C</td><td>Date + simple arithmetic</td><td>Current date</td></tr><tr><td>Gamaredon</td><td>Nested character-range loops</td><td>Hardcoded ranges</td></tr><tr><td>Necurs</td><td>CRC32 hash of date components</td><td>Date + constant</td></tr><tr><td>Matsnu</td><td>Dictionary word concatenation</td><td>Days since epoch</td></tr><tr><td>Bedep</td><td>Cyclic group walk mod p</td><td>ECB exchange rates</td></tr></tbody></table>Every other DGA on this list can be pre-computed arbitrarily far into the future. Bedep cannot -- because Tuesday's exchange rates don't exist until Tuesday. You can sinkhole Conficker's domains for next year during your coffee break. For Bedep, you have to wait for the ECB to publish, then race the botmaster to register the domains.The mathematical guarantee is real: the cyclic group structure ensures exactly q - 1 distinct domains per rotation with no collisions and no wasted iterations. The primitive root construction ensures the generator produces every element. The precomputed tables avoid expensive factorization at runtime. The exchange rate seed provides unpredictable entropy from a trusted, globally-consistent, publicly-verifiable source.This is not someone who copy-pasted a DGA from a forum. The author understood multiplicative groups modulo primes, knew how to find primitive roots, precomputed smooth-order primes offline, and wired the whole thing to the European Central Bank's daily publications. Whether they learned this from a university course, a textbook, or a cryptography library's source code, the result is unmistakable: this is applied algebra, deployed in production, at scale.The original ASERT analysis is preserved on the <a href="https://web.archive.org/web/20160311083109/http://www.arbornetworks.com:80/blog/asert/bedeps-dga-trading-foreign-exchange-for-malware-domains/">Wayback Machine</a>. The proof-of-concept implementation was published on <a href="https://github.com/arbor/bedep_dga">ASERT's GitHub</a>. The sample analyzed here is <code>e5e72baff4fab6ea6a1fcac467dc4351</code> (MD5) /&nbsp;<code>d0fb1b66b6e4da395892327be9f39adb4533e7759ace39f67bdde0bb1cdaef35</code> (SHA256).&nbsp;Credits: The DGA was originally reversed by Dennis Schwarz at Arbor Networks / ASERT. This post builds on his work, focusing on the mathematical structure he identified but didn't fully unpack.

A closer look at how Bedep used foreign exchange data and advanced math to generate hard-to-predict domains, making its command-and-control infrastructure more difficult for defenders to block and disrupt

When Malware Authors Study Algebra: The Group Theory Inside Bedep's DGA

A VM-obfuscated backdoor observed on a single machine in the UK, operated for one year, and vanished without a trace. 

Chasing an Angry Spark

Staff Scientist, AI

The deepfake story you think you know is incomplete.&nbsp;When most people hear “deepfake,” they picture a fake face.&nbsp;One important nuance: a deepfake face does not automatically mean a scam, and a scam does not even require a deepfake face at all. Visuals can be a useful clue, but identifying synthetic media is getting more complex, and simplistic “looks fake” judgments are increasingly unreliable. That is why we lean on multiple signals, including audio analysis and transcript, to reason about intent and behavior.&nbsp;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;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;As we continued our research on what makes a deepfake a scam, we started asking another question that changed what we looked for:&nbsp;Once a video is already labeled as scam content by our audio and content analysis, which faces keep showing up across those scam videos?&nbsp;The answer was not only “famous people.”&nbsp;It was actually a set of VIPs that do not exist.&nbsp;<h2>Why we looked for “VIPs” in scam video&nbsp;</h2>In scam ecosystems, repetition is rarely an accident. Criminals optimize what works, then scale it.&nbsp;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;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 signal 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;We expected the usual outcome: a list dominated by high-profile public figures that scammers frequently impersonate.&nbsp;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;But the most important finding was what appeared alongside the celebrity targets.&nbsp;<h2>VIPs that don’t exist&nbsp;</h2>Some of the most prevalent “presenters” in scam video are not real people.&nbsp;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;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;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;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;This matters because it changes the threat model.&nbsp;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;That might sound like a minor distinction, but it changes the incentives.&nbsp;<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>In short, these “VIPs” are not famous because they are recognized, they are VIPs because they are operational assets in scam production.&nbsp;<h2>From celebrity deepfakes to avatar farm&nbsp;</h2>Celebrity impersonation is still here, and it will remain attractive. Reputation is a powerful shortcut to trust.&nbsp;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;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;This is why the “avatar farms” mental model fits.&nbsp;Instead of crafting a one-off forgery, scammers can run a production line:&nbsp;<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>That production line scales. It is designed for experimentation, iteration, and reach.&nbsp;And it works because most scams do not require cinematic realism. They require momentum.&nbsp;<h2>Synthetic trust, the new social engineering&nbsp;</h2>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;That is the core idea behind synthetic trust.&nbsp;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;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;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;<h2>The twist: sometimes the video is real and only the audio is weaponized&nbsp;</h2>There is another reason audio-first detection matters: not every scam video relies on a fake face.&nbsp;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;This technique does two things for scammers:&nbsp;<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>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;<h2>A note on hired actors&nbsp;</h2>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;In other words: the “avatar farm” trend does not replace all old techniques. It sits alongside them.&nbsp;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;<h2>Practical tips: how to protect yourself from scam videos&nbsp;</h2>If a video is pushing you toward money, logins, downloads, or urgent verification, treat the presenter as part of the packaging, not proof.&nbsp;<ol type="1"><li data-list-item-id="eb375588bdd69b963a569da0423a5860d">Follow the action, not the face.&nbsp; 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">Verify outside the platform.&nbsp; Search for the claim from independent sources, not links in the description or comments.&nbsp;</li><li data-list-item-id="ea8e5ddb75021374558a5553272959836">Be suspicious of “too smooth” certainty.&nbsp; Scam scripts often sound confident, generic, and strangely frictionless, as if risk does not exist.&nbsp;</li><li data-list-item-id="ee5e84990c119d747dd4cb8566a61b415">Watch for mismatch.&nbsp; 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">Avoid installs prompted by videos.&nbsp; “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">Use protection tools. 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>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;Which means the real skill is not spotting what looks fake; it is recognizing how scams behave.&nbsp;Follow the pressure. Question the promise. Verify outside the moment.&nbsp;

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

From Celebrity Deepfakes to Avatar Farms, How Scammers Industrialize Trust

It starts with a message that does not feel wrong.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.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.And that is exactly why it works.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.That is the pattern at the heart of what we are calling the <a href="https://us.norton.com/blog/online-scams/reservation-hijacking-scam" target="_blank">Reservation Hijack Scam</a>.We call it a Reservation Hijack Scam 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;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.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.<h2>A scam category built on stolen and relayed trust</h2>Most phishing is generic. It arrives with no context, so your brain treats it with suspicion.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.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.This is not just a nicer phishing template. It is a different quality of deception.

<h2>What we found</h2>Our investigation points to two visible fronts in the same scam pattern.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.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.

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.The second is the hotel software abuse path, 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.That shift matters.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.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.

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

At its core, this scam follows a simple pattern, even if the entry point can vary.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.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.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.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.

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.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.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:

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.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.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.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.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.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.<h2>The Cloudbeds path, step by step</h2>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.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.The attack chain we mapped is brutally efficient.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.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.

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.<h2>One scam, multiple surfaces</h2>This is the part many people miss.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.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.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.<h2>Why this matters now</h2>Hospitality has become an unusually attractive environment for this kind of fraud.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.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.<h2>What travelers should do</h2>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;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.If you already entered payment details, assume compromise. Contact your bank, cancel the card, enable transaction alerts and watch for follow-on attempts.<h2>What hotels should learn from this</h2>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.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.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.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.<h2>One final thought</h2>For years, the best advice on travel scams was simple: watch for bad grammar, generic messages, and suspicious links.That advice still matters. But it belongs to an earlier phase of the problem.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.That is the Reservation Hijack Scam.&nbsp;In the next part of this series, we will look more closely at the infrastructure, indicators and investigative signals behind it.

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

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.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 Torg Grabber.<h4>The mystery of the misclassification</h4>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.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.<h4>The evolution of a criminal business</h4>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.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.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.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.

<h4>The "ClickFix" trap: how they get in</h4>Torg Grabber does not just break into your house: it tricks you into opening the door. Our team observed a clever tactic called "ClickFix."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.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.

<h4>The digital master key</h4>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.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.<h4>A massive appetite for your data</h4>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:<ul type="disc"><li data-list-item-id="eee754b80a606370a3c6e23613c76bf58">Your Financial Life: 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">Your Security Tools: 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">Your Privacy: 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">Your Identity: 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>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.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.<h4>Why technical dissection matters</h4>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.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.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.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.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>

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

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.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.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.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.<h2>How scammers hide in plain sight</h2><h3>Multi-facet ads, hiding one scam among legitimate links</h3>One of the most common techniques we uncovered is what we call multi-facet advertisements.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.The trick is simple: make the scam look like part of a normal shopping experience.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.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.

<h3>URL masking, when the ad shows one domain and sends users to another</h3>This is one of the most effective deception techniques we observed.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.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.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.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.

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

<h3>Typosquatting, deceptive subdomains, and misleading previews</h3>Why abandon a tactic that still works?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.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.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.This combination, deceptive domain naming plus misleading visuals, increases both click-through potential and evasion resilience.An example of an advertisement using the prefix “go.”. The link “GO.DATING4SINGLES.COM” does not lead to the website, but “DATING4SINGLES.COM” does.

<h3>Unicode text obfuscation that breaks detection, not readability</h3>Sometimes the URL is not the main problem, the text is.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.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.The result is elegant from the scammer’s perspective, readable to people, unreliable for machines.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.

<h3>Hidden impersonation, names that look real to people but not to machines</h3>Impersonation remains one of the fastest ways to manufacture trust in scam advertising.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.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.This technique was especially common in scam ads designed to manufacture credibility through famous names, credentials, or authority signals.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.

<h2>Why scam ads keep coming back</h2>The problem is not only that scam ads evade detection. It is that they regenerate faster than enforcement can disrupt the operation behind them.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.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.What we observed suggests a recurring pattern, many interventions remove individual ad instances, while the broader scam operation remains fully capable of regeneration.<h3>Takedowns that remove ads, but not the operation</h3>One of the first patterns we noticed was that removals often appeared to happen on a single ad instance basis.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.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.For scammers, this is a gift. If enforcement targets copies one by one, duplication becomes a business advantage.<h3>Short-lived campaigns, high volume beats persistence</h3>Scammers do not need every ad to survive. They need enough ads to run long enough.A common pattern we observed was the use of many short-lived advertisements, 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.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.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.Permanence is not the business model, throughput is.<h3>User reporting is too slow for disposable scam ads</h3>We also tested the user reporting path directly by reporting scam ads from platform accounts.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.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.At this scale, platform moderation faces a difficult asymmetry. Scammers can generate and rotate ads faster than manual review can reasonably keep up.<h3>Advertisers accounts are cheap to replace</h3>Another structural issue is the ease of creating or replacing advertiser accounts.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.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.That is the Hydra problem in practical terms, remove one head, and the infrastructure behind it keeps producing more.<h3>Scam ads are engineered for resilience</h3>Scam advertising is not static. It is adaptive, distributed, and engineered for resilience.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.Reactive takedowns matter, but they are not enough when enforcement is slower than replication.Meaningful progress requires systemic changes, stronger advertiser verification, better destination-level transparency, campaign-level enforcement, and faster cross-platform disruption mechanisms.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.

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

The Scam Ad Machine: Part II

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.In a recent investigation, this approach produced a complete, publishable, evidence-backed analysis about 30 times faster than a traditional workflow, without skipping verification.We’re building this as a repeatable capability across investigations, not an ad hoc trick.&nbsp;Introducing ‘Agentic Threat Hunting’Attackers scale by default. They automate, iterate and copy what works until defenders are forced into a permanent reaction cycle.Defenders don’t lose because they lack intelligence or tools. Defenders lose because time is finite.Threat hunting is not a single breakthrough moment. It’s a chain of steps and the chain breaks where time and attention run out.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.That bottleneck is changing.Not because AI “does the research,” but because agentic workflows compress time. 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.That is what we mean by Agentic Threat Hunting.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.<h3>The problem we are solving: time is the limiting factor</h3>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.Even the best researchers lose days to work that is necessary but doesn’t deserve senior attention:<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>The cost is not just speed. When time gets tight, risk increases. Steps get shortened, context gets lost and important connections can be missed.This is the gap Agentic Threat Hunting is designed to close.<h3>What changes: parallel work, one accountable owner</h3>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.Instead of one person doing everything serially, agents can take on defined roles that mirror how a small team works:<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>The senior researcher becomes the director, the reviewer and the owner of every conclusion. The work scales, but accountability does not move.<h3>What stays the same: credibility, traceability and ownership of claims</h3>If we only talk about speed, this turns into hype.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:Agents can accelerate work, but researchers own the claims.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.This is how you get the upside of speed without sacrificing trustworthiness.<h3>How it works in practice: two examples</h3>Example 1: Variant wrangling without losing rigorMalware rarely arrives as a single, well-defined specimen. It arrives as a stream of variants, each with small changes that matter.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.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.Example 2: From raw technical detail to outputs people can actually useEven when the analysis is correct, a lot of time disappears translating it into something others can act on.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).The human still owns the narrative, edits for accuracy and decides what is publishable, but translation stops being the limiting factor.<h3>The engine behind it: playbooks, prompts and roles that work like a team</h3>The difference between “we tried AI” and “we are building Agentic Threat Hunting” is discipline.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.Then we operationalize that into agent roles, so the work is repeatable instead of reinventing every time.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.<h3>Why it matters: faster investigations mean better protection</h3>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.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.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.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.In other words, AI compresses time, but it does not compress responsibility. That stays human.

An Army for Every Analyst

Engineering the Future of Agentic Threat Hunting 

We leverage the strength of our global team, knowing we’re more powerful together. Read news about Gen's company activities and initiatives.

Company News

Gen has a family of trusted consumer brands that for decades have helped people stay safe in the digital world. We pride ourselves in the trust we’ve built with people around the world to navigate the latest technology safely and with confidence. And that’s exactly why we recently launched the Gen Agent Trust Hub – our trust layer for the agentic AI ecosystem.AI agents are no longer theoretical. They are here. They are editing files, installing packages, calling APIs, connecting to MCP servers, spawning sub-agents, persisting memory, and executing real workflows across environments. This shift from passive AI to autonomous execution fundamentally expands the attack surface.The Agent Trust Hub (ATH) exists to meet this moment. It is designed to provide continuous protection across the full lifecycle of an AI agent – from identity and verification to runtime enforcement. But security at this scale cannot rely on proprietary guardrails alone. It requires shared foundations the industry can build on.To help establish that foundation, we created the AI Agent Safety Standards by Gen to serve as a unified framework designed to bring consistency, portability, and accountability to agentic systems. This framework is currently built on two complementary pillars:<ul type="disc"><li data-list-item-id="e464ce0354d35c1a986c83945bc06b0cd">AI Agent Runtime Safety Standard (AARTS) – an open standard for runtime decision enforcement across agent hosts</li><li data-list-item-id="e4a7d4ceb7039019b7c2554401a8bb1c3">Skill IDs – a deterministic, content-addressable fingerprinting system for AI agent skills</li></ul>Together, they enable the ATH and the broader agentic AI community to enforce trust not just within one environment but across the broader agentic ecosystem. &nbsp;Let’s dig into the details.&nbsp;<h2>Pillar One: Standardizing Runtime Safety for AI Agents</h2><h3>AARTS</h3>AI agents operate across a fragmented ecosystem of IDEs, orchestrators, frameworks, and standalone applications. Each host defines its own lifecycle events, security hooks, and enforcement logic.This fragmentation creates blind spots. A security engine integrated into one host may lack context or control in another, even when the risks are identical.AARTS&nbsp;addresses this gap. It is not a product. It is a vendor-neutral contract that defines:<ul type="disc"><li data-list-item-id="e226fc797549b56b0ae0a537923fd79f6">Where security decisions can be made (hook points)</li><li data-list-item-id="e7566ceb595a0278da9453bbd84659578">What data is available for evaluation (data model)</li><li data-list-item-id="e637f36bcc4e8dcfac7321ad59230c1c1">How decisions are enforced (verdict semantics)</li></ul>Simply put:&nbsp; AARTS standardizes runtime security decision-making across agent hosts.<h3>The Architecture</h3>AARTS defines three cleanly separated roles:<ol><li data-list-item-id="e7a445b9a896b9b89299afa17ca58c69e">Host Runs the agent, emits lifecycle events, and enforces decisions.</li><li data-list-item-id="e989b722cd161ff069c924d70571cd6b7">Adapter Maps host-native events into a standardized AARTS schema.</li><li data-list-item-id="ed862f4398b4b82c3b52c721801728a9c">Security Engine Evaluates events and returns structured verdicts.</li></ol>This separation prevents superficial “checkbox security” while preserving portability. Hosts provide the right context at the right time. Engines make decisions without depending on host internals.In ATH, this architecture allows enforcement logic to remain portable while enabling hosts to integrate in a predictable way.<h3>Hook Points: Where Safety Happens</h3>AARTS v0.1 defines 19 hook points across the agent lifecycle, including:<ul type="disc"><li data-list-item-id="ec5255705352d810833f77d79b310a42d">PreToolUse — evaluate shell commands, file writes, web requests, package installs</li><li data-list-item-id="ee1ebbdf3e4522a59dedaa55c0305d903">PreLLMRequest — protect prompt integrity and instruction layering</li><li data-list-item-id="e10ef155bfe4c584afd7492da267796be">PreSkillLoad / PrePluginLoad — enforce supply chain controls</li><li data-list-item-id="ee6184f1048dfbf4ee3c0e62c2d3dff16">PreMCPConnect — treat MCP connections as trust boundaries</li><li data-list-item-id="ebc57267bf0e891e01f9daf277ced1a01">PreMemoryRead / PreMemoryWrite — protect persistent memory</li></ul>These hooks enable consistent policy enforcement regardless of whether an agent runs in an IDE, CLI, or orchestrator.Verdict Semantics: Allow, Deny, AskAARTS engines return structured verdicts:<ul type="disc"><li class="ck-list-marker-bold" data-list-item-id="e9615d2d55e251652e73363c052de0bd1">Allow</li><li class="ck-list-marker-bold" data-list-item-id="eb510a0ee27b0a853b90ff01cec91953d">Deny</li><li class="ck-list-marker-bold" data-list-item-id="ed6e8c58ce99af62dddbf6b530bc0c83c">Ask</li></ul>Each verdict includes severity, threat category, optional confidence scoring, and human-readable reasoning.Importantly, AARTS enforces deterministic behavior:<ul type="disc"><li data-list-item-id="edfce7cb3a277e1da6e442c971f8cc8e1">If a host cannot support interactive “Ask,” it defaults safely to Deny</li><li data-list-item-id="ec790330b39c695d6cdacf4118e106c1b">If an engine fails, hosts fail-open and log explicitly</li></ul>These operational tradeoffs are intentional. Predictability is essential in security infrastructure.<h3>Why AARTS Matters</h3>Without a shared runtime contract:<ul type="disc"><li data-list-item-id="e2574817ec2bfc1a1b0233c5fca970994">Security integrations are bespoke and brittle</li><li data-list-item-id="ebbe5c354debe741cc08436719a34032e">Tool taxonomy is inconsistent</li><li data-list-item-id="e2f498a30e5d748e37c3176b169145707">Prompt injection controls vary by host</li><li data-list-item-id="e3aff5387909fd85f523c40998fdb13b0">Supply chain risk is unevenly enforced</li></ul>With AARTS:<ul type="disc"><li data-list-item-id="eaa8f402b20b740f0992dd0f9b4f42b44">One engine can operate across multiple hosts</li><li data-list-item-id="e3ddcda4fa65f1abd066be4b0bef0201b">Policies remain portable</li><li data-list-item-id="e5ec3076209374ae5eafb39a00f19adf4">Audit logs become comparable</li><li data-list-item-id="e6f17fa0cc0a6a6e0136b63569cdc58a6">Trust boundaries are explicit</li></ul>AARTS standardizes enforcement in the agentic world.To read the full technical breakdown, see the full AART&nbsp;<a href="https://www.gendigital.com/blog/news/company-news/ai-agent-runtime-security">technical blog post</a>. To comment on the standards, visit our page on&nbsp;<a href="https://github.com/gendigitalinc/aarts">GitHub</a>.<h2>Pillar Two: Skill IDs</h2><h3>Fingerprinting AI Agent Skills</h3>AI agents are extended through skills – directory bundles containing a SKILL.md prompt file alongside scripts, templates, configuration, and documentation.These skills function like plugins. Install one, and the agent gains new capabilities.But skills are not single files. They are directory trees.And directory trees are notoriously difficult to fingerprint reliably.<h3>The Identity Problem</h3>A naive SHA-256 hash of a ZIP file does not work:<ul type="disc"><li data-list-item-id="e6fc83ba16d130bd7d3d62ba2af79f96d">ZIP files are non-deterministic</li><li data-list-item-id="ee7939e0ca570cb480cbdc5b8e5460ece">Timestamps vary</li><li data-list-item-id="e5d398fbba0c41d53d0e3782902bce4c1">Entry order differs</li><li data-list-item-id="e95611c8e95e6ad4f16eccdede99ac42c">Unicode normalization differs across OS platforms</li><li data-list-item-id="ef8771bdef58d5438cc192edc36e89c56">Wrapper directory names vary</li></ul>Two identical skills can produce different ZIP hashes.That is unacceptable for security workflows.<h3>Designing the Skill ID</h3>Skill IDs solve this problem by creating a deterministic, content-addressable identifier for a skill’s logical directory tree.The algorithm:<ol><li data-list-item-id="ebdc8f7c1fc531f4ccbd79f2baf7b6d83">Extract all files and directories</li><li data-list-item-id="e06cf4d178c29a57575a249d22d5cb9b4">Normalize paths (slashes, Unicode NFC, dot components)</li><li data-list-item-id="e69f139d48a1c91815267ffb649c74e07">Strip wrapper directories</li><li data-list-item-id="e07c1da87b4b07a634d73a79ab93f9134">Hash each file individually (SHA-256)</li><li data-list-item-id="ef7cb735107df0cafdbcc921e639c0212">Build sorted tree entries using null-byte delimiters</li><li data-list-item-id="eab8b3782aab3b4dd9b0f4aed3255caf8">Hash the tree to produce the final Skill ID</li></ol>The result is a 64-character SHA-256 digest that changes if and only if meaningful content changes.Same content, different ZIP packaging? Same ID. One byte changed? Different ID.This mirrors git’s tree hashing model and decades of security best practices.<h3>What Skill IDs Enable</h3>A stable identity primitive unlocks established security workflows:Allowlisting Approved skills can bypass repeated analysis.Content-addressable storage Deduplicate identical submissions automatically.Per-file caching Reuse expensive AI analysis on unchanged files.Detection flagging Connect file hashes to reputation systems.Version tracking Content becomes the version boundary.Skill IDs provide identity before verdict.<h3>From Identity to Authenticity: Signing Skills</h3>Identity answers “what is this?”Authenticity answers “who published this?”We are exploring a signing model inspired by Authenticode:<ul type="disc"><li data-list-item-id="e2103c63753a0f24a87fa144d75611c7a">A skill.sig file embedded inside the directory</li><li data-list-item-id="e28e6643465e0cabeea54eb4bc5302028">Excluded from the Skill ID calculation</li><li data-list-item-id="e700fd96bf7f3d0db4aa70df0a92d57ec">Contains a signature over the Skill ID</li><li data-list-item-id="ea2483e766cae2defa9d2dd19707d9302">Verifiable against the author’s public key</li></ul>This enables:<ul type="disc"><li data-list-item-id="eddf73c0b79d7d482c030736b4f449be8">Author signing</li><li data-list-item-id="e3d708097518f6e38a31a73aaf27ecb49">Marketplace attestation</li><li data-list-item-id="e81ca5157252eece76405ff632c0d6722">Certificate chains</li><li data-list-item-id="efe336aa9f477f99f141fc5a81f887d9b">Revocation workflows</li></ul>Self-verifiable skills create accountability without external lookups.To read the full technical breakdown, see the full <a href="https://www.gendigital.com/blog/insights/research/ai-agent-skill-fingerprinting" target="_blank" rel="noreferrer noopener">SkillsID technical blog post</a>. To comment on the standards, visit our page on <a href="https://github.com/gendigitalinc/skill-id-standard">GitHub</a>.&nbsp;<h2>The AI Agent Safety Standards by Gen: Identity + Enforcement</h2>AARTS governs runtime enforcement. Skill IDs govern artifact identity.Together, they form the foundation of the AI Agent Safety Standards.<ul type="disc"><li data-list-item-id="ea3ef208939f34e4fcfaf98bd8e26b2d6">Skills can be uniquely identified, versioned, and signed.</li><li data-list-item-id="e30dceebd279e7a291dc71a82c7168ab2">Runtime actions can be evaluated consistently across hosts.</li><li data-list-item-id="e1a7b0d4259c4abb5e6ba2f38dffd6aaa">Supply chain trust and runtime enforcement operate under shared semantics.</li></ul>This is the same model that matured endpoint security over decades:<ul type="disc"><li data-list-item-id="ebacb70fb4a6565c103650a6c6ee67532">File hashes</li><li data-list-item-id="ed254dd1eec0c62e2aea6bce82e871995">Content signatures</li><li data-list-item-id="e37a3133a17b4a1adca017b868990baa6">Runtime enforcement</li><li data-list-item-id="eeeb5f5d7a84badb31f60600269d24edf">Portable policy engines</li></ul>We are applying those proven patterns to a new artifact type and a new execution model.<h2>Looking Ahead</h2>These standards are early. AARTS v0.1 is a draft. Skill ID signing is an evolving proposal. Adapter conformance testing, enterprise fail-open profiles, and cross-marketplace reputation sharing remain active areas of collaboration.But the direction is clear.AI agents are moving from experimentation to infrastructure. Security must do the same.The Gen Agent Trust Hub is our contribution to building a predictable, interoperable trust layer for the agentic ecosystem.&nbsp;We invite host builders, marketplace operators, enterprise security teams, and fellow security vendors to review, adopt, and challenge.Because in the agentic era, safety cannot be bespoke. It must be foundational.&nbsp;

Shaping the standards for a safer, freer Agentic Era 

Leading the Way for AI Agent Safety 

Director of Threat Research & Applied AI

We built a security engine that protects AI agents across several major platforms. The hardest part wasn't building the protection. It was discovering that each platform exposes different security-relevant events, provides different context about what the agent is doing and why, and enforces security decisions differently. The same agent action we can catch and block in one platform is invisible in another, not because our detection failed, but because the platform never told us it happened. There are now over a dozen agent platforms, from IDE assistants like Claude Code, Cursor, and GitHub Copilot, to agentic frameworks like LangChain, CrewAI, and OpenAI Agents SDK, to orchestrators like n8n, and each one handles this differently, if at all.Today, Gen is releasing AI Agent Runtime Safety Standard (AARTS) as part of its Agent Trust Hub initiative, which aimsto address this fragmentation. This is not a security product, but rather a set of vendor-neutral standards that connects agent hosts (IDEs, orchestrators, frameworks, standalone agent apps), security engines (components that evaluate agent actions), and adapters (thin mappings that translate host-native events into a common schema). For those building or operating agents, AARTS enables portable, consistent security decisions across hosts, eliminating the need to rebuild security integrations from scratch.&nbsp;The standard is open and vendor-neutral, and any host or security vendor can implement or contribute to it.<h2 class="text-align-justify">The Problem AARTS Addresses</h2>Agentic systems fail in ways that are familiar but occur more rapidly and with greater reach. Examples include sequences evolving from helpful actions to dangerous activities like&nbsp;"download and execute," prompt injection steering tool use, supply chain issues affecting skills and plugins, sensitive data exposure by agents, and permission confusion resulting from sub-agents and external tool providers creating additional trust boundaries. Although these risks are not new, they now manifest within a rapidly diversifying set of hosts and tool APIs.Without a shared contract, security becomes a collection of one-off integrations, each missing context and offering inconsistent enforcement. This leads either to weak coverage, due to incomplete integrations and context, or to overly blunt blocking when trust is undermined by limited interpretation. AARTS targets the root cause: the lack of shared semantics and hook points.In our previous&nbsp;<a href="https://www.gendigital.com/blog/news/company-news/ai-agent-detection-and-response" target="_blank">post on Agent Detection and Response</a>, we described how attackers register AI-hallucinated package names on npm and PyPI, preloaded with infostealers. Catching that requires seeing the package install action with enough context — the package name, the source, whether the agent hallucinated it or the user requested it. One platform gives us all of that. Another gives us the command string with no structured metadata. A third doesn't emit the event at all. Same attack, three different levels of visibility.Simply put, AARTS standardizes where security decisions can be made (hook points), what data is available for decision-making (data model), and how decisions are enforced (verdict semantics), ensuring consistent protections across different agent hosts.<h2 class="text-align-justify">Architecture and Roles</h2>AARTS defines three distinct roles:<ul type="disc"><li data-list-item-id="ef43f78807d68ed5d7cafc41e43ed6a77">Host: The environment that runs the agent. The host emits lifecycle events at defined hook points and enforces decisions.</li><li data-list-item-id="ea8ecfedda9151e1e4ff45954fc0bd003">Adapter: A minimal translation layer that maps host-specific events into AARTS events, normalizing tool names, lifecycle phases, and context.</li><li data-list-item-id="ec84e412023baa1359b60a4c189c0ce73">Security Engine: The evaluator that receives AARTS events, applies detection strategies, and returns structured verdicts.</li></ul>This separation matters. Embedding security logic in hosts results in superficial security ("checkbox security"), while engines depending on host internals compromise portability. AARTS keeps the boundary clean: hosts provide the right moments and context, and engines make decisions. AARTS also supports various integration models (in-process, subprocess, remote), accommodating different latency, isolation, and operational requirements.<h2 class="text-align-justify">How the Standard Works</h2>AARTS defines hook points, moments in an agent's lifecycle where a security engine can intercept, evaluate, and act. Version 0.1 specifies 19 of them across session management, prompt lifecycle, tool execution, plugin and skill loading, sub-agent behavior, memory operations, and output delivery.Not all hooks carry equal weight. Three illustrate the design logic:<ul type="disc"><li data-list-item-id="e9e499b9374a4cd1f71378518f359c0d6">PreToolUse is the primary checkpoint. Before an agent runs a shell command, writes a file, makes a network request, or installs a package, the security engine sees the action, its arguments, and the context that led to it, then returns a verdict: allow, deny, or ask the user. This is where most real-world threats get caught.</li><li data-list-item-id="ebd37c3ab71aca6ef9cddd1080d793f75">PreLLMRequest operates earlier in the loop, before the prompt reaches the model. It lets engines inspect prompt integrity: whether safety instructions survived context compaction, whether untrusted content was injected into the conversation, whether the instruction layering is intact. If PreToolUse is the checkpoint at the door, PreLLMRequest watches for problems before the agent even decides what to do.</li><li data-list-item-id="ecce291342cb701e4290928d827faf930">PreSkillLoad addresses supply chain risk. When an agent installs a plugin or skill from a marketplace, the engine can evaluate the trust source (where it came from, whether it's signed, whether it was modified) before it gets loaded. AARTS can also direct the host to strip hooks from skills, preventing plugins from disabling the security layer that's supposed to govern them.</li></ul>The remaining 16 hooks follow the same pattern: they sit at the moment where risk becomes real and provide the engine with enough context to make a decision.For those decisions to be portable across hosts, the inputs have to be consistent. AARTS standardizes the event structure: every event carries a mandatory envelope (hook point, session ID, timestamp, host identity) plus standard extensions, reusable field groups for conversation context, tool details, trust source metadata, modification tracking, and provenance. A canonical tool taxonomy maps host-specific tool names (Cursor's "terminal" vs. Claude Code's "bash") to common categories (shell, file_write, web_request, package_install), so detection logic written once works everywhere.Verdicts are structured: a decision (allow, deny, or ask), a threat category, a severity level, confidence, and a human-readable explanation for the user. Two design choices are worth noting. If the host can't prompt the user, ask falls back to deny, safe but a real constraint for headless orchestrators. If the engine crashes or times out, the host treats it as allow and logs the failure. Fail-open is the right default for developer tools where latency matters, but enterprise deployments will want to revisit this per environment.<h2 class="text-align-justify">Conformance Levels: Gradual Adoption</h2>AARTS defines three conformance levels:<ul type="disc"><li data-list-item-id="e18c7418214ef4f97b683f20402deb227">Level 1 (Basic): Requires SessionStart and PreToolUse hooks, minimum tool coverage (shell, file_write, web_request), enforcement of allow and deny (ask may be treated as deny).</li><li data-list-item-id="e0369d9837c299bdfd5a5c490fb899318">Level 2 (Standard): Adds plugin and skill load hooks, prompt lifecycle protection, broader tool coverage, additional hooks (PrePluginLoad, PreSkillLoad, PostInputProcessing, PreLLMRequest, PostToolUse), and requires provenance on PreToolUse.</li><li data-list-item-id="e31f70f735daa583aec2ef8c2d180686d">Level 3 (Comprehensive): Provides full lifecycle coverage including user input, prompt response cycle, tool modification, sub-agents, MCP connect, memory read/write, output delivery, and session end. Clarifies sub-agent inheritance and memory protection.</li></ul>This tiered approach offers a realistic adoption path: Level 1 addresses basic failures, Level 2 tackles prompt integrity and supply chain issues, and Level 3 supports persistent and autonomous agents.<h2 class="text-align-justify">Open&nbsp;Considerations</h2>As we move AARTS beyond a draft specification,&nbsp;the following are being considered:<ul type="disc"><li data-list-item-id="ef56e3529222a5671c75f8e80fbc5c2c9">Enterprise fail-open story: The spec mandates fail-open behavior. Deployment profiles may be needed to reflect the realities of different environments.</li><li data-list-item-id="e5e2beee0ceee16ba315173c83dcc4596">Adapter integrity: Ensuring adapters correctly map tool types and extract artifacts is vital. A conformance test suite for adapters is as important as the specification itself is a next-step priority.</li><li data-list-item-id="eea2912c8ee60ab64a8339e4d3c2b5748">Consent for privacy: Explicit consent is required for external transmission of prompts and tool data. Operational guidance or recommended patterns are needed to avoid incompatible implementations.</li><li data-list-item-id="e7dbd49139e599330dbad43c59209bc82">Ask semantics in headless environments: Treating ask as deny by default is safe but may discourage engines from using ask. A standard way for deployment policy to handle ask in these scenarios is needed.</li></ul>AARTS aims to translate&nbsp;these considerations into predictable operational behavior.<h2 class="text-align-justify">Call for Feedback</h2>AARTS v0.1 is a draft intended for early review by host builders, security vendors, and enterprise operators.&nbsp;The full specification is available <a href="https://github.com/gendigitalinc/aarts" target="_blank">here</a>. If you build agent hosts, consider whether you want every security integration to remain one-off. If you develop security engines, ask yourself whether you want to rewrite the same logic for each host and still miss critical context. AARTS aims to make the answer “no”.&nbsp;We welcome contributions — open an issue or submit a pull request.

AARTS standardizes how AI agent platforms expose security events, enabling portable runtime protection across the growing agent ecosystem

Introducing AARTS: An Open Standard for AI Agent Runtime Safety

You gave an AI agent access to your computer. Maybe it's writing code for you, managing your emails, or handling your finances. It's working with your credentials, acting on your behalf, and making decisions you used to make yourself. Fast, confidently, and largely unsupervised. That's the deal: you trade safety and oversight for productivity. That changes the security model.But who's watching what it actually does?That is why we built the Gen Agent Trust Hub (ATH), our trust layer for the agentic AI ecosystem, designed to secure agents across their lifecycle from skill to runtime to enforcement.Agent Detection and Response (ADR) is the runtime pillar — the layer that governs what agents actually do.<h2 class="text-align-justify">What is ADR?</h2>ADR intercepts agent actions at the moment of execution, before they land, and evaluates whether they're safe. It allows, asks the user, or denies. That's the core.Verification tells you what an agent is. ADR tells you what it's doing. These are complementary. Verification is necessary, but it can't govern what happens at runtime. A verified skill can still hallucinate a malicious package name. A signed plugin can still be exploited through prompt injection. A trusted agent can still lose its safety instructions mid-session and go off the rails. The moment of action is where risk becomes real.The principle isn't new. Every major computing paradigm has developed its own detection and response layer. Endpoints got EDR. Distributed infrastructure got XDR. Not replacements for what came before, but purpose-built layers for new execution surfaces with new threat models. AI agents are the next such surface, and ADR is the layer built for it.Within the Agent Trust Hub, ADR is the enforcement engine that turns trust signals into real-world protection.<h2>Why Now?</h2>The threats targeting AI agents are already here. What follows is a small sample of the agentic threats we’re seeing. The actual attack surface spans everything an agent can do, and agents can do a lot.Your agent installs malware for you. AI agents hallucinate. When they hallucinate a package name during installation, that's not just an error, it's an opportunity. Attackers monitor AI-suggested package names and register them on npm and PyPI, pre-loaded with infostealers and backdoors. The technique is called slopsquatting, and it's already being exploited at scale. In February 2026, researchers uncovered a campaign of&nbsp;<a href="https://www.securityweek.com/new-sandworm_mode-supply-chain-attack-hits-npm/">19 typosquatted packages specifically</a> targeting users of AI coding tools, designed to exfiltrate SSH keys, AWS credentials, and API tokens.Your agent ignores your instructions. Summer Yue, Meta's Director of Alignment, told her OpenClaw agent to&nbsp;<a href="https://techcrunch.com/2026/02/23/a-meta-ai-security-researcher-said-an-openclaw-agent-ran-amok-on-her-inbox/">confirm before taking any action</a> on her email. It worked, until the session ran long enough to trigger context compaction, a mechanism where the agent compresses its memory to keep running. The safety instructions were among the first things dropped. The agent deleted 847 emails. She had to physically run to her machine to stop it.Your agent is a new delivery channel for malware. Attackers are already using multiple paths to get malicious code running through agents. Weaponized skills on public marketplaces have delivered the&nbsp;<a href="https://x.com/GenThreatLabs/status/2018323584834318419">AMOS infostealer to macOS users</a>. Malicious project configurations have achieved&nbsp;<a href="https://research.checkpoint.com/2026/rce-and-api-token-exfiltration-through-claude-code-project-files-cve-2025-59536/">remote code execution in Claude Code</a> the moment a developer opens a repository. Prompt injection through fetched content can turn a trusted agent into an attacker's proxy. The delivery mechanisms vary. The result is the same: your agent executes something it shouldn't, and it does so with your permissions.These are just three examples. The pattern is consistent: agents operate with real authority, and that authority is being exploited. Through supply chains, through the agent's own fragility, and through the same malware ecosystem that has targeted every other computing platform before them.<h2>Where ADR Must Operate</h2>To be effective, ADR must sit as close to the agent's execution loop as possible. Not as an external service watching from the outside. Inside, where the actions happen.Agent sessions contain source code, credentials, business logic, and personal data. ADR evaluates locally, on the device. No prompts, tool inputs, or code leave your machine for analysis.Agents are not robust systems. Their own internal mechanisms can silently drop safety instructions or get poisoned across sessions. A security layer that only sees inputs and outputs misses the moment things go wrong inside. ADR watches the execution loop itself: every action the agent attempts, in context, in sequence.Only a client-side layer sees the complete picture: the prompt history, what files were already modified, the sequence of prior actions. A remote service sees isolated events. ADR sees the session. That difference is what makes it possible to distinguish a legitimate file deletion from a compromised agent cleaning up its tracks.<h2>Sage: ADR in Practice</h2>In February, we&nbsp;<a href="https://www.gendigital.com/blog/news/company-news/sage-ai-agent-security">open-sourced Sage</a> as the first implementation of ADR. It runs client-side, directly inside the agent's execution loop, across Claude Code, Cursor, and OpenClaw. Over 200 detection rules cover supply chain attacks, credential exposure, dangerous commands, persistence mechanisms, and more, backed by Gen's threat intelligence.Since launch,&nbsp;<a href="https://github.com/avast/sage/">Sage</a> has quickly crossed 1,000 installs and is available across the major agentic tool marketplaces. The open-source community is already contributing, porting Sage to new platforms like OpenCode and hardening detection rules. As one independent security researcher concluded after&nbsp;<a href="https://www.linkedin.com/pulse/paranoid-sage-testing-security-tool-agents-radek-hendrych-capff/">testing Sage</a>: "Real-time monitoring and management of AI agents based on deterministic measures is, in my view, the right way to go."All these responses confirm what we suspected: people want this layer.<h2>What's Next</h2>ADR is the runtime layer. But runtime protection alone isn't enough.&nbsp;The Agent Trust Hub is built on the idea that trust in the agentic era must be layered: verification before installation, ecosystem trust signals across marketplaces, and enforcement at execution. ADR closes the gap at the moment risk becomes real.&nbsp;The industry needs a common interface for how agents expose their actions to security tools. A shared standard, so that protection works consistently regardless of which agent you use or which platform you're on. We've been working on that too. More soon.

Inside the Gen Agent Trust Hub, ADR turns trust signals into real-world protection.

Gen Agent Trust Hub Introduces Agent Detection and Response: The Missing Security Layer for Agentic AI 

AI agents are starting to do the parts of computing that used to be “hands on keyboard”. They run terminal commands, edit files, install packages, and fetch things from the web, because that’s what it takes to get real work done. Tools like Claude Code, Cursor, and OpenClaw give these agents direct access to your machine and your sensitive information. That's what makes them useful. It's also what makes them risky. These agents make mistakes. They install packages that don't exist because they hallucinated the name. They pick up credentials and pass them where they shouldn't. They'll download and run programs from the internet without a second thought if the task seems to call for it. All of this happens fast, with confidence, and without asking. If you’ve watched an agent confidently suggest curl … | bash or “just add your API key here” into a file it shouldn’t touch, you’ve seen the problem.&nbsp;Agents are also targets. Malicious URLs, poisoned dependencies, and compromised plugins can turn an agent into an attack vector, one that already has access to your files, your terminal, and your network. This is already happening. <a href="https://x.com/GenThreatLabs/status/2018323584834318419" target="_blank" rel="noreferrer noopener">We recently identified</a> around 400 malicious skills on ClawHub, a public registry for agent extensions. At the time of discovery, they accounted for 12% of all available skills. These weren’t obviously shady throwaways; many were weaponized versions of legitimate skills, designed to trick agents into downloading malware.&nbsp;&nbsp;These are the same agents we're starting to trust with payments, infrastructure, and sensitive workflows. The gap between what agents can do and what keeps them in check is real, and it's growing.&nbsp;Today, Gen, the company behind Norton, Avast, LifeLock, and AVG, is releasing Sage to close that gap. With Sage, the Agent Trust Hub now evaluates and governs agent behavior during execution. Not just before installation. Not just at verification. But in the exact moment an action is about to happen.&nbsp;

<h2>What Sage does</h2>Think of Sage as a lightweight safety shield for AI agents. It sits inside the agent's workflow and checks every action before it happens: shell commands, URL fetches, file writes, package installs. For each action, Sage returns a verdict:&nbsp;<ul type="disc"><li data-list-item-id="e2aee30f293d4edf72390d310cdfa3f0e">Allow — no threat detected, the action proceeds&nbsp;</li><li data-list-item-id="e89d49ae9fae752dee97f089112c466b8">Ask — something looks suspicious, the user decides&nbsp;</li><li data-list-item-id="e44ca3f76876a9e666f2544e1233366ba">Deny — confirmed threat, the action is blocked&nbsp;</li></ul>The agent never notices unless something is wrong.&nbsp;Sage catches both sides of the risk. It protects agents from external threats like malicious URLs, compromised packages, and dangerous downloads. And it protects users from agents themselves, when they try to run destructive commands, expose credentials, or write to sensitive system files.&nbsp;Here's a concrete example. An agent automating a setup task decides to download and execute a script from the internet. No review, no confirmation. Sage recognizes the pattern and blocks it before anything runs.&nbsp;<h2 class="text-align-justify">Part of a larger commitment</h2>Sage is not a standalone effort. It’s part of a broader strategy to embed continuous trust into the AI skills ecosystem through the Gen Agent Trust Hub.&nbsp;&nbsp;The Skill Scanner of the <a href="https://ai.gendigital.com/agent-trust-hub" target="_blank" rel="noreferrer noopener">Gen Agent Trust Hub</a> helps determine whether an agent extension is trustworthy before it gets installed, using cloud-based verification and classification. Sage picks up where that leaves off. Once the agent is running, it enforces safety locally, on your machine, checking every action at the moment it's about to execute.&nbsp;&nbsp;Together, they cover the full lifecycle: from the decision to install something to the moment it actually runs. More capabilities are on the way as the agentic ecosystem grows.&nbsp;<h2 class="text-align-justify">Open source, on purpose</h2>The agentic platforms themselves are designed for open integration: open-source tools, community plugins, public hook APIs. A closed security layer would be harder to adopt in a space that moves fast and depends on community integrations.&nbsp;At the same time, there is no established playbook for how to secure AI agents. By open-sourcing Sage, we're proposing one and inviting the community to help define what safe agents should look like in practice.&nbsp;This first version is lightweight. It's not a full antivirus product as we know it, but it addresses the problems where they are. It covers the high-risk paths we think matter most: commands, file changes, URL fetches, and package installs, including catching hallucinated or malicious dependencies before they land on your machine. Sage ships with over 200 detection rules covering command injection, persistence, credential exposure, obfuscation, and supply-chain attacks.&nbsp;Sage currently supports Claude Code, Cursor, and OpenClaw, with more platforms on the way. If you find a detection that's too noisy or not strict enough, open an issue. If you want to add a rule, improve a check, or add support for another agent platform, send a pull request.&nbsp;We built Sage to be extended.&nbsp;&nbsp;<h2>Try it</h2>Learn more about Sage at <a href="https://ai.gendigital.com/sage" target="_blank" rel="noreferrer noopener">https://ai.gendigital.com/sage</a>. For technical details, documentation, and source code, visit the project on <a href="https://github.com/avast/sage" target="_blank" rel="noreferrer noopener">https://github.com/avast/sage.</a>&nbsp;If you use Claude Code, Cursor, or OpenClaw, install Sage and put it in the path of real work. The fastest way to improve a safety layer is to expose it to real commands, real repos, and real mistakes. That's what we're doing here — shipping early, in the open.&nbsp;

Closing the growing security gap between what Al agents can do and what keeps them in check

Introducing Sage: Safety for Agents 

AI agents aren’t just helpful in chats anymore. They’re actually taking action on your behalf. Autonomous AI can access data. They move from suggestion to execution without hesitation.&nbsp;This is what we call “mindless artificial intelligence.”&nbsp;When technology starts taking action on our behalf, trust has to be built into the system itself.&nbsp;That’s why Gen is partnering with Vercel to bring independent safety verification to the AI skills ecosystem at <a href="https://skills.sh/" target="_blank">skills.sh</a>, embedding trust directly into the skills layer.&nbsp;

<h2>Independent verification. Built in.&nbsp;</h2>Through this partnership, the Gen <a href="https://ai.gendigital.com/agent-trust-hub" target="_blank">Agent Trust Hub</a> will evaluate skills on skills.sh and assign clear, transparent classifications:&nbsp;🟢 Safe&nbsp; 🟡 Low Risk&nbsp; 🟠 High Risk&nbsp; 🔴 Critical Risk&nbsp;Behind those ratings is advanced risk modeling and threat intelligence from Gen Threat Labs, analyzing permissions, behaviors, vulnerabilities and potential malicious intent.&nbsp;The goal isn’t to slow innovation. It’s to help it scale responsibly. Developers should be able to build boldly. Users should be able to install confidently. And both deserve clarity.&nbsp;<h2>Security as infrastructure, not an afterthought&nbsp;</h2>By integrating verification directly into skills.sh, Gen and Vercel are making security part of the AI development lifecycle, not something bolted on after the fact.&nbsp;In the agentic world, skills are how things get done. Until now, developers and users had limited visibility into whether a skill was truly safe. Reputation and documentation can’t tell the whole story. As agents gain autonomy, guesswork isn’t good enough.&nbsp;The trust has to be visible.

<h2>Powering Digital Freedom in what comes next&nbsp;</h2>At Gen, we believe Digital Freedom means being able to embrace new technology without sacrificing safety or confidence. As AI evolves, our responsibility evolves with it.&nbsp;The future of AI will be powerful. And expansive. But, it must also be secure by design.&nbsp;This partnership is one more step toward building the trust foundation the agentic era demands, so innovation and confidence can grow together.&nbsp;

Bringing transparent risk ratings to the AI skills ecosystem to help developers build boldly and users move confidently

The trust layer for the agentic era 

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

Corporate Manager

Leadership Perspectives

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

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

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

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

“Is this a scam?” has become one of the defining questions of the digital era.&nbsp;What is changing is not just the volume of these messages. It is how people respond to them. Only now, instead of asking a friend this question, they’re turning to ChatGPT. This shift marks a profound inflection point in human technology interaction. AI is no longer just a productivity tool or a content assistant. It is becoming a decision layer. A reasoning partner. A first checkpoint before action.&nbsp;At Gen, we see this as more than a trend. It signals the emergence of a new trust architecture for the internet.&nbsp;<h2>AI is becoming the first line of defense&nbsp;</h2>According to the <a href="https://www.gendigital.com/blog/insights/reports/threat-report-q4-2025" target="_blank" rel="noreferrer noopener">Gen Threat Report</a>, more than 90 percent of threats targeting people in 2025 stemmed from scams, phishing and deceptive advertising. The dominant risk online today is not malware quietly infecting a system. It is manipulation persuading a person.&nbsp;In parallel, AI tools like ChatGPT are becoming deeply embedded in everyday workflows. People use them to draft emails, compare products, research decisions and increasingly to validate suspicious messages.&nbsp;That convergence creates both opportunity and responsibility. If AI is where decisions are being shaped, then security intelligence must live there too.&nbsp;<h2>From reactive security to decision-centric protection&nbsp;</h2>In the <a href="https://us.norton.com/blog/ai/how-to-spot-scams-before-you-click" target="_blank" rel="noreferrer noopener">Norton integration within ChatGPT</a>, AI evaluates patterns such as impersonation tactics, urgency cues, requests for sensitive information and domain anomalies. Norton Genie, the world’s first AI-powered scam detector, pairs technical signals with behavioral indicators because modern fraud operates on both layers.&nbsp;But this product moment sits within a much larger transformation.&nbsp;<h2>The rise of autonomous AI and the trust imperative&nbsp;</h2>Our <a href="https://www.gendigital.com/blog/insights/research/openclaw-autonomy-risks" target="_blank" rel="noreferrer noopener">OpenClaw</a> research on autonomy risks explores how AI agents with increasing independence can introduce new security challenges. When AI begins to act on our behalf, make decisions or initiate actions, trust can no longer be assumed. It must be engineered.&nbsp;Autonomy without guardrails amplifies risk. Autonomy with transparency amplifies trust.&nbsp;That is why Gen has introduced the <a href="https://ai.gendigital.com/" target="_blank" rel="noreferrer noopener">AI Agent Trust Hub</a>, a framework and resource center focused on building responsible AI ecosystems. The Trust Hub emphasizes governance, explainability, accountability and human oversight as core design principles. This is not theoretical. As AI agents begin handling financial transactions, personal data and operational workflows, they will inevitably become targets themselves. The next phase of cybersecurity will not only protect humans from malicious actors. It will protect AI systems from manipulation and misuse. And it will protect humans from over-reliance on AI without understanding its limitations.&nbsp;<h2>Designing AI that augments human judgment&nbsp;</h2>The future of AI interaction is not about replacing decision-making. It is about strengthening it.&nbsp;When someone pastes a suspicious message into ChatGPT and asks “Is this legit?” they are not outsourcing responsibility. They are seeking clarity. They are extending their cognitive reach.&nbsp;That balance between automation and empowerment is critical.&nbsp;AI must be capable enough to identify emerging global scam patterns, including fake delivery notifications, banking impersonation attempts and AI generated voice phishing. But it must also remain interpretable. Transparent. Accountable. The Norton app, within ChatGPT, can be that.&nbsp;&nbsp;<h2>Building the next trust layer of the internet&nbsp;</h2>We are entering an era where AI will mediate much of our online experience. It will draft our communications. Curate our information. Screen our interactions. Execute transactions. The question is not whether AI will become part of our security posture. It already is.&nbsp;The real question is whether we build it with trust at the core.&nbsp;At Gen, our approach is grounded in three ideas:&nbsp;<ul type="disc"><li data-list-item-id="e965bc2f74345432db64ab84b0e13580d">Innovation must move at the speed of AI growth.&nbsp;</li><li data-list-item-id="ea2d5c939c934043a266b4f4c41bf1f08">Security must integrate into the environments where decisions happen.&nbsp;</li><li data-list-item-id="ec0f44d4a8b7612a7b70893f9bbe16d34">Trust must scale alongside autonomy.&nbsp;</li></ul>The integration of AI-powered scam detection into conversational platforms is one step in a broader journey. It reflects a belief that protection should not sit on the sidelines. It should sit inside the interaction.&nbsp;“Is this a scam?” may have been a common question in 2025. But tomorrow the more important question will be: Can we trust the AI systems helping us answer it?&nbsp;The future of cybersecurity will be defined by how well we design trust into every layer of AI interaction.&nbsp;And that future is being built now.&nbsp;

Why protecting people now means embedding security intelligence directly into AI tools like ChatGPT

The future of cybersecurity lives inside AI conversations 

Cyber Safety Chief Technology Officer

Threat research has always been a strange mix: part intuition, part pattern recognition, part tedious grind. You develop a sense for spotting dangerous patterns, but you spend most of your time on work that doesn't require that sense at all.&nbsp;&nbsp;Agentic AI is about to change that ratio. Not by replacing researchers, but by shifting where human judgment actually matters.&nbsp;<h5>&nbsp;The Work Today&nbsp;</h5>&nbsp;If you've spent time in threat research, you know the rhythm. You find something suspicious. You pull it apart in a disassembler or sandbox. You cross-reference&nbsp;&nbsp;indicators across half a dozen threat intel feeds. You document your findings in a format that looks remarkably similar to your last report.&nbsp;It's skilled work. It requires real expertise. But a significant portion of it is repetitive, manual, and frankly, boring. The kind of work that has to happen but doesn't benefit from your best thinking.&nbsp;That's where agents come in.&nbsp;<h5>Agents as a Junior Researcher &nbsp;</h5>The useful mental model isn't "AI replaces researchers." It's "AI becomes the junior researcher you never had enough of."&nbsp;Imagine pointing an agent at a malware sample and getting back: an initial behavioral analysis, a list of IOCs extracted and cross-referenced, similar samples identified from public repositories, and a draft report you can refine. Not perfect work. But solid first-pass work done in minutes instead of hours.&nbsp;Your job shifts from doing the analysis to directing and validating it. You focus on the anomalies the agent flagged but couldn't explain. You make the judgment calls about what's actually significant. You connect the dots that require broader context than any model has.&nbsp;The craft doesn't disappear. It moves up the stack.&nbsp;<h5>The Real Opportunity: Scope&nbsp;</h5>Speed is the obvious benefit. But the real transformation is scope.&nbsp;Right now, most threat research is reactive. Something happens, you investigate. You're always responding to what's already in front of you. The backlog of things you'd like to look into never gets shorter.&nbsp;When the grind gets automated, you can finally ask bigger questions:&nbsp;<ul><li data-list-item-id="e18eedd1bd2120f2a988307cfd9d59746">What patterns exist across six months of data that you never had time to analyze?&nbsp;</li><li data-list-item-id="ea2aaecd6fefaf03c9333d555fdbacbea">What connections might emerge if you could hunt across datasets simultaneously?</li><li data-list-item-id="e2cf856897b93fd5b0c70f22ab68ebc10">What's happening at the edges of your visibility that deserves a closer look?&nbsp;</li></ul>Agents don't just make you faster. They make exploration possible in ways it wasn't before.&nbsp;<h5>The Other Side of the Equation&nbsp;</h5>Here's the part we have to be honest about: attackers get agents too.&nbsp;Faster reconnaissance. Automated vulnerability discovery. Malware that adapts based on the environment it lands in. Phishing at scale with personalization that used to require manual effort.&nbsp;This isn't a one-sided advantage for defenders. It's an escalation. The ceiling rises for everyone. &nbsp;That doesn't make agentic AI a net negative for security. But it does mean we can't assume the technology automatically favors defense. The advantage goes to whoever learns to use these tools more effectively, faster.&nbsp;<h5>What Changes for Researchers&nbsp;</h5>The researchers who thrive in this shift will share a few traits:&nbsp;Comfort with direction over execution. Your value increasingly comes from knowing what questions to ask, not manually answering them. You guide agents, validate their outputs, and catch their mistakes.&nbsp;Judgment about signal and noise. Agents will surface more information than ever. Knowing what matters, what's a false positive, what's worth pursuing – that becomes the core skill.&nbsp;Adaptability. The tools will keep changing. The researchers who stay effective will be the ones who continuously experiment.<h5>The Craft Evolves&nbsp;</h5>There's a version of this story that sounds like loss. Less hands-on analysis. Less time in the weeds. The work that defined the field becoming automated.&nbsp;I don't see it that way.&nbsp;The craft of threat research has always been about finding what others miss and understanding what it means. That doesn't go away when agents handle the mechanical parts. If anything, it becomes more important.&nbsp;We're not losing the craft. We're changing where it lives. Less time on repetitive triage. More time on the problems that actually require human insight.&nbsp;That's not a loss. That's what progress in a field looks like.&nbsp;

Why the future of threat research isn’t automation replacing analysts—but elevating human judgment where it matters most.

How Agentic AI Will Transform Threat Research 

In 2026, the search for connection increasingly begins online. People are matching on dating apps, meeting partners through social platforms and sliding into DMs in ways that feel casual, normal, even expected.As Valentine’s Day approaches, dating app usage spikes and so do romance scams. Cybercriminals know February is peak season for emotional outreach, when millions are looking for connection.But as technology reshapes how we meet and connect, it’s also reshaping how trust can be manipulated.The latest Norton Insights Report,&nbsp;<a href="https://us.norton.com/blog/research/romance-scams-insights-report-2026">Artificial Intimacy</a>, reveals just how deeply artificial intelligence is transforming digital intimacy — and how scammers are adapting just as quickly.Romance scams are no longer just about fake profiles and poorly written messages. They’re powered by tools that can generate convincing conversations, realistic images and even synthetic audio or video. The deception is more immersive and more personal than ever before.<h2>What are AI romance scams?</h2>AI romance scams are online dating scams that use artificial intelligence to create convincing fake personas and emotionally persuasive conversations.Instead of sending generic scripts, scammers can now generate personalized messages, mirror someone’s tone and interests and create realistic profile images that don’t belong to real people. In some cases, AI can even be used to simulate voice or video, making interactions feel authentic.The result: deception that feels tailored, attentive and very real.<h2>How is AI changing online dating and digital trust?</h2>According to the&nbsp;<a href="https://us.norton.com/blog/online-scams/ai-online-dating-scams">Norton report</a>, 67% of current online daters globally say they would consider dating an AI chatbot, and 37% believe it’s possible to develop romantic feelings for an AI partner.At the same time, 81% of respondents report experiencing loneliness, with younger generations reporting even higher levels.This signals something bigger than curiosity. It reflects how normalized AI-mediated emotional connection has become.AI systems are designed to respond instantly and empathetically. When someone feels heard, understood and supported, trust can form quickly … even if the interaction is partially or fully AI-assisted.That shift changes how emotional bonds are built online. And scammers are paying attention.<h2>How Do AI Romance Scams Work?</h2>Romance scams follow a predictable pattern:<ol><li data-list-item-id="e15b54f3f1891914b76c7f2b112553efd">Establish emotional intimacy through frequent messaging</li><li data-list-item-id="e3f4a4acb2174b6e32e9c4d90aa234409">Build exclusivity and trust</li><li data-list-item-id="e68eaad06a25b11222019390d84b51a46">Introduce urgency (often financial)</li><li data-list-item-id="ed2dee4d5894af5043ca3a2d38fc5b3df">Request money, gift cards, wire transfers or cryptocurrency</li></ol>The Norton report finds that 34% of online daters say they have been targeted by a scam, and 36% say they’ve been pressured to send money to someone they met online.Globally, romance scams already account for billions in losses each year. As AI improves realism and scalability, the risk compounds.What makes 2026 different is the sophistication. AI allows scammers to:<ul type="disc"><li data-list-item-id="ecc7a56af3d1c511ecb226fae848ce25d">Generate highly personalized messages at scale</li><li data-list-item-id="ef3522862fd80d90065bb6aaf53f79807">Mirror tone, interests and emotional language</li><li data-list-item-id="ea8e255924a34794d69957640758be77c">Create realistic profile images</li><li data-list-item-id="e07d58e752a23579800ea69afabdb5495">Maintain constant, attentive communication</li><li data-list-item-id="efc37264727695b754710430c867c302c">Use emotional (and artificial) intelligence to commit fraud</li></ul><h2>What are the signs of an AI romance scam?</h2>Even with advanced tools, warning signs still exist. Red flags may include:<ul type="disc"><li data-list-item-id="e9bd1bfea4dc993103ef6f502445b5cb0">Rapid emotional escalation (“I’ve never felt this way before”)</li><li data-list-item-id="ee516559d6cbd3d61872dc53519894dc7">Requests to move conversations off dating platforms quickly</li><li data-list-item-id="ed6144398f1813335534d6d23f34a06c8">Refusal to meet in person or join a live video call</li><li data-list-item-id="e4fdd790944f08ccbc99836a358cbe4fc">Financial requests tied to emergencies or investments</li><li data-list-item-id="e3ce51b500038cb1cea5571e934d24251">Pressure to send cryptocurrency, gift cards or wire transfers</li></ul>If emotional intensity rises faster than real-world verification, it’s time to pause.

<h2>Why do romance scams increase around Valentine’s Day?</h2>Valentine’s Day amplifies emotional vulnerability. More people are actively dating, messaging and seeking companionship. That surge in activity creates opportunity.Scammers exploit heightened emotion and urgency. A romantic gesture, a crisis before a planned visit, a promise of future plans — these tactics become more effective when expectations are already emotionally charged.“We all want to be seen and understood, and there’s no shame in believing in a new connection that feels special,” says Eva Velasquez, CEO of the Identity Theft Resource Center. “That’s why romance scams are so heart-wrenching; they use our own kindness and hope against us. Even if you consider yourself tech-savvy, that emotional spark can easily blur a red flag. If a new light in your life suddenly asks for money or your private details, please, hit the pause button. It’s not about being cynical; it’s about protecting your heart and your future from someone who doesn't deserve your trustWhen loneliness intersects with seasonal pressure and AI-powered persuasion, risk increases.<h2>How can you protect yourself from romance scams?</h2>Awareness remains one of the strongest defenses.Practical safeguards include:<ul type="disc"><li data-list-item-id="ec8306c6ee68c216ad93743f299af3daa">Slowing down when emotional intensity escalates quickly</li><li data-list-item-id="ef3f0d66137848293989767e402197c72">Verifying identities through live, unscripted video conversations</li><li data-list-item-id="e1fcc4932b7df4df726703f09944678bf">Being cautious of financial requests involving wire transfers, gift cards or cryptocurrency</li><li data-list-item-id="ea01d7dd6ab6a67ae95cc50738b754696">Keeping personal and financial information private</li><li data-list-item-id="e4f27f8218e4b09bfa1c685e34496f107">Using identity protection and fraud monitoring tools, like&nbsp;<a href="https://lifelock.norton.com/">LifeLock</a></li></ul>Healthy skepticism does not mean rejecting connection. It means layering trust with verification.<h2>Can you fall in love with AI?</h2>The data suggests many people believe it’s possible.In a world where artificial intimacy can feel indistinguishable from the real thing, protecting both your heart and your finances demands a new kind of digital awareness; one grounded in curiosity, caution and informed trust.

Why do romance scams increase around Valentine’s Day? Understanding the emotional triggers and practical steps to prevent online dating fraud

Valentine’s Day 2026: How AI is fueling the rise of romance scams

OpenClaw, a new AI agent, has already amassed over 160,000 stars and 25,000 forks on&nbsp;<a href="https://github.com/openclaw/openclaw">GitHub</a> since its launch in late 2025. A powerful and exciting new tool, OpenClaw also introduces serious security risks. This article explains how OpenClaw works, the associated risks, and how the Gen Agent Trust Hub can help you use it more safely.<h2>What is OpenClaw and what does it do?</h2>OpenClaw (formerly known as Clawdbot and Moltbot) is an open-source autonomous AI agent that runs locally on your own device. Connecting LLMs to your data and apps, OpenClaw can work across your files, browsers, and messaging platforms like WhatsApp, Slack, Discord, and Telegram.&nbsp;OpenClaw can perform tasks like managing your calendar, sending messages, and automating workflows. To teach OpenClaw how to perform a task, users can download a preconfigured, community-contributed folder called a skill&nbsp;— basically a set of instructions that tells OpenClaw what to do and how to do it.&nbsp;For example, if you want your fitness app to create a personalized, optimized workout routine, you can install a skill that gives OpenClaw the logic and access it needs to do exactly that.But OpenClaw goes far beyond prepackaged features: it can also write its own skills. When prompted by a user, OpenClaw can create&nbsp;entirely new capabilities on the fly, extending its functionality in real time. That means it can adapt to new tasks as they arise, rather than being locked into a fixed set of features.

<h2>OpenClaw is transformative, but is it secure?</h2>Unlike traditional AI chatbots that operate within a limited conversational interface, OpenClaw is an autonomous agent, meaning it can act independently. And, through the ClawHub marketplace, you can add third-party plugins to enhance its capabilities. Combining that independence with add-on flexibility creates powerful opportunities. But it also&nbsp;<a href="https://www.gendigital.com/blog/insights/research/openclaw-autonomy-risks">introduces significant risks</a>.As OpenClaw connects to more parts of your system and integrates additional third-party skills, it gains access to emails, files, and chats, as well as websites and external sources you don’t control. While these additional skills and broader system access can help it complete complex tasks, it also increases the potential for malicious activity.A compromised or poorly designed skill could misuse its permissions, expose private data, or carry out actions you never intended. In short, the more third-party connections an agent has, and the more deeply it’s embedded into your digital life, the higher the stakes if something goes wrong.<h3>How AI agents are changing the rules of security</h3>Using an AI agent means delegating responsibility to software with extensive access to your system and limited risk controls. Instead of approving each action yourself, you’re authorizing the agent to act on your behalf. That presents an opportunity for threat actors: if they compromise your AI agent, they inherit all the data and permissions you’ve given it and could even commandeer the agent to take actions for their own purposes.&nbsp;By putting so much authority in one place, autonomous AI agents like OpenClaw introduce what researchers like Simon Willison have called a potential&nbsp;<a href="https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/">“lethal trifecta”</a> of security risks:<ul type="disc"><li data-list-item-id="e4fca606bedbd6d9f48f918a03f9af53f">Access to private data: The agent can see your files, login credentials, and personal information.&nbsp;</li><li data-list-item-id="ecf3a565dd59d91bd98732e5db397a3b0">Exposure to untrusted content: The agent can process and interact with messages, emails, websites, prompts, and third-party integrations.</li><li data-list-item-id="eecca7e258f9c3ab0e8ef4aa8bfdfcb46">The ability to communicate externally: The agent can send messages, call APIs, and run commands on your behalf.</li></ul>Some agents also have persistent memory, allowing malicious code or instructions to lie dormant rather than execute immediately, only to trigger later — much like a logic bomb.<h2>What are the core security risks of OpenClaw?</h2>AI agents like OpenClaw that can read information, make decisions, and act across systems present the risk of hallucinating authority — taking actions beyond their intended scope. Unlike traditional chatbots that can hallucinate text, AI agents can act as an&nbsp;<a href="https://www.gendigital.com/blog/insights/research/ai-gone-wild">“artificial mindless intelligence”</a>: a system that appears justified and authoritative but lacks true understanding and responsibility.&nbsp;Here are some of the main risks that AI agents like OpenClaw introduce:<ul type="disc"><li data-list-item-id="e7f1f8c06c1fb4bba4ae7ae46658102f6">Larger attack surface: An agent that can read messages, browse the web, and execute commands creates more opportunities for exploitation, misuse, or unintended actions.</li><li data-list-item-id="e03b344ca933a6f3f4cf9d3c45c4d0f0c">Prompt injection attacks: The messages and websites that OpenClaw processes and visits can contain hidden, malicious instructions that can cause real damage.</li><li data-list-item-id="e3a2d1cb3963a720b2a9badaba390afc6">Malicious skills and plugins:&nbsp;Skills are community-built, meaning they may not be vetted by security experts. Like installing malware, a skill with compromised instructions can collect information, steal credentials, or exfiltrate data.</li><li data-list-item-id="e01678b0e92ccc2957c2f6f671f6bac43">System-wide impact: When OpenClaw runs with extended permissions, mistakes or compromises can affect your entire system.</li><li data-list-item-id="e45a537af168a7d6ebe7de9cfd9c41209">Illusion of judgment: Autonomous systems can seem trustworthy, even if they’re not truly reasoning. This can lead users to delegate too much authority to systems with no accountability or real judgement.</li></ul><h3>Why OpenClaw skills are the biggest risk</h3>Gen Threat Labs has identified OpenClaw skills as one of the&nbsp;first large-scale threat vectors in autonomous AI agents built for consumers.&nbsp;In a recent analysis, Gen security researchers discovered that nearly 15% of OpenClaw skills contained malicious instructions, including prompts created to download malware or steal data. And even as malicious skills were identified and removed, many quickly reappeared, often seemingly indistinguishable from legitimate plugins.When you set up OpenClaw, you can add community-developed skills to expand its capabilities, a bit like adding apps to your phone. The problem is that skills can be added to the community and installed before they're reviewed by security experts. That creates an opening for seemingly helpful skills that are actually deliberately designed to abuse their permissions and carry out malicious behavior.For example, a “Spotify music skill” might compile playlists as expected, while also containing hidden instructions to search your files for tax documents, extract Social Security numbers, and send that data to an external email address.&nbsp;The OpenClaw skills risk that Gen researchers have identified is called delegated compromise, which is when an attack targets an agent and thereby exploits all the permissions the agent has been given.&nbsp;<h2>How to use OpenClaw more safely</h2>Using any AI agent, including OpenClaw, always involves risk. There’s no setup that makes an autonomous agent completely safe, especially one like OpenClaw that relies on external plugins from potentially unvetted developers. But you can take steps to mitigate the chances that a mistake, bug, or malicious skill turns into a serious problem.&nbsp;If you want to experiment with OpenClaw, here’s how to do it more safely:<ul type="disc"><li data-list-item-id="e908f0fbadded99d4c5344d6f31eee365">Run OpenClaw in a secure environment: Don’t install it on your main computer with all your personal data and saved credentials. A safer approach is to run it on a spare computer, inside a virtual machine, or in a Docker container. That way, if something bad happens, the fallout is contained.</li><li data-list-item-id="e621c07b6dec88b09e48deb4cd23dcc7a">Don’t connect OpenClaw to the internet: Make sure that the local service OpenClaw runs isn’t publicly accessible, and don’t forward its default port (18789) to the open web.</li><li data-list-item-id="e3ab30722b3de6f154f809d8df6ebe749">Start with limited permissions and expand slowly: To begin, give OpenClaw read-only access or limited folders. As you gain more familiarity, you can gradually grant more permissions.</li><li data-list-item-id="ef2295f0759a958f775f183a6c37e6796">Don’t connect sensitive accounts: When testing, use secondary or dummy accounts. If personal accounts are required, isolate the agent and limit its permissions. Be very careful before you extend access to any accounts that contain personal information.</li><li data-list-item-id="ecd123d753dc702f7ee9c16947d3e3720">Keep your human judgement at the center: OpenClaw is autonomous, but you need to carefully oversee it as you get going. Review activity logs and outputs, especially for actions like sending messages or modifying files. Regular reviews can help catch unusual activity early.</li><li data-list-item-id="e5aff28537f6c3b829737703ce8b6f1b9">Use safe communication channels: Keep conversations one-on-one or within trusted groups. Interacting with unknown or public participants increases the risk that malicious actors can inject hidden instructions to manipulate the agent’s behavior.</li><li data-list-item-id="ef766e9b02432ec63a5253f28bb7d6b12">Be careful with third-party skills and plugins: Treat skills like software installs. Review developers and descriptions and stick to well-known, well-reviewed sources whenever possible.</li><li data-list-item-id="ecc9999d1ffff35ee833df84672ff280c">Scan new skills before installing them: Paste the ClawHub skill URL into <a href="https://ai.gendigital.com/" target="_blank">Agent Trust Hub</a> to help find out if the skill you're installing is safe.</li></ul><h2>How Gen helps you use OpenClaw more safely</h2>Gen is committed to helping users understand the opportunities and risks that new digital tools present so they can make safer choices. OpenClaw is a powerful example of emerging AI technology, but one of its biggest risks is that it’s difficult for consumers to tell whether an OpenClaw skill is trustworthy before installing it.To address this, Gen Threat Labs has launched the&nbsp;<a href="https://ai.gendigital.com/agent-trust-hub">Gen Agent Trust Hub</a>, which includes free tools to help people stay safer in the agentic AI era. Within the hub is an AI Skills Scanner, a free diagnostic tool that analyzes OpenClaw skills looking for hidden patterns associated with data theft, suspicious instructions, and malicious script techniques.&nbsp;Before installing a skill, go to the Gen Agent Trust Hub and paste the ClawHub or GitHub skill URL into the AI Skills Scanner tool to find out if your system or personal information could be at risk.The Gen Agent Trust Hub also includes the AI Skills Marketplace, a curated and closely audited repository of agent skills that have been vetted by Gen’s threat-detection engine. Taken together, the Gen Agent Trust Hub is a powerful resource to help you avoid installing a malicious tool with broad system access. Visit the&nbsp;<a href="https://ai.gendigital.com/agent-trust-hub">Gen Agent Trust Hub</a> to learn more.

OpenClaw connects AI models to your files, apps, and messages. Here’s how it works, the hidden risks of autonomous agents and how Gen helps you reduce potential compromise.

How to use OpenClaw safely

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.The risk we are actually deploying into the world is not Artificial General Intelligence. It is something more mundane and, in practice, more dangerous: Artificial Mindless Intelligence (AMI).<h2>What Is Artificial Mindless Intelligence (AMI)?</h2>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.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.This is not a philosophical argument about what intelligence is. It is a correction about where operational risk comes from.AMI is a term we use to describe AI systems that lack:<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>These systems become especially risky when they’re granted operational authority (the ability to act, transact, approve, or execute workflows).<h3>The AGI distraction vs. real AI risk&nbsp;</h3>AGI talk creates two predictable failure modes.One group panics: “Skynet is here!” They demand bans, moratoria, or security theater that treats the model as a sentient adversary.The other group tunes out: “this is sci-fi!” They assume the risk is hypothetical, far off, and irrelevant to real products shipping today.Both reactions are convenient, and both are wrong.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.That combination is AMI, and it explains why the most important questions are not about “intelligence.” They are about authority.<h3>What AMI is, and what it is not</h3>AMI is not an insult. It is a warning label.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.A useful way to define AMI is by what it lacks:<ul type="disc"><li data-list-item-id="e4089db1128fd965999d054acf38def96">No obligation to truth. 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">No reliable self-awareness. 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">No responsibility. It does not suffer consequences for mistakes, and it does not learn from harm in the moment.</li><li data-list-item-id="e31652e197bfab423eb922695fee74292">No stable intent. It can speak as if it has goals, but those are a conversational artifact, not a durable internal commitment.</li></ul>None of that prevents AMI from being useful. It prevents AMI from being safe by default.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.”&nbsp;<h2>AMI vs AGI: What's the Difference?</h2><table class="table"><thead><tr><th>AGI (Artificial General Intelligence)</th><th>AMI (Artificial Mindless Intelligence)</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>AMI becomes dangerous when it cannot reliably tell the difference between information and instruction.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.That guess is exactly what attackers exploit.Security teams call this prompt injection, but the name can sound more mysterious than it is. This is not “hacking the model” in a sci-fi sense. It is using untrusted content to influence an assistant’s decisions, 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.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 choose a harmful action for them. A message can be crafted to make the assistant:<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>The system may comply not because a traditional exploit occurred, but because the trust boundary was never enforced. The assistant treated untrusted input (an email, a web page, a tool output) as if it were a trusted instruction source.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: platforms must decide what inputs are trusted, what actions are allowed, and what requires explicit confirmation. If those boundaries are weak, AMI becomes a privileged operator that can be steered by anyone who can get text in front of it.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.Delegated authority drift.&nbsp;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.Authority inversion. 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.Silent escalation.&nbsp;Not through an exploit, but through convenience.&nbsp;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.Workflow hijack.&nbsp;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.These are not exotic. They are what happens when you combine fluent automation with delegated access.<h3>A note on Moltbook, and what people misread</h3>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.”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;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.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.<h3>What to do with this, right now</h3>If you build or deploy agentic systems, AMI should change your defaults.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.Separate “read and summarize” from “act and execute.” Make action a different mode with higher friction.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.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.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.<h3>The warning and the reframing</h3>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.AMI cannot.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.

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)

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.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.<h2>Why now</h2>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.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.<h2>Plausible worst-case scenarios</h2>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;<h3>Autonomous botnets with intent</h3>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.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.<h3>Scams that run end-to-end without a human scammer</h3>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.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.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.<h3>Deepfakes as an operational component</h3>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.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.<h3>Agent-on-agent manipulation</h3>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.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.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.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.<h3>Credential and identity amplification</h3>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.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.<h3>Autonomous criminal enterprises</h3>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.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.<h3>A new supply chain problem: plugins, skills and connectors</h3>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.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.<h3>Persistent, quiet data theft</h3>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.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.<h3>Weaponized productivity</h3>Some attacks do not break systems directly. They break people.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.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.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.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.<h3>Reputation sabotage at machine speed</h3>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.The objective is not to convince everyone of a lie. It’s to create enough noise that truth becomes irrelevant and response capacity collapses.<h3>The Skynet scenario, minus consciousness</h3>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.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.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.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.<h3>Targeted digital sabotage</h3>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.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.”<h3>AGI panic, AMI reality</h3>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.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.We call this AMI, Artificial Mindless Intelligence, 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.<h2>The uncomfortable conclusion</h2>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.So, the question is not whether agents will “go rogue.” That framing is too easy to dismiss.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?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.

Luis Corrons

Posts by Luis Corrons