Analisi della vicenda Phica.eu dal punto di vista tecnico e sistemistico

Il sito Phica.eu (nato come Phica.net), attivo ininterrottamente dal 2005 al 2025, è stato per vent’anni uno dei più controversi portali italiani, diventando tristemente noto per aver ospitato migliaia di foto di donne pubblicate senza consenso. Tra i contenuti figuravano immagini di personaggi noti, come Giorgia Meloni, Elly Schlein, Chiara Ferragni e Alessandra Moretti, ma soprattutto foto di donne comuni, fidanzate, mogli e persino figli minorenni, in alcuni casi rubate dai social o scattate di nascosto, in altri raccolte tramite condivisioni private. Molte di queste foto ritraevano le vittime in pose ammiccanti, fino ad arrivare a scatti completamente espliciti, diffusi all’insaputa delle protagoniste.

Nonostante decine e decine di denunce presentate negli anni, il sito è rimasto online per due decenni, sollevando domande e sospetti non solo tra le vittime, ma anche tra conoscenti, colleghi, appassionati del mondo IT e semplici curiosi: com’è possibile che un portale di questo tipo sia riuscito a operare indisturbato così a lungo, senza che le autorità riuscissero a intervenire in modo efficace?

Nel seguito di questo post forniremo la nostra visione tecnica della vicenda: analizzeremo come funzionano i servizi di hosting che permettono la sopravvivenza di portali illegali, spiegheremo gli errori commessi dal fondatore italiano che ne hanno permesso l’identificazione e metteremo in evidenza le lacune, i ritardi e le responsabilità delle Procure italiane e degli enti preposti al controllo. Non affronteremo la questione dal punto di vista etico e morale, certi che i corpus giuridici possano farlo con maggiore autorevolezza e competenza.

Phica.eu, il Forum XenForo con quasi un milione di iscritti.

Phica.eu non era semplicemente un sito web, ma un vero e proprio forum di grandi dimensioni, basato su XenForo 2, una delle piattaforme commerciali più potenti e apprezzate al mondo per la gestione di community online. XenForo è sviluppato in PHP e si appoggia a un DBMS MySQL-compatibile — come Percona Server o MariaDB — progettato per gestire elevati carichi di lavoro e ottimizzato per scenari ad altissimo traffico. Nato come naturale evoluzione di vBulletin, XenForo ne eredita parte delle basi architetturali ma introduce miglioramenti significativi, sia sul fronte delle performance che delle funzionalità.

La piattaforma è particolarmente famosa per le sue feature avanzate di gestione delle community, l’interfaccia utente moderna e la possibilità di integrare estensioni, plugin e sistemi di caching avanzati. Ma il vero punto di forza di XenForo è la gestione ottimizzata delle query SQL: l’engine è in grado di gestire migliaia di utenti connessi simultaneamente e supportare database con miliardi di post, mantenendo tempi di risposta estremamente ridotti. Un’installazione ben configurata, supportata da un’infrastruttura adeguata, consente di raggiungere livelli di scalabilità e affidabilità difficilmente eguagliabili da altri software concorrenti.

Nel caso specifico, Phica.eu rappresentava un esempio estremo di sfruttamento di queste potenzialità: il forum ospitava qualche milione di discussioni attive, con diversi miliardi di letture di pagina complessive accumulate negli anni. Secondo le stime pubbliche di SimilarWeb, il traffico generato era enorme, circa 6 milioni di visite mensili, con una media di 12 pagine visitate per ogni singola visita, ed un totale di circa 70 milioni di pagine viste al mese, un valore che lo collocava tra i portali più visitati in Italia, comparabile per numeri ai principali siti di informazione nazionale. A questo si aggiungeva una userbase registrata di circa 800.000 iscritti, che ne faceva una delle più grandi community online d’Europa nel suo settore.

Va precisato che SimilarWeb è un servizio che fornisce stime di traffico basate su analisi deduttive e non dati ufficiali. Tuttavia, la sua attendibilità aumenta sensibilmente nel caso di siti ad altissimo traffico, dove le approssimazioni tendono a rasentare la realtà. Questa considerazione si basa anche sulla nostra esperienza diretta: in più occasioni abbiamo confrontato i dati stimati da SimilarWeb con quelli reali e certificati di Google Analytics di alcuni nostri clienti ad alto volume di visite, riscontrando una notevole coerenza e affidabilità delle proiezioni fornite dal servizio.

Un simile volume di traffico richiedeva un’infrastruttura solida, con sistemi di caching multilivello, database ottimizzati, bilanciatori di carico e probabilmente l’uso di Content Delivery Network (CDN) per distribuire le risorse statiche a livello globale. Nonostante ciò, il sito rimaneva estremamente reattivo, segno di un’ottimizzazione tecnica accurata. È proprio questa combinazione di architettura performante, database ottimizzati e scalabilità orizzontale che ha permesso a Phica.eu di sostenere per anni volumi di traffico imponenti senza mostrare cedimenti evidenti.

Phica.eu, non solo Forum ma anche streaming Video

Oltre a essere un enorme forum basato su XenForo, Phica.eu si distingueva anche per l’integrazione di contenuti multimediali all’interno delle discussioni e dei commenti degli utenti. Il modus operandi più frequente prevedeva l’embedding di video provenienti da portali esterni: gli utenti inserivano link o player incorporati da piattaforme di terze parti, replicando dinamiche simili a quelle di YouTube, Vimeo o repository minori.

