Security Evangelist at Gen

Threat Operations Analyst at Gen

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.

Research

A fake invoice in your email is easy to ignore. A fake invoice inside your order history feels different.&nbsp;Norton customers have reported fake Norton invoices appearing inside the Shop app, the shopping and order-tracking app from Shopify. Public reports suggest the same technique is not limited to Norton. Similar suspicious Shop app notifications have used McAfee, Apple gift cards, iPhones, PayPal-style payment claims and other high-value purchases as bait. The impersonated brand may change, but the mechanics are familiar: make the user believe they have been charged, then give them a phone number to call.&nbsp;That phone number is where the scam really begins.&nbsp;<h4>Why the Shop app makes this more believable&nbsp;</h4>Shop is a legitimate app. People use it to track packages, check receipts and receive order updates. According to Shop’s own documentation, the app can automatically track orders from several sources, including Gmail, Outlook, the email address linked to the user’s Shop account and orders paid through Shop Pay. If Gmail or Outlook is connected, Shop says it scans recent emails for keywords such as “tracking number” and “track your package” to populate deliveries in the Orders tab.&nbsp;

Shop also supports push notifications for delivery updates, payments and favorite products. So the first alert the victim sees may not be an email, an SMS or a calendar invite. It may be a notification from an app they already use for real purchases.&nbsp;That context matters. The scam text is not especially polished. Some of the examples we reviewed contain awkward wording and obvious signs of fraud. But when the message appears inside an order-tracking app, surrounded by real receipts and shipping updates, users may give it more credibility than it deserves.&nbsp;The screenshots reported to us show fake orders under generic seller names such as “My Store.” The receipts claim that a Norton or Norton LifeLock subscription has been activated or renewed, usually for several hundred dollars. The phone number appears in the product description, the receipt body or even the shipping address field.&nbsp;That is not how a normal receipt should look.&nbsp;<h4>The brand is interchangeable&nbsp;</h4>Norton is the example we saw through customer reports. Norton support now warns that scammers may abuse Android and iOS shopping platforms or applications to generate fake order notifications that appear to be legitimate Norton purchases. Those notifications may include fake order confirmations, fake charges, trusted third-party app delivery and fake support phone numbers embedded in order details.&nbsp;Public user reports point to a wider pattern. One Reddit user described receiving a Shop.app message about a transaction they did not recognize, with no follow-up email confirmation, and a message telling them to call support if the order was not placed by them. Another thread includes reports of unrecognized iPhone purchases under “My Store,” suspicious contact emails and users saying they saw no matching charges on their bank cards. Other reports mention fictitious Apple gift card purchases and iPhone orders using the same kind of wording: “If Order Not Placed By You,” followed by a phone number.&nbsp;The choice of brand is part of the social engineering. A fake security subscription charge plays on two fears at once: being billed for something you did not buy, and being left unprotected if you ignore it. Apple products and gift cards create high-value purchase panic. PayPal-style wording makes users worry about payment account abuse. In each case, the fake order is there to push the victim toward a call.&nbsp;<h4>What we know, and what we do not&nbsp;</h4>We have not found any evidence that any of the impersonated brands have been compromised.&nbsp;&nbsp;We also should not claim that Shop or Shopify was breached based on the evidence we have. The exact abuse path still needs confirmation. The fake order may be entering the app through a merchant/order workflow, through email parsing, through account association, or through another legitimate mechanism that scammers have found a way to misuse. Shop’s own documentation shows that orders can populate from multiple sources, so assuming one route would be premature.&nbsp;&nbsp;What we can say is narrower and stronger: scammers are placing fake purchase claims inside shopping app order experiences, where users are used to seeing real receipts and order updates. Norton’s own support page now describes this class of shopping app scam, and public reports show similar lures using other brands and products.&nbsp;&nbsp;That is enough to warn users without overstating the technical evidence.&nbsp;<h4>How the scam works&nbsp;</h4>The user receives a notification or sees a new order in the Shop app. The order looks like a receipt for something expensive: a security subscription, an Apple gift card, an iPhone, a MacBook or another high-value purchase.

