Apr 29, 2026 Giancarlo Calzetta Approfondimenti, Attacchi, In evidenza, News, RSS, Scenario, Scenario, Tecnologia, Tecnologia 0

---

Stanno arrivando, ma non nascono già pronti. Stiamo parlando degli agenti AI progettati per compiere attacchi informatici. Sebbene si legga in giro che sono già in uso e sembri una tragedia, la realtà è che la tragedia deve ancora arrivare. Al momento gli attacchi basati su agenti AI sono all’inizio della loro carriera e vengono rintuzzati abbastanza facilmente. In futuro, però, non sarà così e allora sia la benvenuta una ricerca pubblicata da Cisco Talos Intelligence Group  che mostra come la stessa AI possa essere utilizzata per ribaltare completamente il paradigma difensivo, trasformando i sistemi vulnerabili in trappole intelligenti. Il concetto alla base è tanto semplice quanto interessante: utilizzare modelli generativi per creare honeypot capaci non solo di simulare vulnerabilità, ma di interagire dinamicamente con gli attaccanti, adattandosi al loro comportamento in tempo reale.

Dalla difesa passiva alla deception attiva

Gli honeypot non sono certo una novità. Da anni vengono utilizzati per attirare attaccanti e studiarne le tecniche, ma tradizionalmente si tratta di sistemi statici, limitati nella loro capacità di simulare ambienti reali. La ricerca di Talos introduce un cambio di paradigma: grazie all’AI, gli honeypot diventano sistemi dinamici in grado di mascherarsi come infrastrutture vulnerabili credibili e interagire con l’attaccante in modo realistico.

Il risultato è un livello di inganno molto più sofisticato. L’attaccante non si trova più davanti un sistema “finto” facilmente riconoscibile, ma un ambiente che reagisce, risponde e si evolve. L’architettura descritta da Talos si basa su tre componenti chiave, che insieme costruiscono un sistema di difesa completamente nuovo.

Il primo elemento è un listener di rete che accetta connessioni e simula la presenza di un servizio vulnerabile. Il secondo è una vulnerabilità “pilotata”, progettata per concedere accesso controllato all’attaccante e mantenerlo all’interno dell’ambiente di analisi. Il terzo, e più innovativo, è il layer di intelligenza artificiale, che interpreta le azioni dell’attaccante e genera risposte coerenti, mantenendo viva l’illusione.

Questo approccio consente di creare sistemi altamente scalabili. A differenza degli honeypot tradizionali, che richiedono configurazioni manuali complesse, quelli basati su AI possono essere distribuiti rapidamente e replicati su larga scala, adattandosi automaticamente ai diversi scenari di attacco.

Il bersaglio sono gli agenti AI malevoli

Uno degli aspetti più interessanti della ricerca riguarda il target di queste trappole: non tanto gli hacker umani, quanto gli agenti autonomi basati su modelli linguistici. Questi agenti, sempre più diffusi, sono progettati per automatizzare attività offensive come la scansione delle vulnerabilità, l’esecuzione di exploit e la raccolta di informazioni. Il problema è che operano con una velocità e una scala difficili da gestire con i sistemi di difesa tradizionali.

Gli honeypot AI-driven permettono invece di intercettare questi agenti, studiarne il comportamento e raccogliere intelligence in tempo reale, offrendo una visibilità senza precedenti su una nuova classe di minacce emergenti.

Il valore principale di questi sistemi non è, infatti, solo difensivo, ma soprattutto analitico. Interagendo con gli attaccanti, gli honeypot intelligenti consentono di raccogliere informazioni dettagliate sulle tecniche utilizzate, sugli strumenti impiegati e sulle logiche decisionali degli agenti AI.

Il rischio della “gamification” della difesa

L’adozione di AI anche lato difesa apre però scenari complessi. Se da un lato gli honeypot intelligenti consentono di ingannare gli attaccanti, dall’altro introducono una dinamica di escalation tecnologica. Gli attaccanti potrebbero a loro volta migliorare i propri agenti per riconoscere e aggirare queste trappole, dando vita a una sorta di “corsa agli armamenti” tra AI difensive e offensive.

Questo porta a un punto chiave: la sicurezza informatica sta evolvendo verso un modello in cui macchine attaccano macchine e altre macchine cercano di ingannarle. Per le organizzazioni, questo scenario implica un cambiamento profondo nell’approccio alla sicurezza. Non è più sufficiente proteggere i perimetri tradizionali o monitorare eventi sospetti. Serve una strategia capace di affrontare minacce automatizzate, veloci e adattive.

Gli honeypot basati su AI rappresentano una possibile risposta, perché permettono di trasformare l’infrastruttura da bersaglio passivo a sistema attivo di difesa e intelligence. Tuttavia, la loro efficacia dipenderà dalla capacità di integrarli in architetture più ampie, che includano detection avanzata, risposta automatizzata e analisi comportamentale.

---

---

---

https://www.securityinfo.it/2026/04/29/honeypot-intelligenti-come-lai-viene-usata-per-ingannare-gli-attaccanti-automatizzati/?utm_source=rss&utm_medium=rss&utm_campaign=honeypot-intelligenti-come-lai-viene-usata-per-ingannare-gli-attaccanti-automatizzati