Tuttavia, Phica.eu non si limitava a questo: il portale disponeva di una propria infrastruttura di server dedicata alla distribuzione diretta dei video, organizzata come una CDN self-hosted. Questa rete era ben visibile pubblicamente e strutturata su più nodi dedicati, identificabili attraverso domini del tipo:

• cdn1.phica.eu

• cdn2.phica.eu

• cdn3.phica.eu
  …e così via, per un totale di circa dieci server dedicati esclusivamente alla gestione dei contenuti multimediali. Questi nodi ospitavano file video classici — generalmente in formati .mov e .mpeg — e offrivano funzionalità simili al video on demand rudimentale, ma non si trattava di vero streaming.

La differenza è sostanziale:

• Streaming video reale → utilizza protocolli moderni come HLS, MPEG-DASH o RTSP, che dividono il contenuto in segmenti caricati dinamicamente. Questo consente all’utente di saltare avanti o indietro nel video senza dover scaricare completamente le parti intermedie, riducendo tempi di attesa e consumo di banda.

• Sistema adottato da Phica.eu → la CDN amatoriale funzionava come un repository di file statici. Quando un utente voleva, ad esempio, saltare direttamente verso la fine di un video, era necessario che l’intero file fosse stato già scaricato fino a quel punto. Ciò comportava maggiore carico sui server, banda elevata e un’esperienza meno fluida rispetto alle piattaforme di streaming moderne.

Questa infrastruttura distribuita, composta da embedding di contenuti esterni e circa dieci nodi CDN proprietari, permetteva a Phica.eu di gestire centinaia di terabyte di contenuti video e contribuiva in modo significativo ai suoi impressionanti volumi di traffico, stimati intorno ai 100 milioni di pagine viste al mese. La presenza di una CDN dedicata così estesa dimostra come il progetto fosse tecnicamente più complesso di un semplice forum: dietro c’era un’infrastruttura strutturata, ottimizzata e costantemente scalata per reggere milioni di utenti attivi e miliardi di richieste mensili.

I guadagni stimati e reali di Phica.eu

Uno degli aspetti più discussi attorno al caso Phica.eu riguarda i guadagni generati dal portale nel corso degli anni. Basandoci su stime di mercato relative ai siti per adulti con volumi di traffico simili, i ricavi vengono calcolati tramite il parametro RPM (Revenue per Mille), cioè l’incasso medio ottenuto ogni 1.000 pagine viste. Per piattaforme di questo tipo, le stime più attendibili indicano un valore medio che oscilla tra 1 e 2 euro per ogni 1.000 visualizzazioni, con picchi che in certi casi possono arrivare anche a 3 euro a seconda della qualità del traffico e delle fonti pubblicitarie.

Rimanendo nello scenario più prudente, cioè 1 euro ogni 1.000 pagine viste, e tenendo conto delle circa 70 milioni di pagine mensili stimate da SimilarWeb, Phica.eu avrebbe potuto generare almeno 70.000 euro al mese, pari a circa 840.000 euro l’anno. Tuttavia, considerando le analisi più approfondite e alcune indiscrezioni apparse sui giornali, l’ipotesi di un RPM medio di 2 euro sembra più realistica: ciò significherebbe circa 140.000 euro di entrate mensili e oltre 1,6 milioni di euro di ricavi annui.

Un indizio importante a supporto di questa seconda ipotesi arriva dall’analisi dei dati societari di Hydra Group Eood, una delle imprese individuate come “parte collegata” all’infrastruttura di Phica. La società, registrata a Sofia con un capitale sociale di appena 50 euro, avrebbe dichiarato un fatturato superiore a 1,3 milioni di euro (per la precisione 1.369.296,48 euro). Una sproporzione evidente, che suggerisce come strutture apparentemente piccole possano diventare snodi chiave all’interno di architetture digitali complesse, movimentando capitali molto consistenti attraverso reti distribuite.

Gli stessi analisti, Valerio Lilli e Lorenzo Romani, hanno contribuito a ricostruire gli schemi societari e le connessioni dietro Phica.eu, utilizzando fonti aperte e strumenti di network analysis, tra cui il database Whois. Sebbene molti domini fossero protetti da servizi di privacy masking (ad esempio GoDaddy Domains by Proxy), l’incrocio di metadati e registrazioni ha comunque consentito di tracciare collegamenti significativi tra soggetti, società e infrastrutture. È importante sottolineare che non si tratta di prove definitive di titolarità, ma di ipotesi plausibili formulate a partire da tracce tecniche e documentali disponibili online, che delineano un ecosistema finanziariamente molto più strutturato di quanto potesse sembrare dall’esterno.

Il sistema di anonimato grossolano, poggiato su CloudFlare.

Per la natura delicata e rischiosa dei contenuti trattati da Phica.eu, il fondatore sapeva di esporsi a denunce, querele e possibili responsabilità penali. Per questo motivo aveva tentato di proteggersi adottando CloudFlare come livello di anonimato e difesa. CloudFlare è un servizio di Content Delivery Network (CDN) e reverse proxy che, tra le varie funzionalità, consente di mascherare l’indirizzo IP reale del server origin: invece di esporre l’IP dell’hosting effettivo, ai visitatori vengono mostrati gli IP di CloudFlare, che si interpone tra l’utente e il server, filtrando il traffico, gestendo la cache e offrendo protezione DDoS.

In questo scenario, chi effettua una richiesta HTTP verso Phica.eu non comunica mai direttamente con il server reale, ma con i nodi CloudFlare, che poi indietro inoltrano la connessione al server origin. Questo approccio, apparentemente, garantisce un certo grado di anonimato per chi gestisce il portale, perché un utente che cerca di risalire all’indirizzo IP del server reale vedrà solo gli IP pubblici di CloudFlare.