The receipt says the charge has been processed, the subscription has renewed, or the order is being prepared. Somewhere in the order details, the scammer inserts a phone number, email address or support instruction.&nbsp;The wording is often clumsy. We have seen phrases like “If Order Not Place By You” and “If Need Help.” Those errors may look obvious when reviewing a screenshot. They are easier to miss when a phone notification tells you that hundreds of dollars have just been charged.&nbsp;If the victim calls, the scam moves off-platform. The person answering may claim to be billing support, Norton support, PayPal support or a cancellation department. The script can vary, but the request usually moves toward credentials, payment data, one-time codes or remote access software.&nbsp;By that point, the fake receipt has done its job. It has created enough urgency for the victim to enter a conversation controlled by the scammer.&nbsp;<h4>Why this is harder for users to judge&nbsp;</h4>Most people understand that email can be spam. They may still fall for phishing, but at least the inbox is a place where scams are expected.&nbsp;Order-tracking apps are different. Their purpose is to collect receipts, shipping updates and purchase information in one place. A notification from that environment can feel as if it has already passed through some layer of trust, even when the content inside the order is fraudulent.&nbsp;We have seen the same logic with calendar invite scams. The message itself is not always convincing, but the delivery channel changes how people read it. A fake invoice in an inbox is one thing. A fake invoice inside a calendar reminder or shopping app receipt can feel closer to a real event.&nbsp;For security products, this also creates a detection problem. The first visible alert may not be an email, SMS or malicious website. It may be a legitimate app notification carrying fraudulent text. The scam still depends on social engineering, but the delivery surface is harder to classify with the usual rules.&nbsp;<h4>What to do if you see one&nbsp;</h4>Do not call the number in the receipt.&nbsp;Check the charge directly. Open your bank or credit card app. Open the official account for the brand being impersonated. If it claims to be Norton, go to your Norton account or official Norton support. If it claims to involve PayPal, open PayPal directly. Do not use the phone number, email address or link inside the suspicious order.&nbsp;If there is no matching charge, treat the receipt as a scam attempt.&nbsp;Report the suspicious store or message in the Shop app if the option is available. Shop’s help pages say suspicious Shop stores can be reported from the store page through the app, and Shopify also tells users to forward phishing messages to its phishing inbox.&nbsp;&nbsp;Norton users can forward suspicious messages to Norton and should verify unexpected charges only through their Norton account or official Norton support channels.&nbsp;&nbsp;Opening the receipt does not automatically mean your device was compromised. The risk increases if you call the number, share information, install software or follow instructions from the person on the phone.&nbsp;<h4>What to do if you have already called&nbsp;</h4>End the call.&nbsp;If you shared payment details, contact your bank or card provider immediately using the number on your card or inside your banking app. If you gave away a password, change it from a different device if possible. Start with your email account, Apple ID or Google account, banking account and any account connected to the fake invoice.&nbsp;If you installed remote access software, disconnect the device from the internet and remove the software. Run a security scan before using the device again for banking, email or shopping.&nbsp;If you gave a one-time code to the caller, treat the related account as compromised. Change the password, review recovery options and check recent login activity.&nbsp;<h4>The lesson&nbsp;</h4>Scammers keep testing new places to put old tricks. For years, fake invoices were mostly an email problem. Then similar subscription notices appeared in calendar invites. Now we are seeing fake receipts inside shopping app order histories and push notification flows.&nbsp;The safest response is to separate the alert from the action. If an app, email, text message or calendar invite says you have been charged, do not use the contact details inside that alert. Go directly to the account or payment provider yourself. Check whether the charge exists. Use official support channels.&nbsp;The fake receipt, the fake support number and the fake emergency are all part of the same controlled environment. The moment you verify the charge somewhere else, the scam loses most of its power.&nbsp;

Scammers are using order-tracking apps to place fake receipts where users expect to see real purchases, then pushing them to call fake support numbers. 

Fake invoices are moving from inboxes to shopping apps 

Threat Researcher at Gen

<h2>Introduction&nbsp;</h2>Infostealers are constantly evolving, and so are the techniques they use to bypass <a href="https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html" target="_blank" rel="noreferrer noopener">Application-Bound Encryption (ABE)</a>. In recent weeks, Vidar has been among the most actively developed stealers and, apart from <a href="https://x.com/GenThreatLabs/status/2064836539952361976" target="_blank" rel="noreferrer noopener">multiple updates to its string obfuscation</a> and <a href="https://x.com/GenThreatLabs/status/2061462524604649840" target="_blank" rel="noreferrer noopener">a reworked approach to protecting its configuration</a>, it has also introduced a novel technique for bypassing ABE. And while there have been many other changes in Vidar lately, with new versions dropping every week, in this blog post we focus solely on the ABE bypass and its technical aspects.&nbsp; &nbsp;<h2>The ABE Bypass&nbsp;</h2>From a high-level perspective, Vidar’s approach to bypassing ABE is somewhat similar to that of Remus/Lumma, in that both try to extract the <code>v20_master_key</code> directly from the browser’s memory. What sets them apart, however, is how they achieve it. Since we’ve already covered the inner workings of ABE in earlier posts (<a href="https://www.gendigital.com/blog/insights/research/remus-64bit-variant-of-lumma-stealer" target="_blank" rel="noreferrer noopener">Remus</a>, <a href="https://www.gendigital.com/blog/insights/research/voidstealer-abe-bypass" target="_blank" rel="noreferrer noopener">VoidStealer</a>), we don’t revisit them here and focus instead on the bypass itself. For readers interested in the broader background, we encourage checking those earlier posts.&nbsp;&nbsp;In short, the end goal of infostealers is to obtain the <code>v20_master_key</code>, as it alone is sufficient for decrypting any ABE-protected data tied to a specific application. This key can be obtained in one of two ways: either from disk, where it is protected by two layers of <code>CryptProtectData</code> (one applied in the context of the logged-in user and one as <code>NT AUTHORITY\SYSTEM</code>), or from the browser’s memory – the direction Vidar took.&nbsp;In memory, however, the key is kept protected with <code>CryptProtectMemory</code> using the <code>CRYPTPROTECTMEMORY_SAME_PROCESS</code> flag. This ensures that even if an attacker manages to read the encrypted form of the key from memory, they cannot simply decrypt it (they would need to invoke the complementary <code>CryptUnprotectMemory</code> function directly from within the browser process). That leaves attackers with two problems to solve: how to find the encrypted key in memory, and how to get it decrypted.&nbsp;<h2>Locating the v20_master_key in Browser’s Memory&nbsp;</h2>Vidar’s approach to locating the encrypted <code>v20_master_key</code> in memory involves scanning the entire memory of a running browser for a specific pattern. But that first requires a browser process to scan.&nbsp;When the target browser is already running, Vidar reuses the existing process. However, it doesn’t read its memory directly. Instead, it creates a fork of it using <code>NtCreateProcessEx</code> with <code>SectionHandle</code> set to <code>NULL</code>, instructing the kernel to clone the address space of the process specified by the <code>ParentProcess</code> as a copy-on-write mapping. The resulting process has no threads and is never resumed – it exists purely as a static memory snapshot.&nbsp;&nbsp;To perform the fork, Vidar first opens a handle to the target browser via <code>OpenProcess</code> with <code>PROCESS_QUERY_INFORMATION | PROCESS_CREATE_PROCESS | PROCESS_VM_READ</code>, falling back to <code>PROCESS_CREATE_PROCESS</code> if the initial call fails. It then passes this handle as the <code>ParentProcess</code> argument to <code>NtCreateProcessEx</code>, requesting <code>PROCESS_ALL_ACCESS</code> on the resulting child. If the fork fails, Vidar falls back to scanning the live browser process directly.&nbsp;

