Search here...
TOP
Cyber Security

HashJack: il simbolo “#” che trasforma un sito legittimo in un’arma

Illustrazione di un simbolo # minaccioso con un piede di porco su sfondo blu, a rappresentare l’attacco HashJack ai browser con assistente AI

Quando tutto sembra “normale” ma “#” ha fatto danno

Schermata di browser con simbolo # e assistente AI, a rappresentare HashJack e l’iniezione di prompt nascosti nell’URL

Quando tutto sembra normale, ma il fragment “#” nell’URL può manipolare l’assistente AI del browser

Immagina questa scena: apri un sito che usi da sempre. Banca, portale fornitori, area clienti, un SaaS “di fiducia”.
Dominio giusto, HTTPS, grafica familiare. Ti rilassi. Sei esattamente dove devi essere, comfort zone, è l’url che ha anche il lucchetto verde, le grafiche sono perfette, non c’è un errore di sintassi eppure…

Chiedi all’assistente AI del browser “riassumimi cosa devo fare qui” oppure “dimmi dove cliccare”. Ed il danno irreparabile è compiuto!

Con HashJack, un attaccante può nascondere istruzioni dentro l’URL dopo il simbolo # e farle elaborare dall’assistente AI come se fossero indicazioni legittime. Il sito resta vero. La pagina resta vera. Ma la risposta dell’AI può essere pilotata, in modo malevolo.

HashJack, spiegato semplice

Mano robotica che preme una tastiera con scritta AI, simbolo di automazioni e rischio di azioni guidate dall’intelligenza artificiale

Quando l’AI passa da “rispondere” ad “agire”, l’impatto di un attacco aumenta: non è  guida operativa ma HashJack

HashJack è una tecnica di indirect prompt injection: non serve compromettere un sito, non serve iniettare codice nella pagina, non serve “sporcare” l’HTML.
Il trucco è infilare comandi nel posto che molti ignorano: la parte dell’URL dopo # (il cosiddetto fragment).

Il punto chiave è questo:

Tutto ciò che sta dopo “#” normalmente non viene inviato al server. Resta nel browser. Quindi spesso non finisce nei log server-side e non passa dalle difese “in rete”. Ma l’assistente AI, quando usa l’URL come contesto, può “leggerlo” lo stesso.

Traduzione per tutti: è un canale nascosto. Invisibile a molti controlli classici. E molto comodo per manipolare un assistente AI.
Quindi dedito a creare danni e a essere un silenzioso attaccante che “ti porta a spasso” senza che tu te ne accorga!

Perché questa cosa fa più paura del phishing classico

Mano davanti a un laptop con icona di assistente AI luminosa, simbolo della fiducia nell’AI che può amplificare il phishing

Quando l’assistente AI sembra “ufficiale” e integrato nel browser, il phishing diventa più credibile e più pericoloso

Il phishing tradizionale ha spesso un difetto evidente: un dominio strano, una pagina finta, un testo mal scritto, una richiesta sospetta. HashJack gioca su qualcosa di più efficace: la fiducia.

  • Sei su un sito vero → ti fidi.
  • L’assistente AI parla con sicurezza → ti fidi di più.
  • L’assistente è “dentro il browser” → lo percepisci come affidabile per definizione.

Questo è il concetto che terrorizza (giustamente) i team security: weaponized trust.
Non ti bucano il sito, ti bucano il cervello. Con gentilezza.

Cosa può succedere davvero

Scenario 1: phishing “guidato” dall’AI

L’assistente può essere indotto a suggerire un link o una procedura “di verifica” che sembra coerente col contesto. Non è il classico “clicca qui o muori”: è una truffa con tono rassicurante e istruzioni passo-passo.
Risultato: tasso di successo più alto, perché l’utente sente di essere “assistito”.

Scenario 2: furto o leakage di dati (peggio con funzioni agentiche)

Quando il browser/assistente ha capacità più “agentiche” (azioni, automazioni, interazioni), il rischio aumenta: l’attaccante può tentare di spingere l’assistente a far compiere azioni rischiose o a facilitare l’uscita di informazioni.
Anche senza “magia”: spesso basta convincere l’utente a copiare/incollare dati o a seguire un flusso sbagliato.

Scenario 3: disinformazione operativa che fa danni reali

Un assistente AI manipolato può dare istruzioni errate su procedure IT, pagamenti, policy, configurazioni. E sì: in alcuni casi estremi può anche fornire consigli pericolosi (per esempio su dosaggi o decisioni delicate). Non serve arrivare al film horror: basta un singolo suggerimento sbagliato nel momento sbagliato per creare un incidente serio.

“Ma le difese aziendali?” Qui arriva la parte scomoda