Tuttavia, è importante capire come funziona la politica di gestione degli “Abuse” da parte di CloudFlare. Quando un soggetto — per esempio una ragazza che trova le sue foto private pubblicate su Phica.eu senza consenso — invia a CloudFlare una richiesta di rimozione per violazione di copyright (DMCA) o un abuse report, CloudFlare non interviene direttamente sui contenuti. Per politica di net neutrality, il servizio agisce da mero intermediario tecnico: riceve la segnalazione, identifica l’IP reale del server origin e inoltra la richiesta al provider di hosting che gestisce quel server.

Ad esempio, se il server di Phica.eu fosse stato ospitato presso un provider ipotetico come “ACME S.p.A.”, e l’IP reale fosse mascherato dietro gli IP pubblici di CloudFlare, il flusso sarebbe questo:

Questo significa che CloudFlare non spegnerà mai il sito, né bloccherà i contenuti contestati, perché non li ospita e per policy aziendale e della Net Neutrality, non effettua moderazione attiva. Il compito di valutare le violazioni e intraprendere eventuali azioni legali o tecniche ricade sempre sul provider che gestisce il server origin. In un contesto come quello di Phica.eu, questa dinamica ha reso più difficile intervenire rapidamente contro il portale, soprattutto se il provider dietro l’infrastruttura era compiacente o inattivo nel gestire le segnalazioni di abuso.

La responsabilità del provider origin dietro CloudFlare

In uno scenario come quello analizzato, il punto cruciale è identificare il provider origin, cioè l’hosting effettivo che si trova dietro la protezione di CloudFlare, e comprendere come decide di operare quando riceve segnalazioni di abuso.

La normativa italiana di riferimento è il D.Lgs. 70/2003, che recepisce la Direttiva europea 2000/31/CE sul commercio elettronico. In particolare, gli articoli 14, 15 e 16 stabiliscono che:

• Un Hosting Provider non è responsabile penalmente né civilmente per i contenuti caricati dai propri clienti, finché non è a conoscenza della loro natura illecita.

• La responsabilità scatta nel momento in cui l’hosting riceve una segnalazione formale (ad esempio un abuse report, una notifica DMCA o una contestazione per violazione di copyright o privacy).

• Dal momento in cui è consapevole del contenuto illecito, il provider ha l’obbligo di rimuoverlo o di impedirne l’accesso, pena la possibilità di rispondere civilmente o penalmente per “concorso” nella diffusione di materiale illecito.

Nel caso di Phica.eu, quando CloudFlare riceveva una segnalazione di abuso, non rimuoveva i contenuti (per sua policy di neutralità), ma inoltrava la richiesta al provider origin che ospitava fisicamente il sito. A quel punto, l’hosting si trovava di fronte a tre possibili scenari:

1. Ignorare deliberatamente la segnalazione

   • Alcuni provider, soprattutto se registrati in Paesi con giurisdizioni permissive, decidono consapevolmente di non intervenire. Questo consente al portale di rimanere online anche per anni, nonostante le richieste di rimozione.

2. Accettare le giustificazioni del cliente

   • Spesso, ricevuta la notifica da CloudFlare, il provider informa il proprietario del sito e richiede spiegazioni. Se il cliente fornisce motivazioni tecniche o legali che l’hosting ritiene plausibili, il provider può decidere di non sospendere il servizio.

3. Intervenire sospendendo o oscurando il servizio

   • In teoria, se il cliente non risponde o non fornisce giustificazioni valide, il provider dovrebbe disattivare l’account, rimuovere i contenuti o collaborare con le autorità competenti.

In pratica, il meccanismo funziona come un passaparola tecnico:

• CloudFlare riceve la segnalazione →

• La inoltra al provider origin →

• Il provider informa il cliente finale →

• Il cliente deve rispondere →

• Il provider decide se sospendere, ignorare o mantenere il servizio.

Questo significa che il cliente finale viene sempre a conoscenza delle segnalazioni di abuso: il provider è formalmente obbligato a trasmetterle. Tuttavia, se l’hosting non agisce o decide di credere alle giustificazioni del cliente, il sito rimane online.

Nel caso di Phica.eu, appare quindi probabile e verosimile che il provider origin dietro CloudFlare abbia:

• ignorato deliberatamente le numerose richieste di rimozione,
  oppure

• accettato le giustificazioni fornite dal gestore, permettendo al portale di restare operativo per quasi vent’anni nonostante le decine di denunce.

Il D.Lgs. 70/2003 evidenzia un punto fondamentale: un hosting provider non è mai penalmente responsabile fino a quando non sa. Ma dal momento in cui sa, è obbligato ad agire. Se non lo fa, la responsabilità — almeno in sede civile — ricade anche su di lui.

Chi è il provider origin dietro a Phica.eu?

Quando si parla di Phica.eu e si cerca di capire chi sia il provider origin che ospita realmente il forum, bisogna partire da un concetto fondamentale: questo sito non nasce dal nulla. La sua storia parte da molto lontano e per fare un’analisi OSINT seria è indispensabile ricostruire l’intera cronologia delle sue infrastrutture tecniche.