If no target browser process is found running, Vidar creates a new isolated desktop via <code>CreateDesktopA</code>, assigns it a name of the form <code>v20_%d</code> (where <code>%d</code> is replaced with the browser’s index in Vidar’s configuration), and launches the target browser in there. In the case of Vidar version 2.1, the browser is launched with the command line <code>--no-first-run --disable-gpu about:blank</code>, although the exact command line varies across versions. Since modern browsers use a multi-process architecture, there are typically multiple processes matching a given browser. Vidar enumerates all of them (up to 64) and applies the fork-and-scan procedure to each one independently.&nbsp;

With a handle to the forked process in hand, Vidar proceeds to enumerate its virtual memory regions using <code>NtQueryVirtualMemory</code>. It iterates through the entire browser’s address space, collecting regions that match a specific profile: committed (<code>MEM_COMMIT</code>), private (<code>MEM_PRIVATE</code>), and either readable (<code>PAGE_READONLY</code>) or read-write (<code>PAGE_READWRITE</code>). Vidar records up to 4096 memory regions matching these requirements, along with their base addresses and sizes. The actual pattern scanning is then performed in parallel with up to 64 worker threads, depending on the system.&nbsp;&nbsp;

Each thread scans its assigned regions using <code>NtReadVirtualMemory</code>, searching for a 32-byte pattern. When a match is found, the thread reads 8 bytes at offset +32 from the match, interprets them as a pointer, and validates that it points to committed, private, and readable memory (the expected memory state for the encrypted <code>v20_master_key</code>).&nbsp;&nbsp;

This naturally raises the question of what pattern Vidar searches for. The answer is a 32-byte signature: <code>76 32 30 00 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 03 00 00 00 00 01 ?? ?? ??</code>, where <code>??</code> denotes a wildcard (Vidar uses the byte <code>AA</code> as the wildcard marker in its internal representation). Notably, the first four bytes correspond to the ASCII <code>v20\x00</code>, which is a common prefix used for ABE-related data.&nbsp;&nbsp;

We assess with high confidence that this pattern is intended to match a node structure within Chromium’s <code>Encryptor::KeyRing</code>, the structure that holds the keys used by the <code>Encryptor</code> class. Now, this part is admittedly a bit tricky as it relies on several assumptions we made about the internal memory layout, as well as on implementation-specific representations of various C++ standard library types <code>(std::map</code>, <code>std::string</code>, <code>std::vector</code>, <code>std::optional</code>), which is why we frame this as a high-confidence rather than a certainty.&nbsp;&nbsp;Our reasoning is as follows: <code>KeyRing</code> is <a href="https://github.com/chromium/chromium/blob/cf5d502bcaedb22927e3829a18be1ff6d8b6f598/components/os_crypt/async/common/encryptor.h#L132" target="_blank" rel="noreferrer noopener">defined</a> as <code>std::map&lt;/*tag=*/std::string, std::optional&lt;Key&gt;&gt;</code>, and <code>std::map</code> is typically implemented as a red-black tree, where each tree node stores three pointers (left child, parent, and right child) followed by the key-value pair. In this case, the pair is in the form of <code>std::pair&lt;/*tag=*/std::string, std::optional&lt;Key&gt;&gt;</code>, meaning that the <code>std::string</code> and the <code>Key</code> object might be laid out consecutively in memory within each node. For a <code>v20_master_key</code> entry, the tag corresponds to the string <code>v20</code>, which at 4 bytes including the null terminator fits within the small string optimization (SSO) buffer and is therefore stored inline rather than heap-allocated. The <code>Key</code> class that immediately follows <a href="https://github.com/chromium/chromium/blob/cf5d502bcaedb22927e3829a18be1ff6d8b6f598/components/os_crypt/async/common/encryptor.h#L93-L98" target="_blank" rel="noreferrer noopener">contains three member variables</a>: <code>std::optional&lt;mojom::Algorithm&gt; algorithm_</code>, <code>std::vector&lt;uint8_t&gt; key_</code>, and <code>bool encrypted_ = false</code>.&nbsp;Putting it all together and applying it to a concrete example from a browser memory dump, we get the following layout:&nbsp;

Please note that while the exact layout may contain minor inaccuracies on our part, the overall structure should be roughly correct. For easier orientation, the following diagram illustrates how the individual structures are nested within each other:&nbsp;

