Analyse du cas Phica.eu d'un point de vue technique et systémique

Le site web Phica.eu (anciennement Phica.net), actif sans interruption de 2005 à 2025 , a été l'un des portails italiens les plus controversés pendant vingt ans, tristement célèbre pour avoir hébergé des milliers de photos de femmes publiées sans leur consentement . Parmi ces photos figuraient des images de personnalités telles que Giorgia Meloni, Elly Schlein, Chiara Ferragni et Alessandra Moretti, mais surtout des photos de femmes ordinaires, compagnes, épouses et même mineures , parfois volées sur les réseaux sociaux ou prises à leur insu, parfois collectées via des partages privés . Nombre de ces photos montraient les victimes dans des poses suggestives , voire totalement explicites , diffusées à leur insu.

Malgré des dizaines et des dizaines de plaintes déposées au fil des ans, le site est resté en ligne pendant deux décennies , suscitant des questions et des soupçons non seulement parmi les victimes, mais aussi parmi leurs connaissances, leurs collègues, les passionnés d'informatique et les simples curieux : comment est-il possible qu'un portail de ce type ait pu fonctionner sans être inquiété pendant si longtemps, sans que les autorités soient en mesure d'intervenir efficacement ?

Dans la suite de cet article, nous présenterons notre analyse technique de la question : nous examinerons le fonctionnement des services d’hébergement qui permettent la survie des portails illégaux , nous expliquerons les erreurs commises par le fondateur italien qui ont conduit à leur identification, et nous mettrons en lumière les lacunes, les retards et les responsabilités des procureurs italiens et autres instances de régulation . Nous n’aborderons pas la question sous un angle éthique ou moral , convaincus que le cadre juridique est capable de le faire avec davantage d’autorité et de compétence.

Phica.eu, le forum XenForo avec près d'un million de membres.

Phica.eu n'était pas un simple site web, mais un véritable forum d'envergure , basé sur XenForo 2 , l'une des plateformes commerciales les plus puissantes et populaires au monde pour la gestion de communautés en ligne. Développé en PHP , XenForo utilise un SGBD compatible MySQL , tel que Percona Server ou MariaDB , conçu pour supporter des charges de travail importantes et optimisé pour les scénarios de très fort trafic. Né de l' évolution naturelle de vBulletin , XenForo hérite d'une partie de son architecture, tout en y apportant des améliorations significatives , tant en termes de performances que de fonctionnalités.

La plateforme est particulièrement réputée pour ses fonctionnalités avancées de gestion de communauté , son interface utilisateur moderne et sa capacité à intégrer des extensions, des plugins et des systèmes de cache performants . Mais le véritable atout de XenForo réside dans sa gestion optimisée des requêtes SQL : son moteur peut gérer des milliers d'utilisateurs connectés simultanément et prendre en charge des bases de données contenant des milliards de messages , tout en garantissant des temps de réponse extrêmement courts. Une installation bien configurée, reposant sur une infrastructure adéquate, permet d'atteindre des niveaux d' évolutivité et de fiabilité difficiles à égaler par les autres logiciels concurrents.

Dans ce cas précis, Phica.eu représentait un exemple extrême d'exploitation de ce potentiel : le forum hébergeait plusieurs millions de discussions actives , totalisant plusieurs milliards de pages vues au fil des ans. Selon les estimations publiques de SimilarWeb , le trafic généré était colossal, avec environ 6 millions de visites mensuelles, soit une moyenne de 12 pages vues par visite et un total d'environ 70 millions de pages vues par mois . Ce chiffre le plaçait parmi les portails les plus visités d'Italie, comparable aux principaux sites d'information nationaux. À cela s'ajoutait une base d'utilisateurs inscrits d'environ 800 000 membres , ce qui en faisait l'une des plus grandes communautés en ligne de son secteur en Europe.

Il convient de noter que SimilarWeb est un service qui fournit des estimations de trafic basées sur une analyse déductive et non sur des données officielles. Cependant, sa fiabilité augmente considérablement pour les sites à très fort trafic , où les estimations se rapprochent de la réalité . Cette observation repose également sur notre expérience directe : à plusieurs reprises, nous avons comparé les données estimées par SimilarWeb avec les données réelles et certifiées de Google Analytics de certains de nos clients à fort trafic, et constaté une remarquable cohérence et fiabilité des projections fournies par le service.

Un tel volume de trafic exigeait une infrastructure robuste , avec des systèmes de cache multiniveaux , des bases de données optimisées, des équilibreurs de charge et probablement l'utilisation d'un réseau de diffusion de contenu (CDN) pour distribuer les ressources statiques à l'échelle mondiale. Malgré cela, le site est resté extrêmement réactif, signe d'une optimisation technique méticuleuse. C'est précisément cette combinaison d' architecture haute performance , de bases de données optimisées et d'une scalabilité horizontale qui a permis à Phica.eu de supporter des volumes de trafic massifs pendant des années sans présenter de faiblesses notables.

Phica.eu, pas seulement un forum mais aussi un service de streaming vidéo

Outre son statut de vaste forum basé sur XenForo , Phica.eu se distinguait également par son intégration de contenu multimédia dans les discussions et les commentaires des utilisateurs. Le mode opératoire le plus courant consistait à intégrer des vidéos provenant de portails externes : les utilisateurs inséraient des liens ou des lecteurs intégrés de plateformes tierces, reproduisant ainsi une dynamique similaire à celle de YouTube, Vimeo et d’autres plateformes plus confidentielles.

Cependant, Phica.eu ne s'est pas arrêté là : le portail disposait de sa propre infrastructure serveur dédiée à la distribution directe des vidéos, organisée sous forme de CDN auto-hébergé . Ce réseau était très visible du public et structuré sur plusieurs nœuds dédiés , identifiables par des domaines tels que :