Il forum Phica nasce ufficialmente nell’agosto del 2005 con il dominio phica.net. In quegli anni diventa progressivamente uno dei più grandi forum italiani legati a contenuti pornografici e, soprattutto, a materiale non consensuale, fino a essere definito, di fatto, un hub di revenge porn. Per quasi 17 anni, phica.net rappresenta il punto di accesso principale alla piattaforma, accumulando milioni di post e centinaia di migliaia di utenti registrati.

Poi, nel 2022, accade un passaggio strategico importante: phica.net inizia a fare redirect automatico verso phica.eu. Questa mossa, apparentemente banale, ha un significato tecnico preciso. Il cambio di dominio può essere legato a più motivi, tra cui:

• Tentativo di eludere eventuali sequestri o blocchi legali.

• Ricerca di un’infrastruttura più sicura per proteggersi da indagini e attacchi informatici.

• Volontà di spostare il focus operativo verso un provider europeo e, probabilmente, di sfruttare giurisdizioni più favorevoli.

Capire chi sia il provider origin dietro phica.eu non è semplice, soprattutto perché oggi il sito si affida a Cloudflare come servizio di protezione. Cloudflare agisce come reverse proxy e nasconde l’indirizzo IP reale del server, schermando così il provider che ospita fisicamente il forum. Tuttavia, con una strategia OSINT ben strutturata, possiamo ricostruire diverse tracce storiche.

1. Perché l’analisi deve partire da phica.net

Per risalire al provider origin di phica.eu, non possiamo limitarci ad analizzare l’attuale infrastruttura: dobbiamo partire dall’inizio, quando la piattaforma utilizzava phica.net. Questo è essenziale perché nel periodo 2005 → 2022 il forum ha operato senza la stessa attenzione alla privacy che adotta oggi.

L’indagine OSINT si sviluppa quindi su tre step principali:

1. Analisi storica del dominio phica.net per capire dove fosse ospitato nei primi anni.

2. Tracciamento delle migrazioni successive fino alla transizione a phica.eu.

3. Analisi dei layer di protezione attuali e individuazione di potenziali punti deboli che rivelano l’infrastruttura origin.

2. I primi anni di phica.net (2005 → 2010)

L’analisi dei record DNS storici mostra che phica.net, nei suoi primi anni, era ospitato in Italia tramite Serverplan, un provider noto per offrire servizi economici e infrastrutture semplici.

Questa informazione è stata ricavata utilizzando strumenti OSINT come:

• SecurityTrails

• RiskIQ PassiveTotal

• DNSdumpster

Questi database conservano i vecchi A record e permettono di ricostruire le variazioni storiche degli indirizzi IP.

Durante questa prima fase, phica.net non utilizzava alcuna protezione avanzata, i server rispondevano direttamente, e l’indirizzo IP era visibile pubblicamente. È verosimile che in questo periodo siano state raccolte molte informazioni, inclusi i provider fisici, i data center e le configurazioni utilizzate.

3. Il passaggio all’estero: Francia e Canada

Dopo qualche anno, probabilmente per aumentare l’anonimato e proteggersi da potenziali indagini italiane, phica.net migra la propria infrastruttura verso la Francia. Qui viene ospitato per un periodo limitato, probabilmente sfruttando Server Dedicati o VPS ad alto traffico.

Successivamente, il forum si sposta definitivamente in Canada, dove trova la sua “casa stabile” per diversi anni. Analizzando le informazioni DNS, emerge che il provider più probabile in questa fase è OVH, uno dei colossi europei dell’hosting, che dispone di enormi data center sia in Francia sia in Canada.

La scelta di OVH non sorprende: il gruppo è tra i più grandi operatori europei, con una reputazione consolidata nell’offrire infrastrutture scalabili, ad alte prestazioni e con politiche di gestione della privacy relativamente favorevoli per chi cerca anonimato. Tuttavia, c’è un aspetto interessante dal punto di vista investigativo: OVH ha anche una succursale commerciale in Italia. Questa presenza sul territorio nazionale potrebbe rappresentare un punto di accesso strategico per le forze dell’ordine italiane, che potrebbero fare leva sulla sede locale per richiedere formalmente dati e informazioni nell’ambito di un’indagine, seguendo le procedure previste dalla cooperazione giudiziaria internazionale.

OVH viene spesso scelto per forum di questo tipo per tre motivi principali:

1. Costi bassi rispetto ad altri provider di pari livello.

2. Elevata banda disponibile, fondamentale per gestire centinaia di migliaia di immagini e video.

3. Protezione parziale dei dati e maggiore difficoltà per le autorità estere di intervenire rapidamente, anche se – grazie alla sede italiana – le forze dell’ordine avrebbero oggi più margini per agire rispetto al passato.

4. L’introduzione di Cloudflare

Con la crescente popolarità e le crescenti polemiche intorno al forum, phica.net decide di adottare Cloudflare come livello di protezione intermedio. Da questo momento in poi, tutte le richieste verso il dominio passano attraverso l’infrastruttura di Cloudflare, che funge da reverse proxy e maschera l’indirizzo IP del server reale.

Dal punto di vista OSINT, questo introduce un ostacolo importante:

• Non è più possibile ottenere l’IP origin tramite un semplice DNS lookup.

• Gli strumenti di base come dig, nslookup o whois restituiscono solo indirizzi IP legati a Cloudflare.

Questo passaggio segna l’inizio di una strategia di protezione attiva da parte del forum, che diventa molto più difficile da tracciare.

5. La migrazione verso phica.eu (dal 2022)

Nel 2022 avviene la svolta: il dominio principale diventa phica.eu. L’intero traffico da phica.net viene reindirizzato tramite redirect 301 verso la nuova estensione europea.