At this point, it should be clear how the scan pattern maps onto the searched structure. The 32-byte match covers the <code>std::string</code> tag <code>v20\x00</code> and the beginning of the <code>Key</code> object up to and including <code>algorithm_</code>. The pointer at offset +32 from the start of the match then lands precisely on <code>key_.begin</code>, the first member of <code>std::vector&lt;uint8_t&gt;</code> that holds the encrypted <code>v20_master_key</code>.&nbsp;Matches from all threads are collected into a shared buffer and subjected to a majority-voting scheme: candidates consisting mostly of zeroes are discarded, the rest are pairwise-compared, and each is scored by the number of identical copies found. This voting is performed independently for each browser process, producing one best candidate per process.&nbsp;<h2>Decrypting the v20_master_key via APC Injections&nbsp;</h2>For each browser process that produced a match, Vidar now holds a candidate address pointing to a potential encrypted <code>v20_master_key</code>. However, as already noted, since the key is protected with <code>CryptProtectMemory</code> using <code>CRYPTPROTECTMEMORY_SAME_PROCESS</code>, it can only be decrypted by invoking <code>CryptUnprotectMemory</code> from within the browser process itself. Vidar solves this by injecting an Asynchronous Procedure Call (APC) into the live browser process.&nbsp;Vidar supports two APC injection methods, selected based on whether ESET or Bitdefender is detected on the system. If either of these products is present, Vidar uses the first method, which it refers to as “classic” (based on decrypted strings) – it creates a suspended thread in the target browser via <code>CreateRemoteThread</code> (with <code>NtTestAlert</code> as the thread start address and the <code>CREATE_SUSPENDED</code> flag), queues an APC using <code>NtQueueApcThread</code>, resumes the thread, and then waits for it to complete via <code>WaitForSingleObject</code> with a randomized timeout. When the thread resumes, it calls <code>NtTestAlert</code>, which flushes the APC queue and executes the injected routine.&nbsp;

If neither product is detected, it uses the “special” method – it finds an existing thread in the target browser using a combination of <code>CreateToolhelp32Snapshot</code> and <code>Thread32First/Thread32Next</code>, opens it via <code>NtOpenThread</code>, and calls <code>NtQueueApcThreadEx2</code> with the <code>QUEUE_USER_APC_FLAGS_SPECIAL_USER_APC</code> flag. Unlike regular APCs, special user APCs execute immediately. Therefore, the target thread does not need to be in an alertable wait state.&nbsp;

In both cases, the APC routine to be executed is <code>CryptUnprotectMemory</code>, called with the following three arguments: the address of the encrypted <code>v20_master_key</code> candidate, its size (32 bytes), and <code>CRYPTPROTECTMEMORY_SAME_PROCESS</code> for the <code>flags</code> parameter.&nbsp;&nbsp;Since <code>CryptUnprotectMemory</code> decrypts the data in place, once the APC executes, the key is decrypted directly in the live browser's memory. To read it, Vidar creates a second fork of the browser process and reads the key from the same address using <code>NtReadVirtualMemory</code>. It then compares the result against a snapshot of the encrypted key taken from the first fork before the APC call – if the data is unchanged, decryption failed, and Vidar moves on to the next browser process’s candidate.&nbsp;If the data differs, Vidar uses the same second fork to perform an additional verification: it scans the forked process’s memory for the byte sequence <code>v20</code> and, treating each match as a potentially ABE-encrypted entry (cookie, password), attempts AES-256-GCM decryption with the key candidate using <code>BCryptDecrypt</code> (successful GCM tag verification confirms that the key is correct).&nbsp;Whenever the data has changed (indicating that decryption of the key took place), Vidar re-encrypts the key in the browser’s memory by injecting another APC with <code>CryptProtectMemory</code> as the routine, preserving the browser’s state. If no candidate produced a successful decryption (i.e., the data remained unchanged after every APC call), Vidar takes a more aggressive approach: it terminates all browser instances, restarts the browser, and repeats the entire scan-decrypt-verify cycle.&nbsp;By abusing APC injections instead of the more traditional approach of injecting code via <code>NtWriteVirtualMemory</code> that performs the decryption, Vidar trades one suspicious behavior for another. APC injections are arguably less common and may thus slip past some detection systems, though they are still well-known techniques monitored by AV and EDR solutions. But that is the nature of ABE bypasses – each has its own advantages and disadvantages, and that’s exactly why infostealers keep inventing new ones. &nbsp;<h2>Indicator of Compromise (IoC)&nbsp;</h2>459daa809751e73f60fbbe4384a7d1653c36bb06945e4eb3635270924241100a (Vidar 2.1)&nbsp;

A Technical Walkthrough of How Vidar Defeats Application-Bound Encryption

Inside Vidar’s ABE Bypass: From Memory Scanning to APC Injections