Welcome to the week’s Pulse: updates affect how deep links appear in your snippets, how your robots.txt gets parsed, how agentic features work in Search, and how the EU’s data-sharing rules apply to AI chatbots.

Here’s what matters for you and your work.

Google Lists Best Practices For Read More Deep Links

Google updated its snippet documentation with a new section on “Read more” deep links in Search results. The documentation lists three best practices that can increase the likelihood of these links appearing.

Key facts: Content must be immediately visible to a human on page load, and content hidden behind expandable sections or tabbed interfaces can reduce the likelihood of these links appearing. Sections should use H2 or H3 headings. The snippet text needs to match the content that appears on the page, and pages with content loaded after scrolling or interaction may further reduce the likelihood.

Why This Matters

The three practices are the first specific guidance Google has published on this feature. Sites using expandable FAQ sections, tabbed product detail areas, or scroll-triggered content for core information may see fewer deep links in their snippets compared with sites that render the same content on page load.

The guidance matches a pattern Google has applied to other Search features. Content that renders without user interaction is more likely to appear in enhanced display.

Slobodan Manić, founder of No Hacks, made a related observation on LinkedIn:

“The documentation is framed around one snippet behavior (read more deep links in search results), but the language Google chose reads as a general preference. ‘Content immediately visible to a human’ is the structural instruction, not a read-more-specific tip.”

Manić’s point extends his April 16 IMHO interview with Managing Editor Shelley Walsh, where he argued that most websites are structurally broken for AI agents. He argues that search crawlers and AI agents now face the same structural problem, and the audit is the same for both.

For existing pages, the audit question is whether key information is contained within a click-to-expand element. If a page already has a “Read more” deep link for one section, that section’s structure serves as a guide to what works. For other sections on the same page, replicating that structure may also improve their chances.

Google describes the guidance as best practices that can “increase the likelihood” of deep links appearing. That hedging matters because this is not a list of requirements, and following all three may not guarantee the links appear.

Read our full coverage: Google Lists Best Practices For Read More Deep Links

Google May Expand Its Robots.txt Unsupported Rules List

Google may add rules to its robots.txt documentation based on analysis of real-world data collected through HTTP Archive. Gary Illyes and Martin Splitt described the project on the latest Search Off the Record podcast.

Key facts: Google’s team analyzed the most frequently unsupported rules in robots.txt files across millions of URLs indexed by the HTTP Archive. Illyes said the team plans to document the top 10 to 15 most-used unsupported rules beyond user-agent, allow, disallow, and sitemap. He also said the parser may expand the typos it accepts for disallow, though he did not commit to a timeline or name specific typos.

Why This Matters

If Google documents more unsupported directives, sites using custom or third-party rules will have clearer guidance on what Google ignores.

Anyone maintaining a robots.txt file with rules beyond user-agent, allow, disallow, and sitemap should audit for directives that have never worked for Google. The HTTP Archive data is publicly queryable on BigQuery, so the same distribution Google used is available to anyone who wants to examine it.

The typo tolerance is the more speculative part. Illyes’ phrasing implies that the parser already accepts some misspellings of “disallow,” and more may be honored over time. Audit any spelling variants now and correct them, rather than assuming they will be ignored.

Read our full coverage: Google May Expand Unsupported Robots.txt Rules List

EU Proposes Google Share Search Data With Rivals And AI Chatbots

The European Commission sent preliminary findings proposing that Google share search data with rival search engines across the EU and EEA, including AI chatbots that qualify as online search engines under the DMA. The measures are not yet binding, with a public consultation open until May 1 and a final decision due by July 27.

Key facts: The proposal covers four data categories shared on fair, reasonable, and non-discriminatory terms. The categories are ranking, query, click, and view data. Eligibility extends to AI chatbot providers that meet the DMA’s definition of online search engines. If the Commission maintains eligibility through the final decision, qualifying providers could gain access to anonymized Google Search data under the Commission’s proposed terms.

Why This Matters

This proposal explicitly extends search-engine data-sharing eligibility to AI chatbots under the DMA. If the eligibility survives the consultation, the regulatory category of “search engine” now includes products that most search marketing work has treated as a separate category.

The consequences vary depending on where you operate. For sites optimizing for EU/EEA visibility, the change could broaden the scope of where anonymized search signals flow. AI products competing with Google in that market could use the data to improve their retrieval and ranking systems, which could, in turn, affect which content they cite.

Outside the EU, the direct regulatory effect is zero. The category definition is a different matter. How the Commission draws the line between “AI chatbot” and “AI chatbot that qualifies as a search engine” is likely to be cited in future proceedings.

The eligibility question is the story to watch through May 1. If the Commission narrows the AI chatbot criteria in response to consultation feedback, the implications stay regulatory. If it holds the line, that would set a material precedent for how AI search is classified.

Read our full coverage: Google May Have To Share Search Data With Rivals

Google Adds New Task-Based Search Features

Google introduced new Search features that continue its evolution toward task completion. Users can now track individual hotel price drops via a new toggle in Search, and Google is adding the ability to launch AI agents directly from AI Mode.