• cdn1.phica.eu

• cdn2.phica.eu

• cdn3.phica.eu
  …et ainsi de suite, pour un total de une dizaine de serveurs dédiés exclusivement à la gestion de contenu multimédia. Ces nœuds hébergeaient fichiers vidéo classiques — généralement dans Formats .mov et .mpeg — et offrait des fonctionnalités similaires à celles du vidéo à la demande rudimentaire, Mais ce n'était pas du vrai streaming.

La différence est substantielle :

• Le streaming vidéo en temps réel utilise des protocoles modernes comme HLS , MPEG-DASH ou RTSP , qui divisent le contenu en segments chargés dynamiquement . Cela permet à l'utilisateur d' avancer ou de reculer dans la vidéo sans avoir à télécharger intégralement les parties intermédiaires, réduisant ainsi les temps d'attente et la consommation de bande passante.

• Le système adopté par Phica.eu → ce CDN amateur fonctionnait comme un dépôt de fichiers statiques . Lorsqu'un utilisateur souhaitait, par exemple, accéder directement à la fin d'une vidéo , le fichier entier devait avoir été téléchargé jusqu'à ce point. Cela entraînait une charge serveur plus importante , une consommation de bande passante élevée et une expérience moins fluide que les plateformes de streaming modernes.

Cette infrastructure distribuée, composée d' intégrations de contenu externe et d'une dizaine de nœuds CDN propriétaires , a permis à Phica.eu de gérer des centaines de téraoctets de contenu vidéo et a largement contribué à son trafic impressionnant , estimé à environ 100 millions de pages vues par mois . La présence d'un CDN dédié d'une telle envergure démontre la complexité technique du projet , bien au-delà d'un simple forum : il reposait sur une infrastructure structurée, optimisée et constamment mise à l'échelle pour supporter des millions d'utilisateurs actifs et des milliards de requêtes mensuelles.

Bénéfices estimés et réels de Phica.eu

L'un des aspects les plus controversés de l' affaire Phica.eu concerne les revenus générés par le portail au fil des ans. D'après les estimations du marché pour les sites pour adultes ayant un trafic similaire, le chiffre d'affaires est calculé à l'aide du RPM ( Revenu pour Mille ), qui correspond au revenu moyen généré pour 1 000 pages vues . Pour les plateformes de ce type, les estimations les plus fiables indiquent une valeur moyenne comprise entre 1 et 2 euros pour 1 000 vues , avec des pics pouvant atteindre 3 euros selon la qualité du trafic et les sources publicitaires.

En restant dans le scénario le plus prudent , soit 1 euro pour 1 000 pages vues , et en tenant compte des quelque 70 millions de pages vues mensuelles estimées par SimilarWeb, Phica.eu aurait pu générer au moins 70 000 euros par mois , soit environ 840 000 euros par an . Cependant, au vu d'analyses plus approfondies et de certaines rumeurs parues dans la presse, l'hypothèse d'un RPM moyen de 2 euros semble plus réaliste : cela représenterait environ 140 000 euros de revenus mensuels et plus de 1,6 million d'euros de revenus annuels.

Un indice important étayant cette seconde hypothèse provient de l'analyse des données de Hydra Group Eood , une des sociétés identifiées comme « partie liée » à l'infrastructure de Phica. Cette société, immatriculée à Sofia avec un capital social de seulement 50 euros , a déclaré un chiffre d'affaires dépassant 1,3 million d'euros ( 1 369 296,48 euros précisément ). Cette disproportion manifeste suggère que des structures apparemment modestes peuvent devenir des nœuds centraux au sein d'architectures numériques complexes , faisant transiter des capitaux considérables par des réseaux distribués.

Les mêmes analystes, Valerio Lilli et Lorenzo Romani , ont contribué à reconstituer les structures et les liens d'affaires liés à Phica.eu , en utilisant des sources ouvertes et des outils d'analyse de réseau , notamment la base de données Whois . Bien que de nombreux domaines soient protégés par des services de masquage de noms de domaine (par exemple, GoDaddy Domains by Proxy), le recoupement des métadonnées et des enregistrements leur a permis de retracer des liens importants entre des personnes, des entreprises et des infrastructures. Il est important de souligner qu'il ne s'agit pas d'une preuve définitive de propriété , mais plutôt d'hypothèses plausibles fondées sur des éléments techniques et documentaires disponibles en ligne , qui révèlent un écosystème financier bien plus structuré qu'il n'y paraît.

NOTE COMPLÉMENTAIRE DU 24/09/2025

Aujourd'hui, après avoir visionné indépendamment l'épisode « THE PHICA CASE » de l'émission Corona On AIR – Falsissimo , nous avons appris que Hydra Group EOOD et son administrateur Roberto Maggio ne sont aucunement impliqués dans l'affaire Phica.eu.

Leur implication présumée, maintes fois soulignée par divers journaux et analystes du secteur, doit donc être considérée comme le fruit d'une tromperie manifeste. Bien que nous considérions jusqu'à présent cette affirmation comme avérée et donc comme une « vérité présumée », elle a récemment été clairement et sans équivoque démentie.

Cette note est rédigée en état de légitime défense, afin de sauvegarder la véracité des faits et de protéger les personnalités mentionnées ici, qui ne doivent en aucun cas être associées à cette affaire.

Compte tenu de l'indexation importante de l'article original, nous avons estimé nécessaire de publier cette mise à jour supplémentaire afin que les lecteurs soient également correctement informés de l'erreur, qui s'est malheureusement propagée et a été largement rapportée par une grande partie de la presse italienne.

Le système d'anonymat brut, basé sur CloudFlare.