Le motivazioni possono essere molteplici:

• Evitare blacklist o sequestri del dominio .net.

• Cercare una giurisdizione più favorevole.

• Migrare verso una nuova infrastruttura, più sicura e distribuita.

Da qui in avanti, phica.eu eredita l’intera struttura preesistente ma la rafforza con un livello di protezione aggiuntivo. Anche in questo caso, il traffico è incanalato attraverso Cloudflare, che nasconde completamente l’IP origin.

6. Come individuare l’origin server dietro Cloudflare

Sebbene Cloudflare protegga l’indirizzo IP reale, esistono tecniche OSINT avanzate per tentare di individuare l’origin provider. Alcune delle principali:

a) Passive DNS e SecurityTrails

• Si analizzano i vecchi record DNS legati a phica.net prima dell’adozione di Cloudflare.

• Spesso i vecchi IP rimangono associati al dominio anche dopo il cambio.

b) Subdomain Enumeration

• Tramite analisi dei sottodomini attivi e inattivi, è possibile individuare endpoint che non passano da Cloudflare e rivelano l’IP reale.

• Strumenti come Amass, Subfinder o crt.sh possono aiutare.

c) Analisi dei certificati SSL

Abbiamo scoperto, tramite un’analisi approfondita dei certificati digitali, che risultano presenti certificati Let’s Encrypt attivi per diversi sottodomini di phica.eu. Per ottenere queste informazioni abbiamo utilizzato crt.sh, un servizio pubblico che consente di consultare il Certificate Transparency Log e visualizzare tutti i certificati SSL rilasciati per un determinato dominio.

Questa scoperta è particolarmente interessante perché, se anche solo uno di questi sottodomini non fosse protetto da Cloudflare – ad esempio un endpoint secondario, un vecchio pannello di amministrazione o un servizio interno rimasto esposto – potrebbe rivelare direttamente l’indirizzo IP del server origin.

Conoscere l’IP reale ci permetterebbe di individuare il provider effettivo che ospita l’infrastruttura, bypassando così il livello di protezione offerto da Cloudflare e rendendo molto più semplice collegare phica.eu alla sua infrastruttura fisica.

d) Shodan e Censys

Inserendo phica.net o phica.eu su Shodan si possono individuare:

• • Vecchi endpoint rimasti attivi.

  • Servizi esposti.

  • Informazioni sul provider reale.

7. Le falle scoperte nell’infrastruttura

Durante l’analisi OSINT del forum, sono emerse vulnerabilità significative:

• Sitemap pubbliche non protette: oltre 981.000 pagine indicizzate liberamente.

• Email in chiaro associate agli utenti: circa 791.000 profili registrati, molti con dati personali visibili.

• Servizi non aggiornati individuati tramite Shodan, con potenziali exploit noti.

• Possibili SQL injection a causa di software obsoleto.

Questi dettagli non rivelano solo problemi di privacy per gli utenti, ma aprono anche potenziali scenari per individuare i server reali tramite analisi dei log, delle chiamate dirette e delle vecchie versioni dei sottodomini.

8. La situazione attuale

Oggi, phica.eu opera dietro un’infrastruttura robusta:

• Cloudflare protegge l’origin da attacchi DDoS e ne nasconde la posizione.

• I DNS e i sottodomini principali passano tutti per il proxy di Cloudflare.

• Il provider origin è quasi certamente un grande operatore europeo o nordamericano, con OVH che rimane il candidato più probabile, data la storia passata del dominio e la vicinanza geografica alle sedi di Cloudflare in Europa.

Tuttavia, la presenza di sottodomini Gmail e Google Workspace lascia intendere che parte delle comunicazioni email sia gestita tramite Google, e questo rappresenta un potenziale punto d’ingresso per eventuali indagini.

Scoprire chi sia il provider origin dietro a phica.eu non è un compito banale. Il cambio di dominio, l’adozione di Cloudflare e la struttura distribuita dei sottodomini rendono l’indagine complessa. Tuttavia, ricostruendo l’intera storia del forum a partire da phica.net, emergono dettagli importanti:

• Nei primi anni il sito era ospitato in Italia (Serverplan).

• Successivamente si è spostato in Francia e infine in Canada, probabilmente su OVH.

• Dal 2022, con la nascita di phica.eu, tutta l’infrastruttura passa dietro Cloudflare.

• Analisi OSINT su DNS, sottodomini, certificati SSL e Shodan indicano che il provider origin attuale potrebbe ancora essere OVH o un provider di pari livello.

In altre parole, sebbene oggi Cloudflare nasconda l’indirizzo IP reale, i dati storici e le evidenze tecniche lasciano intuire che la “casa madre” del forum sia rimasta sostanzialmente invariata: un’infrastruttura ad alte prestazioni, molto probabilmente basata su Server Dedicati collocati in Europa, con OVH come candidato principale.

Come avrebbe dovuto funzionare questo sito a prova di intelligence per non essere scoperto ?

Analizzando l’infrastruttura di phica.eu e la sua evoluzione dal vecchio phica.net, è evidente che sono stati commessi diversi errori strutturali che hanno lasciato tracce tecniche, amministrative e commerciali. Nonostante l’attuale utilizzo di Cloudflare come sistema di protezione, si tratta di una soluzione piuttosto basilare, con tutti i limiti del caso. Cloudflare è efficace nel mascherare l’indirizzo IP origin e proteggere il sito da attacchi DDoS, ma non è sufficiente per costruire un’infrastruttura a prova di intelligence e davvero resistente a indagini coordinate tra diverse giurisdizioni.

