YOOTA

2026-03-16 15:30:00

DuckDuckGo costruisce il suo indice web: meno Bing, più AI

DuckDuckGo sta costruendo un proprio indice del web. Lo hanno annunciato il fondatore Gabriel Weinberg e il CTO Caine Tighe in un episodio del loro podcast interno, spiegando le ragioni tecniche e strategiche dietro una scelta che arriva quasi vent’anni dopo la nascita del motore di ricerca.

La storia è curiosa: DDG aveva già iniziato a indicizzare il web nei suoi primissimi anni, quando Weinberg lavorava da solo. Poi aveva abbandonato l’idea, preferendo appoggiarsi a indici di terze parti, Bing su tutti, e concentrarsi su quello che aggiungeva valore sopra: risposte istantanee, knowledge graph, ricerca locale. Una scelta pragmatica per una piccola realtà che non poteva permettersi l’infrastruttura di un grande motore di ricerca.

Oggi le cose sono cambiate, e la spinta principale viene dall’intelligenza artificiale. Search Assist, il sistema di risposte automatiche integrato nei risultati di ricerca, e Duck.ai, il chatbot dell’azienda, hanno bisogno di accedere a contenuti web freschi e controllati direttamente. Avere un indice proprio significa poter alimentare questi strumenti senza dipendere da dati di terzi, con un ciclo di feedback molto più stretto: i milioni di utenti che usano DDG ogni giorno diventano, in forma anonimizzata, un segnale continuo sulla qualità dei risultati.

Tighe descrive la pipeline tecnica in modo abbastanza dettagliato: c’è un crawler che rispetta le preferenze dei siti (chi vuole essere indicizzato e chi no), un sistema di rendering che esegue anche il JavaScript delle pagine per estrarne il contenuto reale, e un motore di ricerca semantica basato su embeddings (rappresentazioni matematiche del significato dei testi) che usa un database chiamato Vespa. L’indice è già attivo su una parte del traffico e, secondo quanto dichiarato, sta crescendo giorno per giorno.

Vale la pena notare che questa è comunicazione aziendale e le motivazioni dichiarate sono credibili, ma il fatto che l’AI sia il motore principale della decisione merita una lettura attenta: DDG si è sempre posizionata come alternativa rispettosa della privacy, e costruire un indice proprio per alimentare prodotti AI è una direzione che porta con sé domande legittime su come quei dati vengono usati internamente. Per ora non ci sono ragioni per dubitare della coerenza con la loro politica di non tracciamento, ma è un’evoluzione da seguire.

Chi usa un motore di ricerca che non vuole essere tracciato da Google o Bing, e magari abbina già una VPN come Proton VPN per proteggere il traffico di rete, ha interesse a capire come si muovono i player alternativi. DDG che riduce la dipendenza da Microsoft è, sulla carta, una buona notizia. Quanto questa indipendenza si traduca in qualcosa di concreto per gli utenti lo vedremo nei prossimi mesi e anni.

FONTE insideduckduckgo.substack.com

Duck Tales: Why DuckDuckGo is building its own web search index (Ep.22)

Why are we building our own web search index? And why does it matter?

^{DuckDuckGo (Inside DuckDuckGo)}

(in)sicurezza digitale

2026-03-16 11:38:44

Parliamo del fronte cyber Iran-USA: Handala contro Stryker

E’ da un po’ che non riuscivo a prendere del tempo per aggiornare questo blog e, visti gli avvenimenti che hanno determinato e stanno determinando la sicurezza nelle ultime settimane, riapro con un post sull’Iran.

L’11 marzo 2026 Stryker, uno dei colossi mondiali della tecnologia medicale, ha scoperto cosa significa avere l’intero ambiente Microsoft trasformato in un kill‑switch remoto, azionato da un gruppo hacktivista filo‑iraniano che si firma Handala Hack e che l’intelligence occidentale riconduce alla costellazione iraniana Yellow Phobos / Void Manticore / Red Sandstorm. Nel giro di minuti, migliaia di endpoint aziendali – dai server Windows alle workstation fino agli smartphone con profili corporate – sono stati resettati o wipati, i portali di login hanno iniziato a mostrare il logo di Handala e la supply chain sanitaria globale ha avuto un assaggio molto concreto di cosa significhi un attacco distruttivo contro un fornitore critico.​