Compte tenu de la nature sensible et risquée du contenu diffusé par Phica.eu , son fondateur savait qu'il s'exposait à des plaintes, des poursuites judiciaires et d'éventuelles poursuites pénales . C'est pourquoi il a cherché à se protéger en adoptant Cloudflare comme couche d'anonymat et de défense. Cloudflare est un réseau de diffusion de contenu (CDN) et un service de proxy inverse qui, entre autres fonctionnalités, permet de masquer l'adresse IP réelle du serveur d'origine : au lieu d'afficher l'adresse IP de l'hébergeur, les visiteurs voient les adresses IP de Cloudflare , qui s'interpose entre l'utilisateur et le serveur, filtrant le trafic, gérant la mise en cache et offrant une protection contre les attaques DDoS.

Dans ce scénario, toute personne effectuant une requête HTTP vers Phica.eu ne communique jamais directement avec le serveur réel, mais avec des nœuds Cloudflare qui redirigent ensuite la connexion vers le serveur d'origine. Cette approche garantit apparemment un certain degré d'anonymat aux administrateurs du portail, car un utilisateur tentant de retracer l'adresse IP du serveur réel ne verra que les adresses IP publiques de Cloudflare.

Il est toutefois important de comprendre le fonctionnement de la politique de gestion des « abus » de Cloudflare . Lorsqu'un utilisateur – par exemple, une jeune fille découvrant que ses photos privées sont publiées sur Phica.eu sans son consentement – ​​envoie à Cloudflare une demande de retrait pour violation de droits d'auteur (DMCA) ou un signalement d'abus , Cloudflare n'intervient pas directement sur le contenu . Conformément à sa politique de neutralité du net , le service agit comme un simple intermédiaire technique : il reçoit le signalement, identifie l'adresse IP réelle du serveur d'origine et transmet la requête au fournisseur d'hébergement qui gère ce serveur.

Par exemple, si le serveur Phica.eu était hébergé par un fournisseur hypothétique comme « ACME SpA » , et que l’adresse IP réelle était masquée derrière les adresses IP publiques de CloudFlare, le flux serait le suivant :

Cela signifie que Cloudflare ne fermera jamais le site ni ne bloquera les contenus litigieux, car il ne l'héberge pas et, conformément à sa politique interne et au principe de neutralité du Net, ne le modère pas activement. La responsabilité d'évaluer les violations et d'entreprendre toute action légale ou technique incombe toujours au fournisseur gérant le serveur d'origine . Dans le cas de Phica.eu , cette situation a rendu plus difficile une intervention rapide contre le portail, notamment si le fournisseur de l'infrastructure se montrait négligent ou inactif face aux signalements d'abus.

Responsabilité du fournisseur d'origine derrière CloudFlare

Dans un scénario comme celui analysé, le point crucial est d'identifier le fournisseur d'origine , c'est-à-dire l'hébergement réel derrière la protection de CloudFlare , et de comprendre comment il décide d'agir lorsqu'il reçoit des signalements d'abus.

La législation italienne applicable est le décret législatif 70/2003 , qui transpose la directive européenne 2000/31/CE relative au commerce électronique. Plus précisément, les articles 14, 15 et 16 disposent que :

• Un fournisseur d'hébergement n'est pas responsable pénalement ou civilement du contenu téléchargé par ses clients tant qu'il n'a pas connaissance de son caractère illégal.

• La responsabilité commence lorsque l'hébergeur reçoit une notification officielle (telle qu'un signalement d'abus , une notification DMCA ou une plainte pour violation de droits d'auteur ou de la vie privée ).

• Dès l'instant où le fournisseur a connaissance d'un contenu illégal , il est tenu de le supprimer ou d'en empêcher l'accès , sous peine de poursuites civiles ou pénales pour «complicité» dans la diffusion de contenu illégal.

Dans le cas de Phica.eu , lorsque CloudFlare a reçu un signalement d'abus, la plateforme n'a pas supprimé le contenu (conformément à sa politique de neutralité ), mais a transmis la demande au fournisseur d'origine qui hébergeait physiquement le site. À ce stade, l'hébergeur était confronté à trois scénarios possibles :

1. Ignorer délibérément le rapport

   • Certains fournisseurs, notamment ceux enregistrés dans des pays à la législation permissive , choisissent délibérément de ne pas intervenir . Cela permet au portail de rester en ligne pendant des années, malgré les demandes de retrait.

2. Accepter les justifications du client

   • Souvent, suite à une notification de Cloudflare, le fournisseur informe le propriétaire du site et lui demande des explications. Si le client fournit des raisons techniques ou juridiques jugées plausibles par l'hébergeur, ce dernier peut décider de ne pas suspendre le service.

3. Intervenir en suspendant ou en masquant le service

   • En théorie, si le client ne répond pas ou ne fournit pas de justification valable, le fournisseur devrait désactiver le compte , supprimer le contenu ou coopérer avec les autorités compétentes.

En pratique, ce mécanisme fonctionne comme un bouche-à-oreille technique :

• CloudFlare reçoit une notification →

• Transmettez-le au fournisseur d'origine →

• Le fournisseur informe le client final →

• Le client doit répondre →

• Le fournisseur décide de suspendre, d'ignorer ou de maintenir le service.

Cela signifie que le client final est toujours informé des signalements d'abus : le fournisseur est formellement tenu de les transmettre . Toutefois, si l'hébergeur ne réagit pas ou décide de croire les justifications du client , le site reste en ligne.

Dans le cas de Phica.eu , il apparaît donc probable et plausible que le fournisseur d'origine derrière CloudFlare ait :

• délibérément ignoré les nombreuses demandes de retrait,
  ou