Per comprendere come phica.eu avrebbe potuto essere reso quasi impossibile da tracciare, dobbiamo partire dagli errori iniziali commessi ai tempi di phica.net. Nei primi anni, infatti, il forum era ospitato su provider italiani come Serverplan, lasciando tracce commerciali chiare: pagamenti tracciabili, fatture intestate e dati anagrafici associati agli account. All’epoca, tra l’altro, non esistevano le criptovalute, quindi i pagamenti avvenivano quasi esclusivamente tramite bonifici, carte di credito o sistemi tradizionali, tutti facilmente accessibili alle forze dell’ordine. Questa scelta iniziale ha prodotto una catena di evidenze storiche che oggi non può più essere cancellata.

Un’infrastruttura realmente blindata avrebbe richiesto un approccio molto diverso, non solo tecnico, ma anche giuridico. La sicurezza operativa di un sistema di questo tipo si basa infatti su due pilastri:

1. Protezione multilivello dell’infrastruttura.

2. Sfruttamento delle giurisdizioni favorevoli e dei loro conflitti legali con altri Paesi.

Dal punto di vista tecnico, la soluzione più efficace non sarebbe stata affidarsi solo a Cloudflare come unico punto di ingresso. Sarebbe stato necessario inserire almeno due ulteriori livelli di protezione, costruendo un percorso di inoltro del traffico tra diversi Paesi e diversi provider, sfruttando le difficoltà legali derivanti da giurisdizioni internazionali.

Un esempio di architettura più robusta:

• Primo livello: Endpoint pubblico protetto da Cloudflare, che agisce solo come strato di offuscamento iniziale.

• Secondo livello: Un reverse proxy offshore situato in Russia, dove l’accesso ai dati da parte di autorità europee o italiane sarebbe estremamente complesso. La Russia, inoltre, è oggi in conflitto con diversi Paesi europei e NATO, e questo rallenterebbe notevolmente qualsiasi cooperazione internazionale.

• Terzo livello: Un ulteriore strato intermedio tramite un provider in Malesya, un Paese noto per ospitare servizi di hosting offshore e per la difficoltà di ottenere informazioni tramite canali ufficiali.

• Quarto ed ultimo livello: Il datacenter reale come abbiamo stimato in questo caso come opzione possibile OVH

Questa doppia intermediazione tecnica potrebbe essere implementata sia con reverse proxy HTTP sia tramite un più semplice port forwarding delle porte HTTP/HTTPS: in entrambi i casi, l’effetto sarebbe quello di nascondere completamente il server origin.

Per rendere l’analisi ancora più complessa, l’infrastruttura russa avrebbe potuto essere ospitata presso entità opache come la RBN – Russian Business Network, nota storicamente per gestire attività di cybercrime, darknet e protezione di siti ad alto rischio. In questo scenario, eventuali richieste ufficiali provenienti da autorità italiane o europee sarebbero state ignorate o rimbalzate, costringendo le forze dell’ordine a tentare una cooperazione internazionale con realtà ostili o volutamente non collaborative.

A quel punto, il traffico proveniente dai proxy russi sarebbe stato forwardato verso la Malesya, che a sua volta avrebbe potuto inviarlo al server finale europeo, ad esempio ospitato presso OVH.

In questo scenario, se un’autorità italiana avesse tentato di risalire al provider origin, l’indagine si sarebbe scontrata con una catena di passaggi tecnici e giuridici complessi:

• Primo passo: la richiesta partirebbe da Cloudflare, che è l’unico endpoint visibile pubblicamente.

• Secondo passo: Cloudflare indicherebbe come successivo nodo un reverse proxy situato in Malesia. In questo caso, la cooperazione internazionale sarebbe già complicata, poiché la Malesia non aderisce agli stessi protocolli di mutua assistenza giudiziaria previsti nell’Unione Europea.

• Terzo passo: il nodo malesiano, a sua volta, potrebbe inoltrare il traffico verso un secondo proxy situato in Russia. Qui l’iter diventerebbe ancora più difficile, perché la Russia non è tenuta a fornire alcuna collaborazione e, soprattutto nel contesto politico attuale, tende a ignorare le richieste di polizia internazionale.

• Quarto passo: solo superando questi livelli, teoricamente, si potrebbe arrivare al server origin finale, che in passato abbiamo ipotizzato potesse essere ospitato da un provider europeo come OVH. Tuttavia, questo rimane improbabile da verificare, perché l’infrastruttura multilivello rende estremamente complesso stabilire con certezza quale sia il provider effettivo.

In questo modello, dunque, si parte da Cloudflare, ma i passaggi successivi introducono strati di opacità tecnica e giurisdizionale che rendono l’individuazione dell’origin altamente complessa rendendo praticamente impossibile individuare il server finale, garantendo al forum un livello di anonimato quasi totale.

In poche parole, phica.eu ha puntato su un modello di protezione monolitico basato unicamente su Cloudflare, che offre una schermatura minima ma non risolve i problemi strutturali e giuridici legati alla tracciabilità. Un’infrastruttura davvero a prova di intelligence avrebbe richiesto un progetto più avanzato, costruito per sfruttare zone grigie giuridiche e per creare un percorso multilivello di reverse proxy offshore che rendesse impossibile o estremamente complesso ottenere dati utili attraverso richieste ufficiali.

Considerazioni e riflessioni sull’operato delle forze dell’ordine e delle procure.