Molte difese tradizionali sono costruite per intercettare ciò che passa dal network o che arriva al server. HashJack sfrutta un dettaglio del web che spesso resta lato client, quindi:

  • il server può non registrare quel frammento dell’URL,
  • il proxy/WAF/IDS può non avere visibilità utile,
  • la pagina può rimanere intatta e “pulita”.

Morale: se in azienda stai adottando browser con assistenti AI, devi ragionare su un nuovo perimetro: sito + browser + assistente AI.

Chi è coinvolto e perché interessa a tutti

I ricercatori hanno discusso il rischio in relazione ad assistenti integrati nei browser e a browser “AI-first”, citando casi d’uso su prodotti noti (assistenti in Edge/Chrome e browser agentici come Comet).
La cosa importante, al di là del nome del prodotto, è questa: quando un assistente AI prende contesto da elementi non fidati (anche se su domini fidati), può essere manipolato.

La risposta dei vendor non è stata uniforme: alcuni hanno introdotto mitigazioni, altri hanno valutato il comportamento come “atteso” o a bassa gravità. Risultato pratico: non puoi basarti solo sull’idea “tanto lo patchano”. Devi gestire il rischio lato organizzazione.

Come difendersi subito

Scudo digitale su circuito blu, simbolo di sicurezza informatica e contromisure contro attacchi ai browser con assistente AI

Difese multilivello: quando le protezioni classiche non bastano, serve controllo su browser, assistenti AI e flussi di dati

4 regole salva-pelle

  • Non usare l’assistente AI del browser per operazioni sensibili: banking, pagamenti, HR, legal, portali clienti, pannelli admin.
  • Se l’AI propone un link o un’azione “urgente”, rallenta. L’urgenza è quasi sempre un trucco.
  • Se un link ha un “#” con una parte lunga e strana, diffida. Non è prova di attacco, ma è un campanello.
  • Regola d’oro: l’AI è un interprete, non un’autorità. Può essere ingannata.

Governance prima della tragedia

  • Definisci dove l’AI nel browser è consentita e dove è vietata (finance/HR/legal/SOC: di solito “vietato o super-limitato”).
  • Standardizza browser e configurazioni: meno “ognuno fa come vuole”, più controllo.
  • Fai awareness mirata con una frase che si ricorda: “Sito vero ≠ risposta AI vera.”

Controlli tecnici che contano davvero

  • Sanitizzazione dell’input: se l’URL viene passato al modello come contesto, il fragment “#…” va trattato come untrusted (idealmente: rimosso o neutralizzato).
  • Action gating: se l’assistente può fare azioni (click, compilazioni, invii), servono barriere: conferma esplicita, allowlist domini, motivazione leggibile.
  • Egress control e DLP: se lo strumento può far uscire dati, devi governare dove possono andare e cosa può uscire.
  • Telemetria endpoint/browser: se il payload non lo vedi in rete, lo devi vedere sul client.

Takeaway aziendale

  • Quando nel browser entra un assistente AI, non è più solo “navigazione”: è un nuovo canale che può essere sfruttato per ingannare le persone.

  • HashJack sfrutta una parte dell’URL (quella dopo #) che spesso non finisce nei log del sito: quindi molte difese classiche non la vedono.

  • Serve una regola aziendale chiara: dove si può usare l’AI nel browser e dove è vietata (pagamenti, HR, legal, portali clienti, admin).

  • Serve mettere barriere tecniche: ripulire ciò che l’AI legge, bloccare azioni automatiche, e controllare eventuali “uscite” di dati verso l’esterno.

  • Da oggi nel risk register aggiungi un asset nuovo: browser + assistente AI, perché il rischio non è solo il sito, è come l’AI guida le decisioni dell’utente.

Botta e risposta

HashJack compromette il sito?

No. Il sito può essere legittimo. Il problema è che un link può contenere istruzioni nel fragment “#” e un assistente AI può interpretarle come contesto/indicazioni.

Perché i controlli classici lo vedono poco?

Perché il fragment dopo “#” è gestito lato client e spesso non viene inviato al server: quindi la visibilità “server-side” e “network-based” può essere limitata.

Devo disattivare tutti gli assistenti AI in azienda?

Non necessariamente. Ma devi governarli: niente AI nei flussi sensibili e niente funzioni agentiche senza barriere, conferme e controlli.

Qual è la contromisura più efficace?

Ridurre l’esposizione con policy e impedire che input non fidati entrino nel contesto del modello: sanitizzazione del fragment, action gating, e controlli di uscita dati.

Fonti 
Cato CTRL (Cato Networks) – HashJack: First Known Indirect Prompt Injection
F5 Labs – HashJack Attack Targets AI Browsers and Agentic AI Systems

CSO Online – AI browsers tricked via URL fragments
Help Net Security – HashJack hijack AI assistants
The Register – HashJack e AI browser assistants 
Infosecurity Magazine – HashJack Indirect Prompt Injection


«

»