• ont accepté les justifications fournies par le gestionnaire, permettant ainsi au portail de rester opérationnel pendant près de vingt ans malgré des dizaines de plaintes.

Le décret législatif 70/2003 souligne un point fondamental : un hébergeur n’est jamais pénalement responsable tant qu’il n’a pas connaissance du préjudice . Mais dès qu’il en a connaissance, il est tenu d’agir . S’il manque à cette obligation, sa responsabilité – au moins civile – lui incombe également.

Quel est le fournisseur d'origine derrière Phica.eu ?

Pour comprendre l'origine du site Phica.eu et son hébergeur, il est essentiel de partir d'un principe fondamental : ce site n'est pas apparu ex nihilo. Son histoire est longue et, pour mener une analyse OSINT sérieuse, il est indispensable de reconstituer l'historique complet de son infrastructure technique.

Le forum Phica a été officiellement lancé en août 2005 sous le nom de domaine phica.net . Au fil des ans, il est progressivement devenu l'un des plus importants forums italiens dédiés au contenu pornographique et, surtout, aux contenus non consensuels, au point d'être considéré comme une plateforme de revenge porn . Pendant près de 17 ans , phica.net a été le principal point d'accès à la plateforme, accumulant des millions de messages et des centaines de milliers d'utilisateurs inscrits.

Puis, en 2022 , un changement stratégique important s'est produit : phica.net a commencé à rediriger automatiquement vers phica.eu . Ce changement, en apparence anodin, revêt une importance technique précise. Il pourrait être lié à plusieurs raisons, notamment :

• Tenter d' éviter d'éventuelles saisies ou blocages juridiques.

• À la recherche d’une infrastructure plus sécurisée pour se protéger contre les enquêtes et les cyberattaques.

• Volonté de réorienter les opérations vers un fournisseur européen et, vraisemblablement, d'exploiter des juridictions plus favorables.

Identifier le fournisseur d'origine de phica.eu n'est pas chose aisée, d'autant plus que le site utilise actuellement Cloudflare pour sa sécurité. Cloudflare agit comme un proxy inverse et masque l'adresse IP réelle du serveur, dissimulant ainsi l'identité du fournisseur hébergeant physiquement le forum. Cependant, grâce à une stratégie OSINT bien structurée, il est possible de reconstituer plusieurs pistes historiques.

1. Pourquoi l'analyse doit commencer par phica.net

Pour retracer l' origine de phica.eu , il ne suffit pas d'analyser l'infrastructure actuelle : il faut remonter aux origines, lorsque la plateforme utilisait phica.net . C'est essentiel car, de 2005 à 2022, le forum fonctionnait sans accorder la même importance à la protection de la vie privée qu'aujourd'hui.

L'enquête OSINT se déroule donc en trois étapes principales :

1. Analyse historique du domaine phica.net pour comprendre où il était hébergé durant ses premières années.

2. Suivi des migrations ultérieures jusqu'à la transition vers phica.eu.

3. Analyser les couches de protection actuelles et identifier les faiblesses potentielles qui révèlent l'infrastructure d'origine.

2. Les premières années de phica.net (2005 → 2010)

L'analyse des enregistrements DNS historiques montre que phica.net , à ses débuts, était hébergé en Italie par Serverplan , un fournisseur connu pour proposer des services abordables et une infrastructure simple.

Ces informations ont été obtenues à l'aide d'outils OSINT tels que :

• SécuritéTrails

• RiskIQ PassiveTotal

• DNSdumpster

Ces bases de données conservent les anciens enregistrements A et nous permettent de reconstituer les variations historiques des adresses IP.

Durant cette phase initiale, phica.net n'utilisait aucune sécurité avancée ; les serveurs répondaient directement et l'adresse IP était publique. Il est probable qu'une quantité importante d'informations ait été collectée pendant cette période, notamment les fournisseurs d'accès, les centres de données et les configurations utilisées.

3. Le déménagement à l'étranger : la France et le Canada

Après quelques années, vraisemblablement pour accroître son anonymat et se protéger d'éventuelles enquêtes italiennes, phica.net a transféré son infrastructure en France . L'hébergement y a été temporaire, probablement sur des serveurs dédiés ou des VPS à fort trafic.

Par la suite, le forum s'est installé définitivement au Canada , où il a établi son siège permanent pendant plusieurs années. L'analyse des informations DNS indique qu'à ce stade, le fournisseur le plus probable est OVH , l'un des géants européens de l'hébergement web, qui possède d'immenses centres de données en France et au Canada.

Le choix d' OVH n'est pas surprenant : le groupe figure parmi les plus grands opérateurs européens et jouit d'une solide réputation pour ses infrastructures performantes et évolutives, ainsi que pour ses politiques de confidentialité relativement favorables aux personnes souhaitant préserver leur anonymat. Toutefois, un aspect intéressant se dégage du point de vue des enquêtes : OVH possède également une filiale commerciale en Italie . Cette présence dans le pays pourrait constituer un point d'accès stratégique pour les forces de l'ordre italiennes , qui pourraient s'appuyer sur ce bureau local pour demander officiellement des données et des informations dans le cadre d'une enquête, conformément aux procédures établies par la coopération judiciaire internationale.

OVH est souvent choisi pour les forums de ce type pour trois raisons principales :

1. Des coûts faibles par rapport aux autres fournisseurs de même niveau.

2. Une bande passante élevée est essentielle pour gérer des centaines de milliers d'images et de vidéos.

3. Protection partielle des données et difficulté accrue pour les autorités étrangères d'intervenir rapidement, même si – grâce au siège italien – les forces de l'ordre disposeraient désormais d'une plus grande marge de manœuvre qu'auparavant.

4. Présentation de Cloudflare