You have a summer flight booked. You have seen the headlines about jet fuel shortages, cancelled routes and higher travel costs. Then a text message arrives: your flight has been affected, and you need to click a link to confirm your refund or rebook before the offer expires.&nbsp;That message feels plausible because the situation around it is real. In April, <a href="https://www.iata.org/en/pressroom/2026-releases/2026-04-17-01/" target="_blank" rel="noreferrer noopener">IATA warned</a> that Europe could start seeing flight cancellations by the end of May if jet fuel shortages materialized. Airlines and governments have since been trying to reassure travelers, while also publishing guidance on passenger rights, refunds and re-routing.&nbsp;&nbsp;That is exactly the kind of confusion scammers like. They do not need to cause the disruption, they only need to arrive at the right moment, with the right brand logo and the right sense of urgency.&nbsp;<h4>Why travel disruption works so well as a scam hook&nbsp;</h4>Most scam messages fail because they arrive out of context. A random refund email from an airline you never use is easy to ignore. A refund message from the airline you are flying with next week, during a period of public travel disruption, is different.&nbsp;The scammer’s job is to make you think: “This could be real.”&nbsp;That can happen in several ways. You might receive a fake cancellation email that links to a refund form. You might search for an airline’s customer service number and land on a fake support page. You might post publicly on social media asking an airline for help, then receive a reply from an account that looks official. Or you might get a WhatsApp message that knows your hotel name, travel dates or booking reference.&nbsp;Each version uses the same pressure point: you are worried about losing money, losing your flight or being stranded.&nbsp;Criminals are already using disruption this way. In March, <a href="https://www.theguardian.com/money/2026/mar/15/travel-scam-airline-accounts-fake-refunds-iran-war-flight-disruption" target="_blank" rel="noreferrer noopener">The Guardian reported</a> that fake airline support accounts were targeting travelers affected by Middle East flight disruption. Some victims were looking for help or refunds, then received replies from accounts pretending to represent airlines. The scam moved into direct messages, where victims were asked for details and sent links that led to money being taken instead of refunded.&nbsp;&nbsp;The jet fuel story gives scammers another pretext. A message can claim that your flight was cancelled, your fare changed, your fuel surcharge failed, or your refund must be claimed within a few hours. None of those claims needs to be true to be effective.&nbsp;<h4>The scam may start before the message arrives&nbsp;</h4>A fake travel message becomes much harder to spot when it includes real information.&nbsp;This is the idea behind <a href="https://www.gendigital.com/blog/insights/research/reservation-hijack-scam" target="_blank" rel="noreferrer noopener">Reservation Hijack scams</a>, a form of targeted phishing where cybercriminals use real booking details to make a message look legitimate. In some cases, attackers may use information exposed through breaches or compromised travel systems. In other cases, they collect details from emails, social media posts, previous leaks or fake customer service interactions. Gen has previously described Reservation Hijack scams as scams that use real hotel booking details to make fraudulent payment or verification requests feel authentic.&nbsp;&nbsp;That distinction matters. A scam message does not need your credit card number to fool you. Knowing your name, your destination, your travel dates and your booking platform may be enough.&nbsp;<h4>What these scams can look like&nbsp;</h4>A travel disruption scam usually does not begin with a strange offer. It begins with something boring and administrative. That is part of the trick.&nbsp;You may see messages like:&nbsp;“Your flight has been cancelled due to fuel supply issues. Claim your refund here.”&nbsp;“Your rebooking is pending. Confirm passenger details within two hours.”&nbsp;“Additional airport tax or fuel surcharge is required to keep your booking.”&nbsp;“Your hotel reservation will be cancelled unless payment is verified.”&nbsp;“Due to high call volume, please continue this request on WhatsApp.”&nbsp;The exact wording changes, but the structure is familiar. There is a problem, a deadline and a link. The message may also move you away from the official channel into SMS, WhatsApp, Telegram, direct messages or a phone call. Once that happens, the scammer controls the conversation.&nbsp;There is another detail worth watching: some messages do not ask for money immediately. They start by asking for your booking reference, last name, phone number or one-time password. That can still be dangerous. Those details can help scammers access a booking, impersonate you to customer support, reset an account or make the next message more convincing.&nbsp;<h4>Your real passenger rights can be used against you&nbsp;</h4>If an airline cancels your flight, you may have rights to a refund, re-routing or assistance, depending on where you are travelling and the rules that apply. The European Commission said passengers affected by cancellations continue to have rights to reimbursement, re-routing or return, airport assistance and compensation for last-minute cancellations in relevant circumstances. It also said airlines cannot retroactively add fuel surcharges to already published final ticket prices.&nbsp;&nbsp;That information is useful for travelers, but it is also useful for scammers.&nbsp;A fake refund message becomes more believable when people already know refunds are possible. A fake rebooking link becomes more believable when airlines are genuinely changing schedules. A fake “fuel surcharge” demand becomes more dangerous when fuel prices are in the news, even though legitimate retroactive charges may not be allowed in many cases.&nbsp;This is why the safest route is not to judge the message only by whether the story sounds plausible. During travel disruption, many scam stories will sound plausible. Judge the channel instead.&nbsp;<h4>How to check before you click&nbsp;</h4>Start from the airline or booking platform’s official app or website. Do not use the link in the message. Open the app yourself, type the website address yourself, or use the contact details listed on your original booking confirmation.&nbsp;Check whether the same cancellation, refund or payment request appears inside your account. If the message is real, the airline or hotel should be able to confirm it through an official channel.&nbsp;Be careful with social media support. If an account replies to your public complaint, check whether it is linked from the airline’s official website. Look at the handle carefully. Fake support accounts often copy logos and names, but have small differences in spelling, low follower counts or recently created profiles. The Guardian reported that fraudsters often scan social media for passengers trying to contact legitimate airline accounts and reply to them first, which makes the scam harder to spot.&nbsp;&nbsp;Do not share one-time passwords, payment card details or login credentials with anyone who contacts you unexpectedly. A real airline or hotel does not need your banking OTP to send you a refund.&nbsp;Be especially suspicious of pressure. “You have 30 minutes to claim your refund” is not customer service. It is a tactic.&nbsp;<h4>What to do if you already clicked&nbsp;</h4>If you entered payment details, contact your bank or card provider immediately. Ask whether the transaction can be blocked or reversed, and request a new card if needed.&nbsp;If you shared login details for an airline, hotel or booking platform, change the password from the official site or app. Use a unique password, not one you use elsewhere. Turn on two-factor authentication where it is available.&nbsp;If you shared a one-time password or authentication code, assume the account may have been accessed. Check your booking details, payment methods and recent account activity.&nbsp;Report the scam to the airline, hotel or booking platform being impersonated. If the scam came through social media, report the account as impersonation. If money was taken, report it to the relevant fraud authority in your country.&nbsp;<h4>The real lesson for summer travel&nbsp;</h4>Travel disruption changes how people behave. They search for support numbers in a hurry. They post publicly because customer service queues are long. They accept strange instructions because they are worried about losing a flight or refund.&nbsp;Scammers build around that behavior.&nbsp;The safest assumption is simple: if a message about your flight, hotel or refund creates urgency and gives you a link, pause. Go back to the official source. A real cancellation will still be there when you check through the airline or booking platform. A scammer needs you to act before you do.&nbsp;