Key facts: Hotel price tracking is available globally through a toggle in the search bar. When prices drop for a tracked hotel, Google sends an email alert. The AI agent launched from AI Mode allows users to initiate tasks handled by AI within the search interface. Rose Yao, a Google Search product leader, posted about the features on X.

Why This Matters

Each task-based feature moves a process that previously started on another site into Google’s own surface. Hotel price tracking has existed at the city level for months. Expansion to individual hotels adds a new signal that users can set inside Google rather than on hotel or aggregator sites.

Direct-booking visibility depends on being inside Google’s ecosystem. Sites relying on price-drop alerts as a return-trigger for users may see some of that engagement reallocated to Google’s tracking UI. For hotel brands, this raises the stakes for ensuring individual hotel pages are fully populated in Google Business Profile and hotel feeds.

On LinkedIn, Daniel Foley Carter connected the feature to a broader pattern:

“Google’s AI overviews, AI mode and now in-frame functionality for SERP + SITE is just Google eating more and more into traffic opportunities. Everything Google told US not to do its doing itself. SPAM / LOW VALUE CONTENT – don’t resummarise other peoples content – Google does it.”

The AI agent launch is more speculative. Google has not published detailed documentation explaining what kinds of tasks users can delegate or how sources get cited. The feature confirms that agentic search, described by Sundar Pichai as “search as an agent manager,” is appearing incrementally in Search rather than as a single launch.

Read Roger Montti’s full coverage: Google Adds New Tasked-Based Search Features

Theme Of The Week: The Rules Are Getting Written

Each story this week spells out something that was previously implicit or underway.

Google signaled plans to expand what its robots.txt documentation covers. The company listed specific practices that can increase the likelihood of “Read more” deep links appearing. The European Commission proposed measures that extend search-engine data-sharing eligibility to AI chatbots under the DMA. And task-based features that Sundar Pichai described in interviews are rolling out as toggles in the search bar.

For your day-to-day, the ground gets firmer. Fewer questions are judgment calls. What does and doesn’t qualify, what Google supports, and what counts as a search engine to a regulator are all getting written down. That works to your advantage when it means clearer audit criteria, and against you when “we weren’t sure” is no longer a defensible answer.

Top Stories Of The Week:

More Resources:

---

Featured Image: [Photographer]/Shutterstock

https://www.searchenginejournal.com/seo-pulse-googles-robots-txt-docs-expand-deep-links-get-rules-eu-steps-in/572877/

Google updated their spam reporting documentation to make it clearer that spam reports are not wholly confidential and that it’s possible for personal identifiable information to be shared with the sites receiving a manual action.

Change In Response To Feedback

Google’s changelog noted that they were updating the spam reporting form based on feedback they’d received about personal information contained in the spam report that is shared with spammy sites that receive a manual action (formerly known as a penalty).

The update contains a new notice that spam reports containing personal information will not be processed.

The changelog noted:

“Clarifying when and why we may take manual action based on spam reports
What: Further clarified when and why we may take manual action based on spam reports.
Why: To address feedback we received about the change on using spam reports to take manual action.”

Google removed the following from their documentation:

“If we issue a manual action, we send whatever you write in the submission report verbatim to the site owner to help them understand the context of the manual action. We don’t include any other identifying information when we notify the site owner; as long as you avoid including personal information in the open text field, the report remains anonymous.”

The above wording was replaced with the following:

“Don’t include any personally identifying information in your submission. To comply with regulations, we must send the submission text to the site owner to help them understand the context of a manual action, if one is issued.

Because of this, we won’t process your submission if we determine it contains personally identifying information to protect privacy. Not including such information fully ensures your information is safe and prevents your submission from being discarded.”

Action Moving Forward

On the one hand it’s good that Google won’t proceed with a manual action if the report contains personal information. This means that if you’re submitting spam reports to Google, don’t name your site, business name, personal name or anything else that you don’t want the affected spammer to know.

Read the updated documentation here:

Report spam, phishing, or malware

Learn more about Google’s spam reporting tool: Google Just Made It Easy For SEOs To Kick Out Spammy Sites

Featured Image by Shutterstock/andre_dechapelle

https://www.searchenginejournal.com/google-wont-act-on-spam-reports-if-they-contain-personal-information/572929/

Google may expand the list of unsupported robots.txt rules in its documentation based on analysis of real-world robots.txt data collected through HTTP Archive.

Gary Illyes and Martin Splitt described the project on the latest episode of Search Off the Record. The work started after a community member submitted a pull request to Google’s robots.txt repository proposing two new tags be added to the unsupported list.

Illyes explained why the team broadened the scope beyond the two tags in the PR:

“We tried to not do things arbitrarily, but rather collect data.”

Rather than add only the two tags proposed, the team decided to look at the top 10 or 15 most-used unsupported rules. Illyes said the goal was “a decent starting point, a decent baseline” for documenting the most common unsupported tags in the wild.

How The Research Worked

The team used HTTP Archive to study what rules websites use in their robots.txt files. HTTP Archive runs monthly crawls across millions of URLs using WebPageTest and stores the results in Google BigQuery.