Face à la popularité croissante du forum et aux polémiques grandissantes qu'il suscitait, phica.net a décidé d'adopter Cloudflare comme couche de protection intermédiaire. Dès lors, toutes les requêtes adressées au domaine transitent par l'infrastructure de Cloudflare, qui agit comme un proxy inverse et masque l'adresse IP réelle du serveur.

D'un point de vue OSINT, cela introduit un obstacle majeur :

• Il n'est plus possible d'obtenir l'adresse IP d'origine via une simple recherche DNS.

• Les outils de base tels que dig, nslookup o whois Ils renvoient uniquement les adresses IP liées à Cloudflare.

Cette étape marque le début d'une stratégie de protection active de la part du forum, qui devient beaucoup plus difficile à suivre.

5. Migration vers phica.eu (à partir de 2022)

Le tournant s'est produit en 2022 : le domaine principal est devenu phica.eu . Tout le trafic provenant de phica.net a été redirigé via une redirection 301 vers la nouvelle extension européenne.

Les raisons peuvent être multiples :

• Évitez les listes noires ou les saisies de domaines .net.

• Cherchez une juridiction plus favorable.

• Migrez vers une nouvelle infrastructure plus sécurisée et distribuée.

À partir de là, phica.eu reprend l'intégralité de l'infrastructure existante, tout en la renforçant par une couche de protection supplémentaire. Là encore, le trafic est acheminé via Cloudflare , qui masque complètement l'adresse IP d'origine.

6. Comment trouver le serveur d'origine derrière Cloudflare

Bien que Cloudflare protège l'adresse IP réelle, des techniques OSINT avancées permettent d'identifier l'expéditeur. Parmi les principales, on peut citer :

a) DNS passif et SecurityTrails

• Nous analysons les anciens enregistrements DNS liés à phica.net avant l'adoption de Cloudflare.

• Souvent, les anciennes adresses IP restent associées au domaine même après le changement.

b) Énumération des sous-domaines

• En analysant les sous-domaines actifs et inactifs, vous pouvez identifier les points de terminaison qui ne transitent pas par Cloudflare et révéler leur véritable adresse IP.

• Des outils comme Amass , Subfinder ou crt.sh peuvent être utiles.

c) Analyse du certificat SSL

Grâce à une analyse approfondie des certificats numériques, nous avons découvert que plusieurs sous-domaines de phica.eu possèdent des certificats Let's Encrypt actifs . Pour obtenir cette information, nous avons utilisé crt.sh , un service public permettant de consulter le journal de transparence des certificats et d'afficher tous les certificats SSL émis pour un domaine donné.

Cette découverte est particulièrement intéressante car si l'un de ces sous-domaines n'était pas protégé par Cloudflare – par exemple, un point de terminaison secondaire, un ancien panneau d'administration ou un service interne exposé – il pourrait révéler directement l'adresse IP du serveur d'origine.

Connaître la véritable adresse IP nous permettrait d'identifier le fournisseur hébergeant l'infrastructure, contournant ainsi le niveau de protection offert par Cloudflare et facilitant grandement la connexion de phica.eu à son infrastructure physique.

d) Shodan et Censys

En saisissant phica.net ou phica.eu sur Shodan, vous trouverez :

• • Les anciens points de terminaison sont restés actifs.

  • Services exposés.

  • Informations sur le véritable fournisseur.

7. Les failles découvertes dans l'infrastructure

Lors de l'analyse OSINT du forum, d'importantes vulnérabilités sont apparues :

• Plans de site publics non protégés : Plus de 981 000 pages librement indexées.

• Adresses électroniques claires associées aux utilisateurs : environ 791 000 profils enregistrés, dont beaucoup contiennent des données personnelles visibles.

• Services obsolètes détectés via Shodan , avec des failles de sécurité potentielles connues.

• Risque d'injection SQL dû à un logiciel obsolète.

Ces détails révèlent non seulement des problèmes de confidentialité pour les utilisateurs, mais ouvrent également des scénarios potentiels pour identifier les serveurs réels grâce à l'analyse des journaux, des appels directs et des anciennes versions des sous-domaines.

8. La situation actuelle

Aujourd'hui, phica.eu fonctionne grâce à une infrastructure robuste :

• Cloudflare protège l'origine contre les attaques DDoS et masque sa localisation.

• Votre DNS principal et vos sous-domaines passent tous par le proxy Cloudflare.

• Le fournisseur d'origine est très probablement un grand opérateur européen ou nord-américain, OVH restant le candidat le plus probable compte tenu de l'historique du domaine et de sa proximité géographique avec le siège européen de Cloudflare.

Toutefois, la présence des sous-domaines Gmail et Google Workspace suggère que certaines communications par courriel sont gérées par Google, ce qui représente un point d'entrée potentiel pour les enquêtes.

Découvrir le fournisseur d'origine de phica.eu n'est pas chose aisée. Le changement de domaine, l'adoption de Cloudflare et la structure distribuée des sous-domaines complexifient l'enquête. Toutefois, reconstituer l'historique complet du forum à partir de phica.net révèle des détails importants :

• Durant les premières années, le site était hébergé en Italie (Serverplan).

• Elle s'est ensuite déplacée en France puis finalement au Canada , probablement chez OVH.

• Depuis 2022, avec la création de phica.eu , toute l'infrastructure est passée derrière Cloudflare.

• L'analyse OSINT du DNS, des sous-domaines, des certificats SSL et de Shodan indique que le fournisseur d'origine actuel pourrait toujours être OVH ou un pair.

En d'autres termes, bien que Cloudflare masque désormais sa véritable adresse IP, les données historiques et les preuves techniques suggèrent que la « société mère » du forum est restée globalement inchangée : une infrastructure à hautes performances, très probablement basée sur des serveurs dédiés situés en Europe, OVH étant le principal candidat.