Travel disruption gives scammers the one thing they need most: a believable reason to rush you

Your flight was cancelled. Is the refund message real? 

A fake job interview page is easier to trust than a fake ticket shop.In samples reviewed by Gen threat researchers, scammers used branded hiring pages that looked like ordinary recruitment flows: a company logo, a recruiter profile, a 30-minute meeting, and a button to continue with Google or Facebook. There was no attachment to open and no software to install. The credential theft attempt sat inside a step many job applicants already expect: signing in to schedule a call.FIFA is an obvious lure ahead of the 2026 World Cup. On May 22, ESET reported fake FIFA-themed websites that copied ticket and merchandise flows to steal money and personal data. Our researchers later found another FIFA-themed domain, hxxps://fifa-mg[.]shop, which followed a naming pattern not mentioned in that report. Domains like these can be short-lived, often appearing for hours or days before they are blocked, abandoned, or taken down.Our researchers also found a different kind of FIFA lure: hxxps://fifahiring[.]com, a fake hiring page that encouraged users to schedule a call with an alleged FIFA recruiter. When a user tried to register with a personal Gmail address, the page asked for a business email instead. The page was steering victims toward credentials with more value: accounts that could provide access to a company environment.

<h4>The FIFA hiring page did not point to FIFA</h4>The fake page looked believable at first glance.

It used FIFA branding, presented a recruiter identity, and copied parts of the experience users see on legitimate recruiting and scheduling platforms. The recruiter’s name and photo appeared to match a real LinkedIn profile, which made the page feel more credible. For publication, we should keep that person’s identity redacted.The domain did not match FIFA’s real hiring infrastructure. FIFA’s legitimate careers pages are jobs.fifa.com and fifa.pinpointhq.com. The fake page used neither. It also loaded the favicon from the real FIFA recruitment site hosted at pinpointhq.com, giving the page a small visual cue borrowed from the legitimate service.Other signals pointed in the same direction. The domain and certificate were newly created, from May 23. The site used commodity hosting infrastructure, including Vercel and Render, rather than a corporate environment. Those signs are not enough on their own, but they fit the rest of the evidence.The login flow was the clearest part. Credentials were posted to:fifeq2026eqbackeq[.]onrender[.]com/api/loginThe Google sign-in prompt was not a real Google authentication window. It was rendered inside the page itself. The visible controls and links did nothing, and the page did not send the user into a genuine Google sign-in flow. According to the analysis, the only Google asset loaded was the favicon, apparently to make the fake window look familiar.A page can look like it opened a Google login without ever handing control to Google.Researchers also observed hxxps://careers-fifahiring[.]com, which later became inactive, and hxxps://fifajobs[.]com, which showed the same content and was indexed by Google.&nbsp;<h4>The recruitment lure went beyond FIFA</h4>The FIFA page was one version of a wider recruitment phishing pattern. The brand can change. The flow stays familiar: recruiter profile, meeting prompt, business email, fake sign-in.Researchers found similar fake hiring pages abusing other major brands, including Heineken, Hilton, Coca-Cola, Netflix, PepsiCo, Delta,&nbsp;and Spotify. In the Heineken case, the page appeared to use the identity of someone who, according to LinkedIn, really works as a recruiter at the company.

Additional hunting found two other recruitment-themed kits:hxxps://aquent-talent-jobs[.]com hxxps://hays-talent-opportunities[.]comThe Hays-themed version targeted Facebook credentials instead of Google credentials. Researchers assessed that the Aquent and Hays pages shared code, although they differed from the earlier FIFA examples.