Fino a questo punto, abbiamo analizzato la vicenda principalmente dal punto di vista tecnico e sistemistico, concentrandoci sull’infrastruttura di phica.net prima e phica.eu poi, sulle protezioni adottate, sulle vulnerabilità presenti e su come, teoricamente, sarebbe stato possibile rintracciare o oscurare il sito. Tuttavia, le ultime notizie emerse e le numerose inchieste giornalistiche pongono un interrogativo ancora più rilevante: com’è stato possibile che un portale di tali dimensioni, attivo da quasi vent’anni, sia rimasto online indisturbato, nonostante negli anni siano state sporti decine e decine di denunce da parte di vittime, familiari e associazioni?

Questa assenza di azioni incisive da parte delle autorità competenti – procure, polizia postale, magistratura – solleva interrogativi legittimi su come siano state gestite le segnalazioni. Quando si parla di un portale con oltre 800.000 iscritti, quasi un milione di pagine indicizzate e una presenza massiva di materiale potenzialmente illecito, ci si aspetterebbe un approccio investigativo combinato, che unisca tecniche OSINT avanzate, cooperazione internazionale e strumenti di contenimento immediato.

Le alternative tecniche possibili ma mai attuate

Oltre alla localizzazione dei server e all’identificazione dei gestori, esistono diverse strategie tecniche consolidate che avrebbero potuto rendere phica.eu e phica.net irraggiungibili per la maggioranza degli utenti italiani, senza attendere la chiusura definitiva del portale.

1. Sequestro e hijacking DNS

Una delle soluzioni più semplici e utilizzate da anni contro portali illegali sarebbe stata l’implementazione di un sequestro DNS tramite DNS hijacking. Questa tecnica è in uso da decenni e viene comunemente adottata dalle autorità giudiziarie quando un sito viola la legge.

Il meccanismo è semplice:

• L’autorità giudiziaria emette un provvedimento di sequestro.

• I provider DNS degli ISP italiani vengono istruiti a modificare le risoluzioni del dominio.

• Invece di risolvere il vero indirizzo IP del portale, i DNS rispondono con un reindirizzamento a una pagina di notifica che segnala l’avvenuto sequestro.

Questa misura non avrebbe eliminato il sito a livello globale, ma ne avrebbe bloccato l’accesso dalla maggior parte degli utenti italiani, complicando notevolmente la navigazione per chi non dispone di competenze avanzate e di una VPN.

2. Blocco del traffico tramite sistemi di anti-pirateria (tecnica “IP blocking dinamico”)

Un’altra soluzione possibile, ancora più incisiva, sarebbe stata l’adozione del sistema già utilizzato in Italia per contrastare la pirateria sportiva, quello impiegato contro i portali che trasmettono illegalmente eventi calcistici di Sky e DAZN.

Questo sistema, definito “IP blocking dinamico”, informalmente conosciuto come “Filtro Anti Pezzotto” è gestito su impulso dell’AGCOM (Autorità per le Garanzie nelle Comunicazioni) e funziona in questo modo:

1. Identificazione degli IP incriminati in tempo reale.

2. L’AGCOM invia una comunicazione immediata a tutti gli ISP italiani.

3. Gli ISP implementano regole di routing a livello di backbone, bloccando il traffico verso gli IP segnalati.

4. La propagazione avviene in pochi minuti, e il sito diventa irraggiungibile a livello nazionale, indipendentemente dal dominio o dai cambi DNS.

Questa soluzione sarebbe stata particolarmente efficace nel caso di phica.eu, perché avrebbe potuto bloccare l’accesso all’intera infrastruttura, rendendo vano ogni tentativo di cambio dominio o migrazione di server.

Un ventennio di immobilismo

Quello che lascia più perplessi, e per certi versi sconcertati, è che nessuna di queste opzioni sia stata applicata per quasi 20 anni. Secondo quanto riportato da numerose testate giornalistiche che hanno indagato sul caso, nel corso degli anni erano state presentate decine e decine di denunce: da singole vittime che avevano visto le proprie immagini diffuse senza consenso, da familiari di persone coinvolte e persino da associazioni che si occupano di tutela della privacy e della sicurezza online. Inoltre, diverse procure italiane erano già informate da tempo dell’esistenza di questo forum e della sua estrema pericolosità sociale.

Eppure, phica.net prima e phica.eu poi hanno continuato a operare indisturbati, senza alcuna limitazione tecnica significativa, crescendo esponenzialmente fino a raggiungere numeri impressionanti:

• Oltre 800.000 utenti registrati.

• Milioni di messaggi pubblicati in oltre due decenni.

• Quasi un milione di pagine contenenti immagini, video e dati sensibili di persone ignare.

Questo silenzio operativo da parte delle autorità competenti apre scenari preoccupanti. Da un lato, le procure erano già al corrente del fenomeno. Dall’altro, i vari nuclei specializzati di polizia, inclusi i reparti della Polizia Postale e quelli dedicati alla criminalità informatica, non hanno messo in atto alcuna misura concreta per contenere il problema. Non risulta, ad esempio, che siano stati predisposti:

• Blocco del dominio tramite DNS hijacking.

• Interventi mirati sul traffico di rete tramite IP blocking dinamico.

• Oscuramento selettivo delle infrastrutture del sito attraverso canali giudiziari internazionali.

Questa inerzia operativa ha permesso al forum di rafforzare la propria infrastruttura nel tempo, passando da phica.net a phica.eu, adottando Cloudflare come livello di protezione e aumentando la difficoltà di rintracciare i server origin. Il tutto mentre, per quasi due decenni, le autorità non riuscivano – o non volevano – agire in modo efficace.