La narrazione ufficiale dell’azienda, almeno nelle prime ore, è stata prudente: “network disruption”, incidente circoscritto al “Microsoft environment”, nessuna evidenza pubblica di ransomware o malware tradizionale, nessun riferimento esplicito a wiper nel comunicato ai clienti. Eppure le evidenze raccolte nei report di threat intelligence e le testimonianze interne vanno in tutt’altra direzione, parlando di cancellazione massiva di dati, factory reset orchestrati da remoto e indisponibilità diffusa dei dispositivi in decine di sedi nel mondo. Il punto interessante, per una community nerd e tecnica, non è solo il “chi” ma soprattutto il “come”: invece di far leva su un ennesimo payload custom, Handala avrebbe scelto un approccio quasi “living off the SaaS”, abusando di Microsoft Intune per distribuire comandi di remote wipe perfettamente legittimi ma usati con finalità distruttive.

Per capire perché questo incidente pesa più di altri sul piano strategico bisogna partire dal contesto geopolitico. Handala rivendica l’operazione come ritorsione per l’attacco contro la scuola di Minab in Iran, incastonandola in un ciclo di escalation che vede Stati Uniti e Israele da un lato e Teheran dall’altro, con il cyber come teatro operativo ormai pienamente integrato in quello cinetico. Sullo sfondo c’è il ruolo del Corpo delle Guardie Rivoluzionarie Islamiche (IRGC), che tramite media di Stato come l’agenzia Tasnim ha iniziato a pubblicare liste di “obiettivi legittimi” tra le big tech occidentali, indicando strutture di Google, Microsoft, Nvidia, IBM, Oracle, Palantir e Amazon in Israele e nel Golfo come possibili target di future azioni di “infrastructure warfare”. In questo schema, colpire un fornitore medicale come Stryker non è solo un’operazione di sabotaggio episodica, ma un messaggio: l’Iran‑verse cyber non si limita più a entità governative o utility regionali, può aggredire nodi sistemici della sanità globale e disarticolare la capacità operativa degli ospedali occidentali senza toccare direttamente i loro sistemi clinici.

Dal punto di vista tecnico, il quadro che emerge secondo diverse fonti di cyber intelligence è quello di un’operazione costruita intorno a un wiper, o comunque a un effetto wiper‑like, con un’architettura pensata per massimizzare la distruzione più che l’estorsione. A differenza del classico schema ransomware – cifratura, nota di riscatto, canale di negoziazione – qui il focus è la cancellazione irreversibile dei dati sui sistemi aziendali, l’arresto forzato della produzione, il lock‑out degli utenti dalle applicazioni critiche. Nelle prime ore Stryker ha parlato di impatto confinato all’ecosistema Microsoft, ma i report descrivono un effetto domino su più regioni, dal quartier generale europeo in Irlanda agli stabilimenti di produzione in Nord America e Asia, con shutdown degli ambienti industriali, perdita dei canali di comunicazione interna e cancellazione remota degli endpoint gestiti via MDM.

Il passaggio chiave è il controllo dell’infrastruttura di gestione centralizzata. Yellow Phobos è noto per un modus operandi identity‑centric: phishing mirato, furto di credenziali, abuso di account validi, focus su Microsoft Entra ID e Microsoft 365, e pivot sugli strumenti di orchestrazione come Intune, automazioni Azure o Group Policy per scalare rapidamente i privilegi dentro il tenant. Nel caso Stryker, fonti vicine all’indagine hanno raccontato come il gruppo non avrebbe necessariamente spinto un eseguibile wiper classico, ma sfruttato la console Intune per emettere comandi di remote wipe e factory reset verso qualsiasi dispositivo associato al profilo aziendale, inclusi i telefoni personali BYOD con un work profile. Il risultato è un “wiper as a feature”: invece di un malware che sovrascrive i settori del disco, una tempesta di azioni amministrative legittime ma concatenate per ottenere lo stesso esito, con un livello di tracciabilità e attribuzione ancora più insidioso perché si confonde con l’attività di gestione quotidiana.

Questo approccio è perfettamente coerente con le TTP mappate nel framework MITRE ATT&CK per Handala / Yellow Phobos negli ultimi anni. Sul fronte dell’accesso iniziale, il gruppo ha storicamente combinato spear phishing (T1566) con l’exploitation di servizi esposti (T1190) e il riuso di account validi (T1078), spesso attraverso campagne di brand impersonation che mimano attori fidati come provider di sicurezza o vendor IT per indurre l’utente a consegnare credenziali o token. Una volta dentro, la persistenza passa attraverso l’abuso sistematico di account amministrativi compromessi, l’uso estensivo di interpreter di scripting e strumenti nativi (T1059) e l’escalation via exploitation di vulnerabilità note (T1068), con il movimento laterale orchestrato tramite servizi remoti (T1021) e alternate authentication material (T1550) per attraversare velocemente boundary logici e geografici. L’impatto, come dimostra il caso Stryker, è centrato su data destruction (T1485), endpoint DoS (T1499) e defacement (T1491), con i portali di autenticazione brandizzati Handala a sigillare visivamente la presa di controllo dell’infrastruttura.