The first attempt hit a wall. The team “quickly figured out that no one is actually requesting robots.txt files” during the default crawl, meaning the HTTP Archive datasets don’t typically include robots.txt content.

After consulting with Barry Pollard and the HTTP Archive community, the team wrote a custom JavaScript parser that extracts robots.txt rules line by line. The custom metric was merged before the February crawl, and the resulting data is now available in the custom_metrics dataset in BigQuery.

What The Data Shows

The parser extracted every line that matched a field-colon-value pattern. Illyes described the resulting distribution:

“After allow and disallow and user agent, the drop is extremely drastic.”

Beyond those three fields, rule usage falls into a long tail of less common directives, plus junk data from broken files that return HTML instead of plain text.

Google currently supports four fields in robots.txt. Those fields are user-agent, allow, disallow, and sitemap. The documentation says other fields “aren’t supported” without listing which unsupported fields are most common in the wild.

Google has clarified that unsupported fields are ignored. The current project extends that work by identifying specific rules Google plans to document.

The top 10 to 15 most-used rules beyond the four supported fields are expected to be added to Google’s unsupported rules list. Illyes did not name specific rules that would be included.

Typo Tolerance May Expand

Illyes said the analysis also surfaced common misspellings of the disallow rule:

“I’m probably going to expand the typos that we accept.”

His phrasing implies the parser already accepts some misspellings. Illyes didn’t commit to a timeline or name specific typos.

Why This Matters

Search Console already surfaces some unrecognized robots.txt tags. If Google documents more unsupported directives, that could make its public documentation more closely reflect the unrecognized tags people already see surfaced in Search Console.

Looking Ahead

The planned update would affect Google’s public documentation and how disallow typos are handled. Anyone maintaining a robots.txt file with rules beyond user-agent, allow, disallow, and sitemap should audit for directives that have never worked for Google.

The HTTP Archive data is publicly queryable on BigQuery for anyone who wants to examine the distribution directly.

---

Featured Image: Screenshot from: YouTube.com/GoogleSearchCentral, April 2026. 

https://www.searchenginejournal.com/google-may-expand-unsupported-robots-txt-rules-list/572866/

OpenAI’s public crawler documentation now lists OAI-AdsBot, a bot that may visit pages submitted as ChatGPT ads to check policy compliance and help determine ad relevance.

The entry sits alongside OAI-SearchBot, GPTBot, and ChatGPT-User on OpenAI’s crawler docs page, bringing the documented bot count to four.

OpenAI states that OAI-AdsBot only visits pages submitted as ads and that the data it collects isn’t used to train its generative AI foundation models.

What The Bot Does

Per OpenAI’s docs, OAI-AdsBot may visit an ad’s landing page after the ad gets submitted. The bot checks whether the page complies with OpenAI’s ad policies. It may also use content from the landing page to help decide when to show the ad to ChatGPT users.

The bot identifies itself with the user-agent string Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; OAI-AdsBot/1.0; +https://openai.com/adsbot.

OAI-SearchBot and GPTBot are both at version 1.3, per OpenAI’s docs. The crawler only visits pages submitted as ad landing pages, not the wider web.

What The Bot Doesn’t Do

Data collected by OAI-AdsBot isn’t used to train generative AI foundation models. That keeps OAI-AdsBot out of GPTBot’s territory, which handles training data collection.

It also keeps OAI-AdsBot separate from OpenAI’s other bots. OAI-SearchBot surfaces content in ChatGPT search, while ChatGPT-User fetches pages during user-initiated browsing, and OAI-AdsBot is limited to ad validation.

OAI-SearchBot and GPTBot can be controlled independently through robots.txt. ChatGPT-User is user-initiated, and the company notes that robots.txt rules may not apply to it. The OAI-AdsBot entry doesn’t say how the bot treats robots.txt.

No Public IP List Yet

OpenAI publishes IP range files for its three earlier bots at openai.com/searchbot.json, openai.com/gptbot.json, and openai.com/chatgpt-user.json. At the time of publication, no equivalent openai.com/adsbot.json file appears in OpenAI’s docs.

Without a published list, verifying a real OAI-AdsBot visit becomes harder. User-agent strings can be spoofed, and the IP lists give you a way to cross-check for the other three OpenAI bots. For OAI-AdsBot, that cross-check isn’t available.

Why This Matters

OAI-AdsBot has two audiences. Advertisers buying placements on ChatGPT need the bot to reach their landing pages; otherwise, the ad may not validate. Anyone tracking AI bot activity in server logs gets a new user-agent to watch, one tied to paid inventory rather than search or training.

Aggressive bot protection through Cloudflare, Akamai, or similar tools may block OAI-AdsBot before it reaches the page. That could create validation friction for advertisers who use strict bot-mitigation tools.

Looking Ahead

ChatGPT’s ad program has moved fast since OpenAI started testing ads on Feb. 9. As access opens up to more advertisers, OAI-AdsBot traffic will start showing up in more server logs. Watch for an eventual IP range file at openai.com/adsbot.json if OpenAI chooses to publish one. For now, the user-agent string is what you have to work with.