This flexibility makes the campaign harder to frame as a single World Cup scam. FIFA provides the timely hook, but the mechanism is recruitment phishing. A scammer can swap the logo, recruiter name, and sign-in provider while keeping the same basic path to the victim’s credentials.<h4>Why fake recruitment pages work</h4>Recruitment gives attackers a clean excuse to ask for things that might otherwise raise suspicion.A candidate expects to click a scheduling link. They expect a recruiter profile. They expect a calendar prompt. In some cases, they may also expect to use a work email, especially for corporate, contractor, or partner-facing roles.The fake login window turns that ordinary flow into credential theft. Users are used to “Continue with Google” and “Continue with Facebook” buttons, but the button itself proves nothing. A genuine authentication flow should take the user to the provider’s domain and controls. A fake page can draw a convincing copy while keeping the victim inside the attacker-controlled site.The business email prompt is also a warning sign. A page that rejects a personal email and asks for a work address may be trying to raise the value of the stolen account.<h4>What job seekers should check before signing in</h4>Start from the company’s official careers page, not from a link in a message, ad, search result, or forwarded post. For FIFA, that means checking jobs.fifa.com or fifa.pinpointhq.com, not trusting a domain because it contains “fifa,” “career,” “hiring,” or “jobs.”Look closely at the domain before entering credentials. Scam pages often add plausible hiring words around a brand name: career, talent, jobs, hiring, portal, or connect. A polished page on a new domain is still a new domain.Treat the sign-in step as the real checkpoint. If a page offers Google or Facebook login, check whether the flow actually opens a real provider-controlled authentication page. A fake window embedded inside the original site, broken controls, inactive links, or a provider logo used only as decoration should stop the process.Use security software that includes web and phishing protection. These tools can block known malicious pages before they load, which is especially useful when scam domains look polished, appear in search results, or are shared through otherwise legitimate channels.<h4>What companies can do</h4>Recruitment pages are public by design, which makes them easy to copy.Security teams should monitor for newly registered domains combining their brand with hiring-related terms. They should also watch for pages that reuse favicons, recruiter photos, job descriptions, and calendar-booking language from legitimate hiring flows.HR and recruiting teams should make the official hiring path easy to verify. Candidates should not have to guess whether a domain is legitimate. A clear careers page, consistent recruiter communication, and warnings about unofficial scheduling links can remove some of the ambiguity attackers rely on.<h4>Conclusion</h4>The fake FIFA hiring page worked because it did not feel unusual. It looked like a normal step in a hiring process.Attackers do not need to invent new behavior when they can copy one people already trust. A branded scheduling page, a recruiter profile, and a familiar sign-in button can be enough to move a victim from interest to credential entry.The decision point is the login. Before entering a work email or password, check the domain, check where the authentication flow really goes, and verify the role through the company’s official careers site. Security software with web and phishing protection adds another layer, especially against short-lived scam pages that may only stay online for hours or days.IOCs:hxxps://fifahiring[.]com hxxps://careers-fifahiring[.]com hxxps://fifajobs[.]com hxxps://fifa-mg[.]shop hxxps://heineken-careers[.]com hxxps://aquent-talent-jobs[.]com hxxps://hays-talent-opportunities[.]com fifeq2026eqbackeq[.]onrender[.]com/api/login

Scammers are copying recruitment and calendar-booking flows to make fake Google and Facebook sign-ins look routine. 

Fake hiring pages abuse FIFA and other major brands to steal work credentials 

Threat Research Team Lead