Un altro elemento non trascurabile è il ruolo delle identità hacktiviste multiple che orbitano intorno a Yellow Phobos. Handala Hack è solo una delle maschere: le cronache degli ultimi anni hanno già visto Homeland Justice rivendicare operazioni distruttive contro il governo albanese, compresa la compromissione dei sistemi email del parlamento con conseguente sospensione dei servizi, mentre Anonymous for Justice ha firmato presunti wiping contro target israeliani nei settori legale, utilities e servizi finanziari. La logica è quella di una franchising strategy ideologica: nomi e logo cambiano a seconda del messaggio politico e del teatro operativo, ma le infrastrutture, le toolchain e il know‑how restano nelle mani dello stesso cluster operativo legato all’apparato di sicurezza iraniano. Per chi difende, questo rende meno utile concentrarsi sulla “sigla” e obbliga a riconoscere pattern tecnici ricorrenti, come l’abuso di provider di cloud occidentali, il riciclo creativo di domini typo‑squatting e un elenco crescente di IoC che spaziano da indirizzi IP a domini come handala‑hack.to, justicehomeland.* e una lunga serie di pseudo‑brand di big tech usati per phishing e comando e controllo.

Sul terreno, l’effetto dell’attacco è stato immediato anche fuori da Stryker. In Australia, ad esempio, le autorità sanitarie hanno messo in stato di allerta gli ospedali che dipendono da dispositivi e impianti Stryker, consapevoli che una disruption prolungata nella catena di fornitura può tradursi in ritardi nelle procedure chirurgiche, difficoltà nella manutenzione e nei richiami di sicurezza dei device. Al di là del singolo caso, il messaggio per il settore healthcare è che la resilienza non può essere pensata solo dentro il perimetro ospedaliero: un wiper‑driven incident su un player di medtech upstream può avere un impatto sistemico paragonabile a un attacco diretto a un grande ospedale universitario o a una centrale elettrica regionale.

Guardando oltre il perimetro sanitario, l’elenco di minacce diffuse dall’IRGC contro data center e uffici di big tech nel Golfo e in Israele apre un fronte nuovo, in cui i cloud provider e i grandi vendor di AI, storage e analytics non sono più solo infrastrutture di riferimento ma target dichiarati di operazioni di “infrastructure warfare”. Gli episodi recenti che citano attacchi con droni contro data center AWS negli Emirati Arabi Uniti e in Bahrain – ancora da chiarire nei dettagli tecnici – confermano che il confine tra attacco fisico e attacco logico si va sfumando: la stessa facility può finire in un rapporto di intelligence come potenziale obiettivo cinetico e, contemporaneamente, come nodo da degradare via campagne cyber destruttive o di preposizionamento.

All’interno di un’azienda, ente o organizzazione con footprint cloud esteso e dipendenza strutturale da ambienti Microsoft, la lezione del caso Stryker è tanto banale quanto scomoda: la tua superficie d’attacco più critica non è solo l’ennesimo zero‑day, ma il layer di identity e di gestione centralizzata che hai costruito per semplificarti la vita. La strategia di mitigazione descritta – MFA ovunque, soprattutto sugli account privilegiati, principle of least privilege spinto sulle console amministrative, PAM per isolare e tracciare l’uso delle credenziali ad alto impatto, RBAC rigoroso sui sistemi di endpoint management, EDR e SIEM con regole specifiche per rilevare movimenti laterali e azioni massive di wipe/reset – non è più “best practice”, è la baseline minima per sopravvivere a un avversario che ha dimostrato di saper trasformare Intune nel proprio wiper distribuito. L’altro pezzo del puzzle è la preparedness: backup offline e immutabili delle configurazioni critiche, runbook di incident response che contemplino la perdita simultanea di migliaia di endpoint, canali di comunicazione fuori banda pronti per quando la posta e i sistemi di messaggistica aziendale spariscono in un colpo solo.

In prospettiva, il caso Stryker rischia di essere ricordato come uno spartiacque, non tanto per la tecnologia impiegata – nessun exploit miracoloso, nessun malware da collezione – ma per il salto concettuale nell’abuso delle piattaforme di gestione cloud come arma di distruzione su larga scala. È un modello replicabile, economicamente efficiente per l’attaccante e perfettamente allineato a una dottrina in cui il cyber non serve solo a rubare dati o a fare pressione tramite estorsione, ma a erodere la capacità industriale e la fiducia nelle infrastrutture digitali dei Paesi avversari.

Ransomfeed

^Ransomfeed