---

Featured Image: Blossom Stock Studio/Shutterstock

https://www.searchenginejournal.com/openais-crawler-docs-now-list-oai-adsbot-for-chatgpt-ads/572861/

Google announced two updates to Demand Gen ahead of Google Marketing Live.

View-through conversion (VTC) optimization is now available for Demand Gen campaigns in Google Ads. This setting lets campaigns optimize toward view-through conversions on YouTube.

Google is also expanding Commerce Media Suite to support Demand Gen inventory in Google Ads. This adds Google Ads to existing Commerce Media Suite support in Display & Video 360 and Search Ads 360.

What’s New

VTC Optimization

When enabled, VTC optimization lets Demand Gen campaigns optimize toward view-through conversions on YouTube. A view-through conversion happens when a user sees an ad, doesn’t click, but later converts.

Commerce Media Suite

With the Google Ads expansion, advertisers can use retailers’ first-party catalog and conversion data to reach shoppers. Inventory covers YouTube, Discover, and Gmail.

The Performance Claim

In the announcement, Google cited Fospha’s Demand Gen and YouTube Playbook, a third-party vendor report. Fospha attributes an 18% higher share of new-customer conversions to Demand Gen versus the paid media average. Coverage spans 127 retail brands across fashion, cosmetics, and consumer goods from 2024 to 2025.

Fospha is a marketing attribution vendor with a commercial interest in measurement across advertising platforms. Google didn’t publish its own performance data alongside the announcement.

Why This Matters

VTC optimization brings Demand Gen closer to the capabilities advertisers already use on other ad platforms. For teams running Demand Gen alongside video campaigns on those platforms, the optimization setup no longer has to differ by channel.

The Commerce Media Suite expansion gives Google Ads advertisers access to retailer first-party catalog and conversion data. This adds Google Ads to existing Commerce Media Suite support in Display & Video 360 and Search Ads 360.

Since last year, Google has added Demand Gen optimization levers, including in-store sales optimization and shoppable CTV. VTC optimization and Commerce Media Suite support continue that pattern.

Looking Ahead

This announcement lands ahead of Google Marketing Live, where Google says more Demand Gen solutions will follow.

https://www.searchenginejournal.com/google-adds-view-through-conversion-optimization-to-demand-gen/572840/

Apr 23, 2026 Giancarlo Calzetta Approfondimenti, Attacchi, Attacchi, In evidenza, News, RSS 0

---

Vi ricordate il vecchio adagio “cambia la password almeno ogni sei mesi”? Ecco, da tempo ormai questa prassi e diventata tra quelle sconsigliate da molti esperti, ma resta ancora in auge in alcuni ambienti, tanto che, secondo le analisi di Forrester, ogni reset di password può costare fino a 70 dollari all’azienda del dipendente che deve effettuarlo. Un dato che, da solo, racconta quanto questa attività sia diffusa e strutturalmente rilevante nei processi IT aziendali. Non sorprende quindi che molte organizzazioni abbiano introdotto strumenti di self-service password reset (SSPR), nel tentativo di alleggerire il carico sugli helpdesk. Purtroppo, il numero di richieste gestite manualmente resta elevato, tra onboarding agli strumenti self-service ed eccezioni operative. Inoltre, questa apparente banalità operativa nasconde però un problema molto più profondo: il reset password è uno dei punti di ingresso più sfruttati dagli attaccanti, perché consente di aggirare controlli anche avanzati come la multi-factor authentication.

Quando un reset apre la porta all’attacco

Il motivo è semplice: se un attaccante riesce a convincere un operatore a resettare una password, ottiene credenziali legittime. A quel punto, non è più necessario sfruttare vulnerabilità tecniche, perché l’accesso avviene attraverso canali perfettamente validi.

Un esempio concreto arriva dall’attacco del 2025 contro il retailer britannico Marks & Spencer. L’incidente ha avuto un impatto devastante, con la sospensione delle vendite online per cinque giorni e perdite stimate in circa 3,8 milioni di sterline al giorno.

Secondo le ricostruzioni, il gruppo Scattered Spider avrebbe ottenuto l’accesso iniziale impersonando un dipendente e contattando un service desk esterno. Un semplice reset di password ha fornito agli attaccanti credenziali valide, eliminando la necessità di qualsiasi exploit.

Dal primo accesso al dominio completo

Una volta entrati, gli attaccanti hanno sfruttato Active Directory per estrarre il file NTDS.dit, che contiene gli hash delle password di tutti gli utenti di dominio. Attraverso tecniche di cracking offline, è stato possibile recuperare ulteriori credenziali.

A quel punto, l’attacco si è trasformato in un’escalation silenziosa: movimenti laterali, utilizzo di strumenti legittimi e accessi apparentemente normali hanno consentito di espandere progressivamente il perimetro compromesso.

Quando il livello di accesso è diventato sufficiente, è entrato in gioco il ransomware, con la cifratura dei sistemi critici per pagamenti, e-commerce e logistica. Il risultato è stato un blocco operativo su larga scala, con impatti diretti su clienti e transazioni.

Il service desk come superficie d’attacco