Comment ce site à l’épreuve des renseignements était-il censé fonctionner pour ne pas être découvert ?

L'analyse de l'infrastructure de phica.eu et de son évolution depuis l'ancien phica.net révèle plusieurs erreurs structurelles, entraînant des conséquences techniques, administratives et commerciales . Malgré l'utilisation actuelle de Cloudflare comme système de sécurité, cette solution reste rudimentaire et présente toutes les limitations inhérentes. Si Cloudflare masque efficacement l'adresse IP d'origine et protège le site contre les attaques DDoS, il ne suffit pas à garantir une infrastructure inviolable , capable de résister à des enquêtes coordonnées menées dans plusieurs juridictions.

Pour comprendre comment phica.eu a pu devenir quasiment intraçable, il faut remonter aux erreurs initiales commises à l' époque de phica.net . Durant les premières années, le forum était hébergé par des fournisseurs italiens comme Serverplan , laissant des traces commerciales évidentes : paiements traçables, factures au nom des utilisateurs et données personnelles associées aux comptes. À cette époque, les cryptomonnaies n'existaient pas encore ; les paiements s'effectuaient donc presque exclusivement par virement bancaire, carte de crédit ou systèmes traditionnels , autant de moyens facilement accessibles aux forces de l'ordre. Ce choix initial a créé une chaîne de preuves historiques qu'il est aujourd'hui impossible d'effacer.

Une infrastructure véritablement sécurisée aurait nécessité une approche très différente, non seulement technique mais aussi juridique . La sécurité opérationnelle d'un tel système repose sur deux piliers :

1. Protection multicouche des infrastructures.

2. Exploitation des juridictions favorables et de leurs conflits juridiques avec d'autres pays.

D'un point de vue technique, la solution la plus efficace n'aurait pas consisté à s'appuyer uniquement sur Cloudflare comme unique point d'entrée. Il aurait été nécessaire d'ajouter au moins deux niveaux de protection supplémentaires , en établissant un système de routage du trafic entre différents pays et différents fournisseurs, et en tirant parti des difficultés juridiques liées aux juridictions internationales.

Un exemple d’architecture plus robuste :

• Première couche : Point de terminaison public protégé par Cloudflare , qui agit uniquement comme une couche d’obfuscation initiale.

• Deuxième niveau : un proxy inverse offshore situé en Russie , où l’accès aux données par les autorités européennes ou italiennes serait extrêmement difficile. De plus, la Russie est actuellement en conflit avec plusieurs pays européens et membres de l’OTAN, ce qui ralentirait considérablement toute coopération internationale.

• Troisième niveau : Une couche intermédiaire supplémentaire via un fournisseur en Malaisie , pays connu pour héberger des services offshore et pour la difficulté d’obtenir des informations par les voies officielles.

• Quatrième et dernier niveau : Le datacenter actuel tel que nous l'avons estimé dans ce cas comme une option possible d'OVH

Cette double intermédiation technique pourrait être mise en œuvre soit avec des proxys inverses HTTP , soit par une redirection de port plus simple des ports HTTP/HTTPS : dans les deux cas, l'effet serait de masquer complètement le serveur d'origine.

Pour complexifier encore davantage l'analyse, l'infrastructure russe pourrait avoir été hébergée par des entités opaques telles que RBN – Russian Business Network , historiquement connue pour ses activités liées à la cybercriminalité, au darknet et à la protection de sites web à haut risque . Dans ce cas, toute demande officielle émanant des autorités italiennes ou européennes aurait été ignorée ou rejetée, contraignant les forces de l'ordre à tenter une coopération internationale avec des entités hostiles ou délibérément non coopératives.

À ce stade, le trafic provenant des proxys russes serait acheminé vers la Malaisie , qui pourrait à son tour l'envoyer au serveur européen final , par exemple hébergé chez OVH.

Dans ce scénario, si une autorité italienne avait tenté de remonter à l' origine du fournisseur , l'enquête se serait heurtée à une série d'étapes techniques et juridiques complexes :

• Première étape : la requête proviendrait de Cloudflare , qui est le seul point de terminaison visible publiquement.

• Deuxième étape : Cloudflare désignerait un proxy inverse situé en Malaisie comme nœud suivant . Dans ce cas, la coopération internationale serait déjà complexe, car la Malaisie n’adhère pas aux mêmes protocoles d’entraide judiciaire que l’Union européenne.

• Troisième étape : le nœud malaisien pourrait alors acheminer le trafic vers un second proxy situé en Russie . À ce stade, le processus se compliquerait davantage, car la Russie n’est tenue à aucune coopération et, surtout dans le contexte politique actuel, elle a tendance à ignorer les demandes des autorités internationales chargées de l’application de la loi.

• Quatrième étape : ce n’est qu’en franchissant ces niveaux qu’il serait théoriquement possible d’atteindre le serveur d’origine final , que nous avions précédemment supposé hébergé par un fournisseur européen comme OVH . Toutefois, il est peu probable que cela puisse être vérifié, car l’infrastructure à plusieurs niveaux rend extrêmement difficile l’identification précise du fournisseur.

Dans ce modèle, nous commençons donc avec Cloudflare , mais les étapes suivantes introduisent des couches d'opacité technique et juridictionnelle qui rendent l'identification de l'origine extrêmement complexe , rendant pratiquement impossible l'identification du serveur final, garantissant ainsi au forum un niveau d'anonymat quasi total.