Since January 2026, we have detected 7.4 million malicious incidents tied to residential proxy traffic, affecting 572,000 users in our telemetry. In this model, the household whose connection is being used is often not the buyer of the traffic. It is the exit point.That is the uncomfortable part of residential proxy networks. A home router, laptop, phone, smart TV, or other always-on device can quietly become part of a commercial network that routes strangers’ internet traffic through ordinary consumer IP addresses. To the websites on the other end, that traffic looks as if it came from a real household, because it did.The technology itself is not inherently malicious. Businesses use residential proxies for market research, ad verification, brand protection, security testing, and services that need to see the web as a real user would. But the same feature that makes these networks useful also makes them attractive for abuse: traffic from a household IP address is hard to block without risking false positives against legitimate users.The problem for consumers is simpler. Many people do not realize their device or connection can be enrolled into this kind of network at all. Some users opt in through pay-for-bandwidth apps. Others are enrolled through “free” VPNs, bundled software development kits inside unrelated apps, or unwanted software that installs proxy components without meaningful consent.Here is how the market works, who pays for it, and what it can cost the household that unknowingly hosts it.<h2>What is a residential proxy</h2>A residential proxy is an internet connection – typically a home laptop, phone, smart TV, or router – that has been enrolled into a third-party network and is being used to route someone else's traffic. To the rest of the internet, that traffic looks like it is coming from an ordinary household IP address assigned by a consumer ISP, not from a datacenter or&nbsp;VPN provider.Residential proxy networks are sold commercially. The model is two-sided: some people pay to tunnel their traffic out through someone else's connection (much like a VPN, except the exit point is a real home), while others get paid to provide those exit endpoints. Some are structured as paid peer-to-peer networks, where any participant's connection can serve as an exit for any other.Buyers pay for access to pools of millions of these "real user" IPs because they are extremely difficult to block, or rather, blocking them carries real consequences: the traffic originates from genuine households, so any block risks shutting out a legitimate user – effectively a false positive.Common buyers include market research firms, price-comparison services, brand-protection vendors, security teams testing their own defenses, and consumer privacy tools. At the abusive end of the market, the same infrastructure used by operators running automated purchasing bots, scrapping campaigns, ad fraud, credential stuffing, phishing and other attacks where hiding the true origin of the traffic matters. Demand is also being shaped by large-scale web scraping, including&nbsp;<a href="https://blog.includesecurity.com/2026/06/the-smart-tv-in-your-livingroom-is-a-node-in-the-aiscraping-economy/">scraping for AI training data</a>. As anti-bot systems become better at identifying traffic from datacenters and known VPN providers, residential IP addresses become more attractive because they look like ordinary users. That does not make every residential proxy user malicious. It does mean consumers may be carrying traffic for businesses and actors they have never heard of.<h2>How consumer devices end up in these networks</h2>There are several ways a home device can become part of a residential proxy network. Some are explicit. Others are easy to miss.The most obvious route is the pay-for-bandwidth model. Apps such as Honeygain, IPRoyal Pawns, and PacketStream pay users to share their internet connection. The user opts in, but they may not understand who will buy access to that connection later, what kind of traffic will pass through it, or what happens if that traffic triggers abuse reports.A second route is the “free” VPN or proxy app. Instead of charging a subscription, the app monetizes the user’s connection by reselling bandwidth. In practice, the user may think they are getting a privacy tool while also becoming infrastructure for other people’s traffic.A third route is through bundled software development kits, or SDKs. A developer adds a third-party component to an otherwise unrelated app, such as a flashlight, wallpaper, game, or utility. The developer gets paid when the app is active. The user sees the host app, not the proxy network behind it.The fourth route is malware or potentially unwanted software. In those cases, the proxy component is installed silently or deceptively, with no meaningful user consent at all.<h2>Why the "consent" is rarely meaningful</h2>Even when consent technically exists, it is often not the kind of consent most people would recognize.The disclosure may be buried in a long terms-of-service document. The wording may be vague, with phrases such as “share your unused bandwidth,” “support the app,” or “join our network.” These phrases do not clearly tell the user that arbitrary third parties may route traffic through the user’s home IP address.There is also the question of downstream use. Users are rarely told who buys access to the network or what those buyers do with it. Their connection could be used for benign market research. It could also be used for scraping, automated account creation, ad fraud, credential stuffing, or phishing infrastructure.The problem gets worse when the proxy component sits inside another app. The host app’s privacy policy may mention a partner SDK by brand name, but that still does not make it clear to a normal user that their device can become a proxy endpoint.Uninstalling the visible app may not always resolve the issue cleanly either, especially when proxy components are installed separately or bundled with other unwanted software.<h2>The risks consumers actually carry</h2>When a household device becomes a residential proxy node, the user takes on risks created by someone else’s traffic.The first risk is attribution. Abusive, fraudulent, or illegal activity routed through the device appears to come from the household’s IP address. ISP abuse notices, platform bans, fraud checks, and law enforcement requests point first to the subscriber, not to the person who bought the proxy traffic.The second risk is performance. Continuous third-party traffic can consume bandwidth, slow the home network, hit data caps, or violate ISP terms of service. The user may only notice that the internet feels slower, a bill is higher, or a service suddenly blocks access.The third risk is security exposure. Proxy clients run persistent background processes and maintain network connections so they can relay traffic. That adds always-on networking software to the device, often with limited visibility for the user.The fourth risk is reputation. A home IP address used for abuse can end up on blocklists used by banks, retailers, streaming services, and online platforms. The result can be account friction, failed logins, extra verification steps, or outright blocking from services the household actually uses.There is also a family angle. A child or another household member may install a free game, VPN, or utility without understanding the consequences. The legal, financial, and reputational risk still lands on the account holder.<h2>What our telemetry shows</h2>Since the beginning of 2026, we have detected 7.4 million malicious traffic incidents associated with residential proxy traffic, affecting 572,000 unique users in our user base.&nbsp; This is not a measurement of the entire residential proxy market. It reflects what we observe in our telemetry: malicious traffic, detections, and related activity affecting protected users. The real footprint is far larger, because residential proxy networks span major consumer platforms and many devices outside our visibility.The activity is global, but it is concentrated in a smaller set of countries. India leads by a wide margin, with roughly 83,000 affected users, followed by Vietnam with 61,000 and Brazil with 39,000. The Philippines (23,000), Poland (18,000), Indonesia (18,000) and Thailand (14,000) form a second tier, with Egypt, Spain, Ukraine, Argentina, Mexico and Italy each accounting for 10,000 to 13,000. The spread across South and Southeast Asia, Latin America, and Eastern and Southern Europe reflects where the host apps that carry this software are most widely installed.That geographic spread likely reflects a combination of app distribution, local install patterns, user appetite for free or pay-for-bandwidth apps, and the economics of bandwidth resale. It should not be read as a simple ranking of where residential proxy abuse originates.The chart below breaks down the threats we observed in this proxy-related traffic. Two categories dominate: phishing and malicious advertising. Behind them sits a long tail of consumer-facing fraud, including e-shop scams, generic scams, financial scams, and fake-tutorial pages, alongside outright malware such as trojans and other malicious traffic.&nbsp;

In the malicious proxy traffic we observed, scams and malware dominate. The important point for consumers is not only that their connection may be used by someone else. It is that, when abuse happens, their household IP address can be the return address.<h2>What consumers can do</h2>Most people will not identify a residential proxy component by name. But there are practical warning signs.Review “free” VPNs, proxy apps, bandwidth-sharing apps, and utilities from unknown publishers. Check whether they mention bandwidth sharing, peer-to-peer networking, traffic routing, or network participation in their terms. If an app offers payment for leaving your device online, assume your connection may be resold unless the provider explains exactly how traffic is vetted and who can buy access.On phones and computers, remove apps you do not recognize or no longer use. On home routers, check the list of connected devices and look for anything unfamiliar. If your ISP sends abuse notices, websites start blocking you, or your home IP address suddenly fails fraud checks, a proxy component is one possible explanation.Security software can also help by detecting unwanted proxy clients, bundled components, and related malicious activity. But this should not be a guessing game for consumers. Software that turns a household connection into a commercial exit node should be named clearly and made easy to remove.<h2>The takeaway&nbsp;</h2>With residential proxiesthe user’s connection becomes an infrastructure for someone else’s business.The issue is not that residential proxy technology exists. It has legitimate uses. The issue is whether people know when their devices are part of it, understand what kind of traffic may pass through their connection, and have a real choice to opt out.The fix is not to pretend consumers will read every EULA. This software should be named clearly, shown plainly, and made easy to remove before a household connection becomes someone else’s infrastructure.

Your home connection could be routing traffic for strangers. Here's how residential proxy networks work, how devices get enrolled and what our telemetry reveals about the risks for consumers.

Who's Really Using Your Home Internet Connection?

Malware Researcher

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 

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 

Threat Research Team

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.

Luis Corrons

Posts by Luis Corrons