Il quadro diventa ancora più sconcertante quando si apprende che solo dopo una forte mobilitazione politica e mediatica la situazione si è sbloccata. Le prese di posizione pubbliche di alcune figure istituzionali, tra cui la premier Giorgia Meloni, hanno creato la pressione necessaria per spingere le procure e gli organi di polizia a intervenire.

È stato solo grazie a questa spinta politica, e non a un intervento autonomo delle forze dell’ordine, che nel giro di appena 48 ore le autorità hanno predisposto le azioni necessarie per oscurare e mettere offline un portale che viveva indisturbato da oltre vent’anni.

Questa dinamica evidenzia due aspetti critici:

1. La mancanza di coordinamento tra procure e reparti di polizia specializzati.

2. L’assenza di una strategia proattiva nell’affrontare fenomeni digitali complessi, che vengono invece affrontati solo dopo un’esplosione mediatica e non nel merito delle numerose denunce pregresse.

Conclusioni

L’intera vicenda mette in evidenza una carenza sistemica profonda nella gestione delle denunce, nella cooperazione tra procure e nella rapidità d’intervento delle autorità competenti. Non si tratta soltanto di un problema tecnico, ma di una combinazione di strategie investigative carenti, mancato coordinamento tra enti e assenza di pianificazione operativa per fronteggiare reati digitali complessi che richiedono risposte tempestive e integrate.

La storia di phica.net e phica.eu ci offre però un duplice spunto di riflessione: da un lato, mette in luce gli errori e le inadempienze istituzionali; dall’altro, fornisce una panoramica utile per comprendere due aspetti fondamentali:

1. Come allestire sistemi realmente anonimi e robusti, dal punto di vista tecnico e infrastrutturale.

2. Quali tecniche OSINT e strumenti di analisi siano disponibili oggi per indagare in modo approfondito sull’infrastruttura di un sito web.

Da un punto di vista strettamente tecnico, strumenti come il DNS hijacking o l’IP blocking dinamico avrebbero consentito di intervenire molto prima: due metodologie consolidate che avrebbero potuto limitare enormemente l’accesso al portale, proteggendo centinaia di migliaia di vittime e contenendo l’impatto sociale. Il primo, il DNS hijacking, è utilizzato da anni per bloccare domini illegali attraverso la modifica della risoluzione DNS presso gli ISP. Il secondo, l’IP blocking dinamico — già ampiamente impiegato per contrastare la pirateria sportiva e gestito in collaborazione con l’AGCOM — avrebbe potuto intervenire a livello di backbone nazionale, impedendo in tempo reale il routing del traffico verso gli indirizzi IP associati a phica.eu, indipendentemente da eventuali cambi di dominio.

Questi strumenti erano già disponibili, e non solo: negli ultimi anni sono stati ampiamente collaudati in altri contesti complessi. La tecnologia esisteva, così come le competenze tecniche necessarie per attuare un intervento rapido e coordinato. Eppure, per motivi che intrecciano inerzia burocratica, mancanza di visione strategica e probabilmente assenza di volontà politica e giudiziaria, non è stato fatto nulla fino a quando il caso non è esploso mediaticamente.

Parallelamente, l’analisi OSINT svolta sulla vicenda offre anche un valore educativo e tecnico. Strumenti come:

• Shodan e Censys per identificare servizi esposti, certificati SSL e potenziali vulnerabilità.

• SecurityTrails e RiskIQ PassiveTotal per ricostruire la storia DNS e i vecchi IP associati al dominio.

• crt.sh per analizzare i certificati rilasciati ai sottodomini e individuare endpoint nascosti.

• Subdomain enumeration e analisi delle sitemap per scoprire informazioni pubblicamente accessibili.

Tutti questi strumenti, se utilizzati correttamente, dimostrano come sia possibile, anche da un punto di vista esterno, raccogliere informazioni tecniche significative e strutturare un’indagine dettagliata. Il fatto che un singolo ricercatore OSINT indipendente sia riuscito a individuare falle e tracce lasciate online per anni dimostra che le competenze erano disponibili, ma non sono state sfruttate da chi avrebbe avuto i mezzi e l’autorità per farlo.

Alla luce di quanto accaduto, diventa evidente che il problema non era la mancanza di tecnologia né di strumenti investigativi: tutto ciò era già a disposizione, e in alcuni casi perfino consolidato da anni di utilizzo. Ciò che mancava, probabilmente, era una reale volontà politica e giudiziaria di agire con tempestività e un coordinamento operativo efficace tra procure, autorità di garanzia e nuclei specializzati della polizia.

La lezione che si può trarre è duplice:

• Sul fronte difensivo, chi gestisce piattaforme deve comprendere che l’anonimato assoluto richiede scelte infrastrutturali molto più complesse di una semplice protezione con Cloudflare, perché ogni errore storico — pagamenti tracciabili, log non protetti, DNS non offuscati — lascia tracce che possono riemergere anche anni dopo.

• Sul fronte investigativo, le forze dell’ordine hanno oggi a disposizione strumenti OSINT potentissimi che, se usati in modo sistematico, possono mappare in dettaglio un’infrastruttura complessa e indirizzare indagini giudiziarie più rapide ed efficaci.

In sintesi, questo caso dimostra come il divario tra ciò che era tecnicamente possibile e ciò che è stato realmente fatto sia enorme, e rappresenta un problema che va ben oltre phica.eu, toccando l’intero approccio istituzionale alla gestione dei crimini digitali complessi.