En résumé, phica.eu s'appuyait sur un modèle de sécurité monolithique reposant exclusivement sur Cloudflare, offrant une protection minimale et ne résolvant pas les problèmes structurels et juridiques liés à la traçabilité. Une infrastructure véritablement inviolable aurait nécessité une conception plus avancée, exploitant les zones grises juridiques et créant un système de proxy inverse offshore multicouche , rendant impossible ou extrêmement complexe l'obtention de données utiles par le biais de demandes officielles.

Considérations et réflexions sur le travail des forces de l’ordre et des procureurs.

Jusqu'à présent, nous avons analysé la question principalement d'un point de vue technique et systémique , en nous concentrant d'abord sur l'infrastructure de phica.net , puis de phica.eu , les protections mises en place, les vulnérabilités existantes et la manière dont, théoriquement, il aurait été possible de tracer ou de bloquer le site. Cependant, les dernières nouvelles et de nombreuses enquêtes journalistiques soulèvent une question encore plus pertinente : comment un portail de cette envergure, actif pendant près de vingt ans, a-t-il pu rester en ligne sans être inquiété , malgré les dizaines et les dizaines de plaintes déposées au fil des ans par les victimes, leurs familles et des associations ?

Ce manque de réaction de la part des autorités compétentes – parquet, police postale et système judiciaire – soulève des questions légitimes quant au traitement des signalements. Face à un portail comptant plus de 800 000 utilisateurs , près d’un million de pages indexées et une présence massive de contenus potentiellement illicites, on s’attendrait à une enquête concertée , combinant des techniques de renseignement en sources ouvertes (OSINT) avancées , une coopération internationale et des mesures de confinement immédiates.

Les alternatives techniques qui étaient possibles mais jamais mises en œuvre

Outre la localisation du serveur et l'identification de l'opérateur, plusieurs stratégies techniques éprouvées auraient pu rendre phica.eu et phica.net inaccessibles à la majorité des utilisateurs italiens sans attendre la fermeture définitive du portail.

1. Détournement et saisie de DNS

L'une des solutions les plus simples et les plus répandues contre les portails illégaux consiste à recourir au détournement DNS . Cette technique est utilisée depuis des décennies et est couramment employée par les forces de l'ordre lorsqu'un site enfreint la loi.

Le mécanisme est simple :

• L'autorité judiciaire émet un ordre de saisie.

• Les fournisseurs DNS des FAI italiens sont invités à modifier les résolutions des.

• Au lieu de résoudre la véritable adresse IP du portail, le DNS répond par une redirection vers une page de notification signalant la saisie.

Cette mesure n'aurait pas éliminé le site à l'échelle mondiale, mais elle aurait bloqué l'accès à celui-ci pour la plupart des utilisateurs italiens , compliquant considérablement la navigation pour ceux qui ne possèdent pas de compétences avancées et un VPN.

2. Blocage du trafic via des systèmes anti-piratage (technique de blocage IP dynamique)

Une autre solution possible, encore plus efficace, aurait été l’adoption du système déjà utilisé en Italie pour lutter contre le piratage sportif , celui employé contre les portails qui diffusent illégalement des événements de football de Sky et DAZN.

Ce système, appelé « blocage IP dynamique » , plus communément connu sous le nom de « filtre anti-Pezzotto », est géré à la demande de l’AGCOM (l’autorité italienne de régulation des communications) et fonctionne de la manière suivante :

1. Identifiez les adresses IP incriminées en temps réel.

2. AGCOM envoie immédiatement une communication à tous les FAI italiens.

3. Les fournisseurs d'accès Internet mettent en œuvre des règles de routage au niveau du réseau principal, bloquant le trafic vers les adresses IP annoncées.

4. La propagation s'effectue en quelques minutes et le site devient inaccessible à l'échelle nationale , indépendamment des modifications de domaine ou de DNS.

Cette solution aurait été particulièrement efficace dans le cas de phica.eu , car elle aurait pu bloquer l'accès à l'ensemble de l'infrastructure , rendant ainsi inutile toute tentative de changement de domaine ou de migration de serveurs.

Vingt ans d'immobilité

Ce qui est le plus troublant, et même inquiétant , c'est qu'aucune de ces solutions n'ait été mise en œuvre pendant près de 20 ans . D'après les articles de nombreux journaux ayant enquêté sur l'affaire, des dizaines de plaintes ont été déposées au fil des ans : par des victimes individuelles dont les images avaient été diffusées sans leur consentement, par des membres de la famille des personnes impliquées, et même par des associations de défense de la vie privée et de la sécurité en ligne. De plus, plusieurs parquets italiens étaient déjà au courant de l'existence de ce forum et de son extrême dangerosité sociale depuis un certain temps.

Pourtant , phica.net puis phica.eu ont continué à fonctionner sans encombre , sans limitations techniques importantes, connaissant une croissance exponentielle jusqu'à atteindre des chiffres impressionnants :

• Plus de 800 000 utilisateurs inscrits.

• Des millions de messages publiés sur deux décennies.

• Près d'un million de pages contenant des images, des vidéos et des données sensibles provenant de personnes qui n'y prennent pas garde.

Ce silence opérationnel des autorités compétentes soulève des questions inquiétantes. D'une part, le parquet était déjà au courant du phénomène. D'autre part, les différentes unités de police spécialisées , notamment la police postale et celles dédiées à la cybercriminalité , n'ont mis en œuvre aucune mesure concrète pour endiguer le problème. Par exemple, rien n'indique que les mesures suivantes aient été prises :

• Blocage de domaine par détournement DNS.

• Interventions ciblées sur le trafic réseau via le blocage dynamique des adresses IP.

• Blackout sélectif des infrastructures du site par le biais des voies judiciaires internationales.