Gli attacchi di social engineering di questo tipo sono particolarmente insidiosi perché non presentano indicatori evidenti di compromissione. Dal punto di vista dell’helpdesk, si tratta semplicemente di una richiesta di supporto come tante altre.

Ed è proprio questa normalità a rappresentare il problema: il service desk diventa un punto di accesso privilegiato per gli attaccanti, soprattutto quando i processi di verifica dell’identità si basano su informazioni facilmente reperibili o aggirabili. In assenza di controlli robusti, una richiesta apparentemente innocua può trasformarsi in un incidente critico.

Per ridurre il rischio, è necessario introdurre meccanismi di verifica che non possano essere facilmente replicati o simulati. L’operatore non deve basarsi su dati dichiarativi, ma deve attivare codici temporanei su dispositivi registrati o integrare sistemi di identità esistenti.

Il punto chiave è la standardizzazione: ogni richiesta deve seguire lo stesso processo, senza eccezioni o discrezionalità, eliminando una delle principali leve sfruttate dagli attaccant.

---

---

---

https://www.securityinfo.it/2026/04/23/reset-password-una-misura-di-sicurezza-che-diventa-minaccia/?utm_source=rss&utm_medium=rss&utm_campaign=reset-password-una-misura-di-sicurezza-che-diventa-minaccia

Clicks as a ranking-related signal have been a subject of debate for over twenty years, although nowadays most SEOs understand that clicks are not a direct ranking factor. The simple truth about clicks is that they are raw data and, surprisingly, processed with some similarity to human rater scores.

Clicks Are A Raw Signal

The DOJ Antitrust memorandum opinion from September 2025 mentions clicks as a “raw signal” that Google uses. It also categorizes content and search queries as raw signals. This is important because a raw signal is the lowest-level data point which is processed into higher level ranking signals or used for training a model like RankEmbed and its successor, RankEmbedBERT.

Those are considered raw signals because they are:

• Directly observed
• But not yet interpreted or used for training data

The DOJ document quotes professor James Allan, who gave expert testimony on behalf of Google:

“Signals range in complexity. There are “raw” signals, like the number of clicks, the content of a web page, and the terms within a query.

…These signals can be created with simple methods, such as counting occurrences (e.g., how many times a web page was clicked in response to a particular query). Id.
at 2859:3–2860:21 (Allan) (discussing Navboost signal) “

He then contrasts the raw signals with how they are processed:

“At the other end of the spectrum are innovative deep-learning models, which are machine-learning models that discern complex patterns in large datasets.

Deep models find and exploit patterns in vast data sets. They add unique capabilities at high cost.”

Professor Allan explains that “top-level signals” are used to produce the “final” scores for a web page, including popularity and quality.

Raw Signals Are Data To Be Further Processed

Navboost is mentioned several times in the September 2025 antitrust document as popularity data. It’s not mentioned in the context of clicks having a ranking effect on individal sites.

It’s referred to as a way to measure popularity and intent:

“…popularity as measured by user intent and feedback systems including Navboost/Glue…”

And elsewhere, in the context of explaining why some of the Navboost data is privileged:

“They are ‘popularity as measured by user intent and feedback systems including Navboost/Glue’…”

In the context of explaining why some of the Navboost data is privileged:

“Under the proposed remedy, Google must make available to Qualified Competitors …the following datasets:

1. User-side Data used to build, create, or operate the GLUE statistical model(s);

2. User-side Data used to train, build, or operate the RankEmbed model(s); and

3. The User-side Data used as training data for GenAI Models used in Search or any GenAI Product that can be used to access Search.

Google uses the first two datasets to build search signals and the third to train and refine the models underlying AI Overviews and (arguably) the Gemini app.”

Clicks, like human rater scores, are just a raw signal that is used further up the algorithm chain to train AI models to better able match web pages to queries or to generate a quality or relevance signal that is then added to the rest of the ranking signals by a ranking engine or a rank modifier engine.

70 Days Of Search Logs

The DOJ document makes reference to using 70 days of search logs. But that’s just eleven words in a larger context.

Here is the part that is frequently quoted:

“70 days of search logs plus scores generated by human raters”

I get it, it’s simple and direct. But there is more context to it:

“RankEmbed and its later iteration RankEmbedBERT are ranking models that rely on two main sources of data: [Redacted]% of 70 days of search logs plus scores generated by human raters and used by Google to measure the quality of organic search results.”

The 70 days of search logs are not click data used for ranking purposes in Google, AI Mode, or Gemini. It’s data in aggregate that is further processed in order to train specialized AI models like RankEmbedBERT that in turn rank web pages based on natural language analysis.

That part of the DOJ document does not claim that Google is directly using click data for ranking search results. It’s data, like the human rater data, that’s used by other systems for training data or to be further processed.

What Is Google’s RankEmbed?

RankEmbed is a natural language approach to identifying relevant documents and ranking them.

The same DOJ document explains:

“The RankEmbed model itself is an AI-based, deep-learning system that has strong natural-language understanding. This allows the model to more efficiently identify the best documents to retrieve, even if a query lacks certain terms.”

It’s trained on less data than previous models. The data partially consists of query terms and web page pairs:

“…RankEmbed is trained on 1/100th of the data used to train earlier ranking models yet provides higher quality search results.

…Among the underlying training data is information about the query, including the salient terms that Google has derived from the query, and the resultant web pages.”

That’s training data for training a model to recognize how query terms are relevant to web pages.

The same document explains:

“The data underlying RankEmbed models is a combination of click-and-query data and scoring of web pages by human raters.”

It’s crystal clear that in the context of this specific passage, it’s describing the use of click data (and human rater data) to train AI models, not to directly influence rankings.

What About Google’s Click Ranking Patent?

Way back in 2006 Google filed a patent related to clicks called, Modifying search result ranking based on implicit user feedback. The invention is about the mathematical formula for creating a “measure of relevance” out of the aggregated raw data of clicks (plural).

The patent distinguishes between the creation of the signal and the act of ranking itself. The “measure of relevance” is output to a ranking engine, which then can add it to existing ranking scores to rank search results for new searches.

Here’s what the patent describes:

“A ranking Sub-system can include a rank modifier engine that uses implicit user feedback to cause re-ranking of search results in order to improve the final ranking
presented to a user of an information retrieval system.

User selections of search results (click data) can be tracked and transformed into a click fraction that can be used to re-rank future search results.”

That “click fraction” is a measure of relevance. The invention described in the patent isn’t about tracking the click; it’s about the mathematical measure (the click fraction) that results from combining all those individual clicks together. That includes the Short Click, Medium Click, Long Click, and the Last Click.

Technically, it’s called the LCIC (Long Click divided by Clicks) Fraction. It’s “clicks” plural because it’s making decisions based on the sums of many clicks (aggregate), not the individual click.

That click fraction is an aggregate because:

• Summation:
  The “first number” used for ranking is the sum of all those individual weighted clicks for a specific query-document pair.
• Normalization:
  It takes that sum and divides it by the total count of all clicks (the “second number”).
• Statistical Smoothing:
  The system applies “smoothing factors” to this aggregate number to ensure that a single click on a “rare” query doesn’t unfairly skew the results, especially for spammers.

That 2006 patent describes it’s weighting formula like this:

“A base LCC click fraction can be defined as:

LCC_BASE=[#WC(Q,D)]/[#C(Q,D)+S0)

where iWC(Q.D) is the sum of weighted clicks for a query URL…pair, iC(Q.D) is the total number of clicks (ordinal count, not weighted) for the query-URL pair, and S0 is a smoothing factor.”

That formula describes summing and dividing the data from many users to create a single score for a document. The “query-URL” pair is a “bucket” of data that stores the click behavior of every user who ever typed that specific query and clicked that specific search result. The smoothing factor is the anti-spam part that includes not counting single clicks on rare search queries.

Even way back in 2006, clicks is just raw data that is transformed further up the chain across multiple stages of aggregation, into a statistical measure of relevance before it ever reaches the ranking stage. In this patent, the clicks themselves are not ranking factors that directly influence whether a site is ranked or not. They were used in aggregate as a measure of relevance, which in turn was fed into another engine for ranking.

By the time the information reaches the ranking engine, the raw data has been transformed from individual user actions into an aggregate measure of relevance.

• Thinking about clicks in relation to ranking is not as simple as clicks drive search rankings.
• Clicks are just raw data.
• Clicks are used to train AI systems like RankEmbedBert.
• Clicks are not directly influencing search results. They have always been raw data, the starting point for systems that use the data in aggregate to create a signal that is then mixed into ranking decision making systems at Google.
• So yes, like human rater data, raw data is processed to create a signal or to train AI systems.

Read the DOJ memorandum in PDF form here.

Read about four research papers about CTR.

Read the 2006 Google patent, Modifying search result ranking based on implicit user feedback.

Featured Image by Shutterstock/Carkhe

https://www.searchenginejournal.com/the-facts-about-google-click-signals-rankings-and-seo/572827/

Google’s Large Customer Sales team has posted a role titled “GEO Partner Manager, Performance Solutions” on Google Careers. The listing is a single job posting inside Google’s ads sales organization.

The term “GEO” appears seven times across the listing, including the title. “Generative Engine Optimization” is spelled out twice. Other references include “GEO players,” “GEO ecosystem,” and “GEO/AEO companies.”

The listing says the role will “shape the GEO ecosystem to prioritize Google surfaces.” Responsibilities include influencing partners to prioritize Google-owned surfaces in their tools and methodologies, as well as in “Share of Model” analysis. “Share of Model” is an industry term for a brand’s presence in AI-generated answers.

Why This Matters

The terminology is worth noting because it sits alongside a different public position from Google’s search side. In July, Google’s Gary Illyes said standard SEO is sufficient for AI Overviews and AI Mode, and that specialized AEO or GEO optimization is not needed. As of publication, Google has not publicly updated that guidance.

Large Customer Sales manages relationships with major advertisers and agencies. The role’s alignment with the 3P Measurement team places it firmly inside Google’s ad-side partner work.

Microsoft and Google are in different places here, and the categories of evidence differ. In March, Bing added “GEO” to its official webmaster guidelines, defining the term and placing it alongside SEO as a named category. Bing’s AI Performance dashboard, launched in February, was positioned as a step toward GEO tooling.

The Google listing is one job posting inside an ads sales team. Both are adoption signals, but not the same level of commitment.

Looking Ahead

The language reflects how one team inside Google’s ads organization frames this work today. It doesn’t carry the same weight as a documentation update, a public statement from Google Search, or a policy change.

Whether similar GEO language appears in other Google job listings across Ads, Cloud, or Search would indicate whether this is a pattern or a single team’s choice.

For brands working with GEO or AEO partners, the listing is worth noting. The listing indicates Google’s ads team wants partner tools and methodologies to prioritize Google surfaces.

---

Featured Image: Jack_the_sparow/Shutterstock

https://www.searchenginejournal.com/google-ads-posts-geo-partner-manager-role/572741/

Apr 22, 2026 Redazione Attacchi, In evidenza, News, RSS, Tecnologia 0

---

Kyber è un gruppo ransomware relativamente recente che ha attirato un po’ di attenzione su di sé per le ultime operazioni condotte e una postura piuttosto esibizionista nel dark Web. Questa settimana, ha pubblicato un post a proposito di un attacco riuscito usando un sistema di cifratura post-quantum per bloccare i dati della vittima.  Dietro la narrativa tecnologica avanzata si nasconde, però, una realtà più complessa, in cui marketing criminale e implementazione tecnica non sempre coincidono.

Secondo l’analisi pubblicata da Rapid7, la gang ha sviluppato due varianti distinte del ransomware, entrambe utilizzate nello stesso attacco per massimizzare l’impatto su infrastrutture eterogenee.

Attacchi coordinati tra Windows e VMware ESXi

La strategia operativa di Kyber è ben precisa: colpire simultaneamente ambienti virtualizzati e server tradizionali, ogni ambiente con una versione dedicata del malware. Le due varianti analizzate condividono infatti lo stesso campaign ID e la stessa infrastruttura di pagamento basata su Tor, suggerendo l’azione di un unico affiliato.

Ci sono, però, differenze evidenti tra le due. La variante dedicata a VMware ESXi è progettata per ambienti virtualizzati enterprise, dove può censire tutte le macchine virtuali, cifrare i datastore e modificare le interfacce di gestione con messaggi di riscatto, guidando le vittime nel processo di pagamento.

Parallelamente, la versione Windows — sviluppata in Rust — prende di mira i file server e introduce anche funzionalità sperimentali per interagire con ambienti Hyper-V, ampliando ulteriormente la superficie d’attacco.

Il “falso” post-quantum e la realtà crittografica

Il punto più interessante di tutta la vicenda riguarda la presunta adozione di crittografia post-quantum. La gang pubblicizza l’uso di Kyber1024, un algoritmo di key encapsulation appartenente alla famiglia delle tecnologie post-quantum. Tuttavia, l’analisi tecnica rivela una situazione diversa. Nella variante Linux/ESXi, il post-quantum non è realmente utilizzato perché il ransomware impiega ChaCha8 per la cifratura dei file e RSA-4096 per la protezione delle chiavi, seguendo schemi già consolidati nel panorama ransomware.

Diverso il caso della variante Windows, dove Kyber1024 viene effettivamente implementato — ma con un ruolo limitato. Come chiarisce Rapid7, Kyber non cifra direttamente i dati, ma protegge le chiavi simmetriche utilizzate da algoritmi tradizionali come AES-CTR.

Il risultato è che l’introduzione del post-quantum non cambia l’impatto operativo dell’attacco. Senza la chiave privata degli attaccanti, i dati restano comunque irrecuperabili, indipendentemente dall’algoritmo utilizzato.

Tecniche di distruzione e anti-recovery sempre più aggressive

La variante Windows appare più evoluta anche per quanto riguarda le tecniche di sabotaggio dei sistemi compromessi. Il malware è progettato per eliminare ogni possibile via di recupero dei dati, attraverso una serie coordinata di azioni.

Tra queste emergono la cancellazione delle shadow copies, la disattivazione dei meccanismi di ripristino, l’interruzione di servizi critici come SQL Server ed Exchange e la rimozione dei backup. Inoltre, il ransomware procede con la pulizia dei log di sistema e del cestino, rendendo più difficile anche l’attività forense post-incidente.

Interessante — e quasi ironico — è la presenza di un mutex che sembra fare riferimento a una canzone sulla piattaforma Boomplay, un dettaglio che suggerisce un certo grado di personalizzazione o “firma” degli sviluppatori.

Resta il fatto che in questa fase Kyber sta facendo più marketing che sfoggio di capacità tecnologiche avanzate. Il motivo non è chiarissimo dal momento che non c’è alcun motivo per un gruppo ransomware di “farsi pubblicità”, ma evidentemente anche l’ego dei criminali vuole la sua parte.

---

---

---

https://www.securityinfo.it/2026/04/22/kyber-annuncia-il-ransomware-post-quantum-ma/?utm_source=rss&utm_medium=rss&utm_campaign=kyber-annuncia-il-ransomware-post-quantum-ma