Cette inertie opérationnelle a permis au forum de renforcer progressivement son infrastructure, en passant de phica.net à phica.eu , en adoptant Cloudflare comme couche de sécurité et en rendant plus difficile le traçage des serveurs d'origine. Pendant près de vingt ans, les autorités se sont montrées incapables – ou peu disposées – à agir efficacement.

Le tableau devient encore plus inquiétant lorsqu'on apprend que la situation ne s'est résolue qu'après une forte mobilisation politique et médiatique . Les déclarations publiques de certaines personnalités institutionnelles , dont la Première ministre Giorgia Meloni , ont exercé la pression nécessaire pour inciter le parquet et les forces de police à intervenir.

C’est uniquement grâce à cette impulsion politique , et non à une intervention autonome de la police, que les autorités ont pris en seulement 48 heures les mesures nécessaires pour bloquer et mettre hors ligne un portail qui fonctionnait sans interruption depuis plus de vingt ans.

Cette dynamique met en évidence deux aspects critiques :

1. Le manque de coordination entre les parquets et les services de police spécialisés.

2. L’absence de stratégie proactive face aux phénomènes numériques complexes, qui ne sont abordés qu’après une explosion médiatique et non sur la base des nombreuses plaintes antérieures.

Conclusions

Cette affaire met en lumière une grave défaillance systémique dans la gestion des plaintes, la coopération entre les procureurs et la réactivité des autorités compétentes . Il ne s'agit pas d'un simple problème technique, mais d'une combinaison de stratégies d'enquête inadéquates , d'un manque de coordination entre les services et d'une absence de planification opérationnelle pour lutter contre la cybercriminalité complexe, qui exige des réponses rapides et intégrées.

L’histoire de phica.net et phica.eu nous offre cependant deux pistes de réflexion : d’une part, elle met en lumière des erreurs et des défaillances institutionnelles ; d’autre part, elle fournit un aperçu utile pour comprendre deux aspects fondamentaux :

1. Comment mettre en place des systèmes véritablement anonymes et robustes , d'un point de vue technique et infrastructurel.

2. Quelles techniques OSINT et quels outils d'analyse sont disponibles aujourd'hui pour examiner en profondeur l'infrastructure d'un site web ?

D'un point de vue strictement technique, des outils comme le détournement DNS ou le blocage dynamique d'adresses IP auraient permis une intervention bien plus précoce : deux méthodes éprouvées qui auraient pu limiter considérablement l'accès au portail, protégeant ainsi des centaines de milliers de victimes et limitant l'impact social . La première, le détournement DNS , est utilisée depuis des années pour bloquer les domaines illégaux en modifiant la résolution DNS chez les fournisseurs d'accès à Internet. La seconde, le blocage dynamique d'adresses IP – déjà largement utilisé pour lutter contre le piratage sportif et géré en collaboration avec l'AGCOM – aurait pu intervenir au niveau du réseau national, empêchant en temps réel le trafic d'être acheminé vers les adresses IP associées à phica.eu , indépendamment de tout changement de domaine.

Ces outils étaient déjà disponibles, et qui plus est : ils ont été largement testés ces dernières années dans d’autres contextes complexes. La technologie existait , de même que l’ expertise technique nécessaire à une intervention rapide et coordonnée. Pourtant, pour des raisons mêlant inertie bureaucratique, manque de vision stratégique et, probablement, absence de volonté politique et judiciaire , rien n’a été fait jusqu’à ce que l’affaire éclate dans les médias.

Parallèlement, l'analyse OSINT menée sur cet incident présente également un intérêt pédagogique et technique . Des outils tels que :

• Shodan et Censys pour identifier les services exposés, les certificats SSL et les vulnérabilités potentielles.

• SecurityTrails et RiskIQ PassiveTotal permettent de reconstituer l'historique DNS et les anciennes adresses IP associées au domaine.

• crt.sh permet d'analyser les certificats émis pour les sous-domaines et de détecter les points de terminaison cachés.

• Énumération des sous-domaines et analyse du plan du site pour découvrir les informations accessibles au public.

L'utilisation correcte de tous ces outils démontre qu'il est possible, même de l'extérieur, de recueillir des informations techniques importantes et de structurer une enquête détaillée. Le fait qu'un seul chercheur indépendant en OSINT ait pu identifier des failles et des traces laissées en ligne pendant des années prouve que cette expertise existait , mais n'a pas été exploitée par ceux qui en avaient les moyens et l'autorité.

Au vu des événements, il apparaît clairement que le problème ne résidait pas dans un manque de technologies ou d'outils d'enquête : tous étaient déjà disponibles, et même, dans certains cas, perfectionnés au fil des années d'utilisation. Ce qui a probablement fait défaut, c'est une véritable volonté politique et judiciaire d'agir rapidement , ainsi qu'une coordination opérationnelle efficace entre les parquets, les autorités de contrôle et les unités de police spécialisées.

La leçon à tirer est double :

• Sur le plan défensif , les gestionnaires de plateformes doivent comprendre qu'un anonymat complet exige des choix d'infrastructure beaucoup plus complexes qu'une simple protection avec Cloudflare, car chaque erreur passée (paiements traçables, journaux non protégés, DNS non obscurci) laisse des traces qui peuvent refaire surface même des années plus tard.

• Sur le plan des enquêtes , les forces de l'ordre disposent désormais d'outils OSINT extrêmement puissants qui, utilisés systématiquement, permettent de cartographier en détail une infrastructure complexe et de mener des enquêtes judiciaires plus rapides et plus efficaces.

En résumé, ce cas démontre à quel point l'écart entre ce qui était techniquement possible et ce qui a été réellement fait est énorme, et représente un problème qui va bien au-delà de phica.eu , affectant l'ensemble de l'approche institutionnelle de la gestion des crimes numériques complexes.