Analysis of the Phica.eu case from a technical and systems perspective

The site Phica.eu (born as Phica.net), active continuously by 2005 to 2025, was one of the most controversial Italian portals for twenty years, becoming sadly known for having hosted thousands of photos of women published without consent. The contents included images of well-known personalities, like Giorgia Meloni, Elly Schlein, Chiara Ferragni and Alessandra Moretti, but above all photos of ordinary women, girlfriends, wives and even minor children, in some cases stolen from social media or taken secretly, in others collected through private sharingMany of these photos portrayed the victims in suggestive poses, Until you get to completely explicit shots, widespread without the protagonists' knowledge.

Despite dozens and dozens of complaints presented over the years, the site has remained online for two decades, raising questions and suspicions not only among the victims, but also among acquaintances, colleagues, IT enthusiasts and simply curious peopleHow is it possible that a portal of this type was able to operate undisturbed for so long, without the authorities being able to intervene effectively?

In continuation of this post we will provide our technical vision of the story: we will analyze How hosting services that allow the survival of illegal portals work, we will explain the mistakes made by the Italian founder which allowed their identification and we will highlight the shortcomings, delays and responsibilities of the Italian Public Prosecutor's Offices and the bodies responsible for controlWe will not address the issue from the point of view ethical and moral, certain that the legal corpus can do so with greater authority and competence.

Phica.eu, the XenForo forum with almost a million members.

Phica.eu was not simply a website, but a real large forum, based on XenForo 2, one of the world's most powerful and popular commercial platforms for managing online communities. XenForo is developed in PHP and leans on a MySQL-compatible DBMS — like Tap Server o MariaDB — designed to handle heavy workloads and optimized for very high-traffic scenarios. Born as natural evolution of vBulletin, XenForo inherits part of its architectural bases but introduces significant improvements, both in terms of performance and functionality.

The platform is particularly famous for its advanced community management features, the modern user interface and the ability to integrate extensions, plugins and advanced caching systems. But the real strength of XenForo is the optimized SQL query handling: the engine is able to manage thousands of simultaneously connected users and support database with billions of posts, maintaining extremely short response times. A well-configured installation, supported by an adequate infrastructure, allows you to achieve levels of scalability and reliability difficult to match by other competing software.

In the specific case, Phica.eu represented a extreme example of exploitation of these potentialities: the forum hosted a few million active discussions, with several billion total page reads accumulated over the years. According to public estimates, SimilarWeb, the traffic generated was huge, around 6 million monthly visits, with an average of 12 pages visited for each single visit, and a total of around 70 million page views per month, a value that placed it among the most visited portals in Italy, comparable in numbers to the main national news sites. Added to this was a registered userbase of approximately 800.000 members, which made it one of the Europe's largest online communities in his sector.

It should be noted that SimilarWeb It is a service that provides traffic estimates based on deductive analysis and not official data. However, its reliability increases significantly in the case of very high traffic sites, where the approximations tend to to border on realityThis consideration is also based on our direct experience: on several occasions we have compared the data estimated by SimilarWeb with those real and certified di Google Analytics of some of our high-volume customers, finding a remarkable consistency and reliability of the projections provided by the service.

Such a volume of traffic required a solid infrastructure, with systems multilevel caching, optimized databases, load balancers and probably the use of Content Delivery Network (CDN) to distribute static resources globally. Despite this, the site remained extremely responsive, a sign of careful technical optimization. It is precisely this combination of high-performance architecture, optimized databases e Horizontal scalability which has allowed Phica.eu to sustain significant traffic volumes for years without showing any noticeable weaknesses.

Phica.eu, not only a forum but also video streaming

Besides being a huge forum based on XenForo, Phica.eu It was also distinguished by the integration of multimedia content within discussions and user comments. The most frequent modus operandi involved video embedding coming from external portals: users inserted links or embedded players from third-party platforms, replicating dynamics similar to those of YouTube, Vimeo or smaller repositories.

However, Phica.eu It didn't stop there: the portal also had its own server infrastructure dedicated to the direct distribution of videos, organized as a Self-hosted CDNThis network was clearly visible to the public and structured on more dedicated nodes, identifiable through domains of the type:

• cdn1.phica.eu

• cdn2.phica.eu

• cdn3.phica.eu
  …and so on, for a total of about ten servers dedicated exclusively to the management of multimedia content. These nodes hosted classic video files — generally in .mov and .mpeg formats — and offered similar functionality to the rudimentary video on demand, but it wasn't real streaming.

The difference is substantial:

• Real video streaming → uses modern protocols such as Hls, MPEG-DASH o RTSP, which divide the content into dynamically loaded segments. This allows the user to jump forward or backward in the video without having to completely download the intermediate parts, reducing waiting times and bandwidth consumption.

• System adopted by Phica.eu → the Amateur CDN it worked like a static file repository. When a user wanted, for example, skip directly to the end of a video, it was necessary that the entire file had already been downloaded up to that point. This entailed increased load on servers, high bandwidth and a less fluid experience than modern streaming platforms.

This distributed infrastructure, composed of embedding of external content e approximately ten proprietary CDN nodes, allowed to Phica.eu to manage hundreds of terabytes of video content and contributed significantly to his impressive traffic volumes, estimated around 100 million page views per monthThe presence of such a large dedicated CDN demonstrates how the project was technically more complex of a simple forum: behind it there was a structured, optimized and constantly scaled infrastructure to support millions of active users e billions of monthly requests.

Phica.eu's estimated and actual earnings

One of the most discussed aspects surrounding the case Phica.eu it concerns i earnings generated by the portal over the years. Based on market estimates relating to the adult sites with similar traffic volumes, revenue is calculated using the parameter RPM (Revenue per Thousand), that is, the average revenue obtained every 1.000 page viewsFor platforms of this type, the most reliable estimates indicate an average value that It fluctuates between 1 and 2 euros for every 1.000 views, with peaks that in some cases can even reach 3 € depending on the quality of traffic and advertising sources.

Remaining in the most cautious scenario, namely 1 euro for every 1.000 page views, and taking into account the approximately 70 million pages monthly estimated by SimilarWeb, Phica.eu could have generated at least 70.000 euros per month, equal to approximately 840.000 euros per year. However, considering the most in-depth analyses and some rumours that have appeared in the newspapers, the hypothesis of a Average RPM of 2 euros it seems more realistic: that would mean approximately 140.000 euros of monthly income e over 1,6 million euros in annual revenue.

An important clue to support this second hypothesis comes from the analysis of corporate data Hydra Group Eood, one of the companies identified as “connected party” to the Phica infrastructure. The company, registered in Sofia with a share capital of just 50 euros, he would declared a turnover exceeding 1,3 million euros (to be precise 1.369.296,48 €). An evident disproportion, which suggests how seemingly small structures can become key points inside complex digital architectures, moving very large amounts of capital through distributed networks.

The same analysts, Valerio Lilli e Lorenzo Romani, have helped to reconstruct the corporate structures and connections behind Phica.eu, using open sources and tools network analysis, including the database Whois. Although many domains were protected by services of privacy masking (for example GoDaddy Domains by Proxy), the cross-referencing of metadata and registrations still allowed us to trace significant connections between subjects, companies and infrastructures. It is important to underline that These are not definitive proofs of ownership, But say educated guesses formulated starting from technical and documentary tracks available online, which outline a financially much more structured ecosystem than it might appear from the outside.

SUPPLEMENTARY NOTE OF 09/24/2025

Today, following the independent viewing of the episode “THE PHICA CASE” of the program Corona On Air – Very False, we have learned that Hydra Group EOOD and its director Roberto Maggio are in no way involved in the Phica.eu affair.

Their alleged involvement, repeatedly highlighted by various newspapers and industry analysts, must therefore be considered the result of a clear deception. This circumstance, although until now considered by us to be true and therefore a "putative truth," has recently been clearly and unequivocally denied.

This note is drafted in self-defense, in order to safeguard the truth of the facts and protect the figures mentioned here, who must not be associated in any way with the matter.

Given the significant indexing of the original article, we felt it was necessary to publish this additional update so that readers are also correctly informed of the error, which unfortunately has spread and been widely reported by much of the Italian press.

The crude anonymity system, based on CloudFlare.

For the sensitive and risky nature of the contents covered da Phica.eu, the founder knew he was exposing himself to complaints, complaints e possible criminal liability. For this reason he had tried to protect himself by adopting CloudFlare as a level of anonymity and defense. CloudFlare is a service of Content Delivery Network (CDN) e reverse proxies which, among the various features, allows you to mask the real IP address of the origin server: instead of exposing the actual hosting IP, visitors are shown CloudFlare IPs, which sits between the user and the server, filtering traffic, managing cache, and providing DDoS protection.

In this scenario, whoever makes an HTTP request to Phica.eu never communicates directly with the real server, but with the CloudFlare nodes, which then forwards the connection back to the origin server. This approach apparently guarantees a certain degree of anonymity for those who manage the portal, because a user who tries to trace the IP address of the real server will only see CloudFlare public IPs.

However, it is important to understand How CloudFlare's "Abuse" policy works. When a subject — for example a girl who finds His private photos published on Phica.eu without consent — sends CloudFlare a Copyright Takedown Request (DMCA) or abuse report, CloudFlare does not directly intervene on the contents. For net neutrality policy, the service acts as mere technical intermediary: receives the report, identifies the real IP of the origin server e forward the request to the hosting provider who runs that server.

For example, if the server Phica.eu had been hosted by a hypothetical provider such as “ACME SpA”, and the real IP was masked behind CloudFlare's public IPs, the flow would be like this:

This means that CloudFlare will never shut down your site, nor will it block disputed content, because does not host them and for company policy and Net Neutrality, does not perform active moderation. The task of evaluating violations and taking any legal or technical action always falls to the provider that manages the origin server. In a context like that of Phica.euThis dynamic made it more difficult to take quick action against the portal, especially if the provider behind the infrastructure was complacent or inactive in handling abuse reports.

Origin Provider Responsibility Behind CloudFlare

In a scenario like the one analyzed, the crucial point is identify the origin provider, namely the actual hosting which is behind the protection of CloudFlare, and understand how he decides to operate when receiving reports of abuse.

The Italian legislation of reference is the Legislative Decree 70/2003, which incorporates the European Directive 2000/31/EC on electronic commerce. In particular, Articles 14, 15 and 16 establish that:

• Un Hosting provider is not criminally or civilly liable for content uploaded by its customers, until he is aware of their illicit nature.

• The responsability snaps at the time of hosting receives a formal report (for example a abuse reporta whirlpool bath, DMCA notification or a dispute for copyright or privacy violation).

• From the moment it is aware of the illegal content, the provider has the obligation to remove it or prevent access to it, under penalty of not being able to respond civilly or criminally for “complicity” in the dissemination of illicit material.

In the case of Phica.eu, when CloudFlare received a report of abuse, did not remove the contents (for his neutrality policy), ma forwarded the request to the origin provider which physically hosted the site. At that point, the host faced three possible scenarios:

1. Deliberately ignore the report

   • Some providers, especially if registered in countries with permissive jurisdictions, they consciously decide not to interveneThis allows the portal to remain online for years, despite requests for its removal.

2. Accept the customer's justifications

   • Often, upon receiving notification from CloudFlare, the provider inform the owner of the site and requires explanations. If the customer provides technical or legal reasons that the hosting considers plausible, the provider can decide not to suspend the service.

3. Intervene by suspending or obscuring the service

   • In theory, if the customer unresponsive or does not provide valid justifications, the provider should deactivate the account, remove content or cooperate with the competent authorities.

In practice, the mechanism works as a technical word of mouth:

• CloudFlare receives the report →

• Forward it to the origin provider →

• The provider informs the end customer →

• The customer must respond →

• The provider decides whether to suspend, ignore or maintain the service.

This means that the end customer is always informed of reports of abuse: the provider is formally obliged to transmit them. However, if the hosting it doesn't work o decides to believe the customer's justifications, the site remains online.

In the case of Phica.eu, it appears then probable and plausible that the origin provider behind CloudFlare have:

• deliberately ignored the numerous requests for removal,
  or

• accepted the justifications provided by the manager, allowing the portal to remain operational for almost twenty years despite the dozens of complaints.

Il Legislative Decree 70/2003 highlights a key point: a hosting provider is never criminally liable until it knows. But from the moment he knows, he is obliged to actIf he fails to do so, the liability—at least in civil court—also falls on him.

Who is the originating provider behind Phica.eu?

Talking about Phica.eu and we try to understand who is the originating provider Who actually hosts the forum, we need to start with a fundamental concept: this site didn't emerge from nowhere. Its history goes back a long way, and to conduct a serious OSINT analysis, it's essential to reconstruct the entire history of its technical infrastructure.

The forum Phica was officially born inAugust of the 2005 with the domain phica.net. In those years it gradually became one of the largest Italian forums linked to pornographic content and, above all, non-consensual material, to the point of being defined, in fact, a revenge porn hub. For almost , phica.net represents the main access point to the platform, accumulating millions of posts e hundreds of thousands of registered users.

Then, in 2022, an important strategic step occurs: phica.net start doing automatic redirect to phica.euThis seemingly trivial move has a precise technical meaning. The domain change can be linked to several reasons, including:

• Attempt to evade possible seizures or legal blocks.

• Seeking a more secure infrastructure to protect against cyber investigations and attacks.

• Willingness to shift the operational focus towards a European provider and, probably, to exploit more favorable jurisdictions.

Understand who is the originating provider behind phica.eu It's not easy, especially since today the site relies on Cloudflare as a protection service. Cloudflare acts as reverse proxies and hides the server's real IP address, thus shielding the provider physically hosting the forum. However, with a well-structured OSINT strategy, we can reconstruct several historical traces.

1. Why the analysis must start from phica.net

To go back to the provider origin di phica.eu, we cannot limit ourselves to analyzing the current infrastructure: we have to start from the beginning, when the platform used phica.netThis is essential because in the period 2005 → 2022 The forum operated without the same attention to privacy that it does today.

The OSINT investigation therefore develops in three main steps:

1. Historical analysis of the phica.net domain to understand where it was hosted in the early years.

2. Tracking subsequent migrations until the transition to phica.eu.

3. Analysis of current protection layers and identifying potential weaknesses that reveal the origin infrastructure.

2. The early years of phica.net (2005 → 2010)

Analysis of historical DNS records shows that phica.net, in its early years, was hosted in Italy means Server plan, a provider known for offering affordable services and simple infrastructure.

This information was obtained using OSINT tools such as:

• security trails

• RiskIQ PassiveTotal

• DNSdumpster

These databases store the old A records and allow the reconstruction of historical variations in IP addresses.

During this first phase, phica.net It didn't use any advanced security, the servers responded directly, and the IP address was publicly visible. It's likely that a lot of information was collected during this time, including physical providers, data centers, and configurations used.

3. The move abroad: France and Canada

After a few years, probably to increase anonymity and protect themselves from potential Italian investigations, phica.net migrate your infrastructure to the France. Here he is hosted for a limited period, probably taking advantage of Dedicated Servers o High traffic VPS.

Subsequently, the forum moves permanently to Canada, where it finds its "stable home" for several years. Analyzing the DNS information, it emerges that the most likely provider at this stage is OVH, one of the European hosting giants, which has huge data centers both in France both in Canada.

The choice of OVH It's no surprise: the group is among the largest European operators, with a well-established reputation for offering scalable, high-performance infrastructure and relatively favorable privacy policies for those seeking anonymity. However, there is an interesting aspect from an investigative perspective: OVH also has a commercial branch in ItalyThis presence on the national territory could represent a strategic access point for Italian law enforcement, which could leverage the local headquarters to formally request data and information as part of an investigation, following the procedures provided for by international judicial cooperation.

OVH is often chosen for forums of this type for three main reasons:

1. Costi bassi compared to other providers of the same level.

2. High available bandwidth, essential for managing hundreds of thousands of images and videos.

3. Partial data protection and greater difficulty for foreign authorities to intervene quickly, even if – thanks to the Italian headquarters – law enforcement agencies would now have more leeway to act than in the past.

4. Introducing Cloudflare

With the growing popularity and growing controversy surrounding the forum, phica.net decides to adopt Cloudflare as an intermediate level of protection. From this point on, all requests to the domain go through Cloudflare's infrastructure, which acts as a reverse proxies and masks the real server's IP address.

From an OSINT perspective, this introduces a major obstacle:

• It is no longer possible to obtain the origin IP via a simple DNS lookup.

• The basic tools such as dig, nslookup o whois They only return IP addresses tied to Cloudflare.

This step marks the beginning of a strategy of active protection from the forum, which becomes much more difficult to track.

5. Migration to phica.eu (from 2022)

The turning point comes in 2022: the main domain becomes phica.eu. All traffic from phica.net is redirected via 301 redirect to the new European extension.

The reasons could be many:

• Avoid blacklists or seizures of the .net domain.

• Look for a most favorable jurisdiction.

• Migrate to a new, more secure and distributed infrastructure.

From here on, phica.eu It inherits the entire pre-existing structure but strengthens it with an additional layer of protection. Here too, traffic is channeled through Cloudflare, which completely hides the IP origin.

6. How to find the origin server behind Cloudflare

While Cloudflare protects the real IP address, there are advanced OSINT techniques to attempt to identify the originator. Some of the main ones are:

a) Passive DNS and SecurityTrails

• Old DNS records related to are analyzed phica.net before adopting Cloudflare.

• Often the old IPs remain associated with the domain even after the change.

b) Subdomain Enumeration

• By analyzing active and inactive subdomains, it is possible to identify endpoints that they don't go through Cloudflare and reveal the real IP.

• Tools like amass, Subfinder o crt.sh they can help.

c) SSL Certificate Analysis

We have discovered, through an in-depth analysis of the digital certificates, that they are present Let's Encrypt certificates active for several subdomains di phica.euTo obtain this information we used crt.sh, a public service that allows you to consult the Certificate Transparency Log and view all SSL certificates issued for a given domain.

This discovery is particularly interesting because, even if only one of these subdomains was not protected by Cloudflare – for example a secondary endpoint, an old admin panel or an internal service that has been left exposed – could directly reveal the IP address of the origin server.

Knowing the real IP would allow us to identify the actual provider which hosts the infrastructure, thus bypassing the layer of protection offered by Cloudflare and making it much easier to connect phica.eu to its physical infrastructure.

d) Shodan and Censys

By placing phica.net o phica.eu su Shodan you can identify:

• • Old endpoints remained active.

  • Services on display.

  • Information about the real provider.

7. The flaws discovered in the infrastructure

During the OSINT analysis of the forum, the following emerged: significant vulnerabilities:

• Unprotected public sitemaps: beyond 981.000 pages freely indexed.

• Clear email associated with users: about 791.000 profiles registered, many with personal data visible.

• Services not updated identified through Shodan, with known potential exploits.

• Possible SQL injection due to outdated software.

These details not only reveal privacy concerns for users, but also open up potential scenarios for identifying real servers through analysis of logs, direct calls, and old versions of subdomains.

8. The current situation

Today, phica.eu operates behind a robust infrastructure:

• Cloudflare Protects the origin from DDoS attacks and hides its location.

• Your primary DNS and subdomains all go through the Cloudflare proxy.

• The origin provider is almost certainly a large European or North American operator, with OVH which remains the most likely candidate, given the domain's past history and geographic proximity to Cloudflare's European headquarters.

However, the presence of Gmail subdomains e Google workspace It suggests that some email communications are handled through Google, which represents a potential entry point for investigations.

To discover Who is the originating provider behind phica.eu? This is not a trivial task. The domain change, the adoption of Cloudflare, and the distributed structure of the subdomains make the investigation complex. However, reconstructing the entire history of the forum starting from phica.net, important details emerge:

• In the early years the site was hosted in Italy (Server plan).

• He later moved to France and finally in Canada, probably on OVH.

• From 2022, with the birth of phica.eu, all the infrastructure passes behind Cloudflare.

• OSINT analysis of DNS, subdomains, SSL certificates and Shodan indicates that the current origin provider may still be OVH or a similar provider.

In other words, although today Cloudflare hide the real IP address, historical data and technical evidence suggest that the forum's "parent company" has remained substantially unchanged: a high-performance infrastructure, most likely based on Dedicated Servers located in Europe, with OVH as a leading candidate.

How was this intelligence-proof site supposed to work so as not to be discovered?

Analyzing the infrastructure of phica.eu and its evolution from the old phica.net, it is evident that several structural errors have been made which have left technical, administrative and commercial tracks. Despite the current use of Cloudflare as a protection system, it is a solution pretty basic, with all the limitations that this entails. Cloudflare is effective in mask the origin IP address and protect the site from DDoS attacks, but it is not enough to build an infrastructure intelligence-proof and truly resistant to coordinated investigations across multiple jurisdictions.

To understand how phica.eu could have been made almost impossible to trace, we must start from the initial errors committed at the time of phica.netIn the early years, in fact, the forum was hosted on Italian providers such as Server plan, leaving clear commercial traces: traceable payments, invoices in the name of the customer, and personal data associated with the accounts. At the time, among other things, cryptocurrencies didn't exist, so payments were made almost exclusively via bank transfers, credit cards or traditional systems, all easily accessible to law enforcement. This initial choice has produced a chain of historical evidence which today can no longer be erased.

A real infrastructure armored would have required a very different approach, not only technical, but also legalThe operational safety of a system of this type is in fact based on two pillars:

1. Multi-layered infrastructure protection.

2. Exploitation of favorable jurisdictions and their legal conflicts with other countries.

From a technical point of view, the most effective solution would not have been to rely on only to Cloudflare as the only entry point. It would have been necessary to insert at least two additional levels of protection, building a traffic forwarding path between different countries and different providers, exploiting the legal difficulties arising from international jurisdictions.

An example of more robust architecture:

• First level: Public endpoint protected by Cloudflare, which acts only as an initial obfuscation layer.

• Second level: Un offshore reverse proxy located in Russia, where access to data by European or Italian authorities would be extremely complex. Furthermore, Russia is currently in conflict with several European and NATO countries, and this would significantly slow down any international cooperation.

• Third level: An additional intermediate layer via a provider in Malaysia, a country known for hosting offshore hosting services and the difficulty of obtaining information through official channels.

• Fourth and final level: The actual datacenter as we estimated in this case as a possible OVH option

This double technical intermediation could be implemented both with HTTP reverse proxy either through a simpler port forwarding of HTTP/HTTPS ports: in both cases, the effect would be to completely hide the origin server.

To make the analysis even more complex, the Russian infrastructure could have been hosted by opaque entities such as RBN – Russian Business Network, historically known for managing business Cybercrime, darknet, and protection of high-risk sitesIn this scenario, any official requests from Italian or European authorities would have been ignored or bounced, forcing law enforcement to attempt international cooperation with realities hostile or deliberately uncooperative.

At that point, traffic coming from Russian proxies would have been forwarded towards Malaysia, which in turn could have sent it to the European final server, for example hosted at OVH.

In this scenario, if an Italian authority had attempted to trace the provider origin, the investigation would have clashed with a chain of complex technical and legal steps:

• First step: the request would start from Cloudflare, which is the only publicly visible endpoint.

• Second step: Cloudflare would indicate a next node as reverse proxy located in MalaysiaIn this case, international cooperation would already be complicated, since Malaysia does not adhere to the same mutual legal assistance protocols as the European Union.

• Third step: The Malaysian node, in turn, could forward traffic to a second proxy located in RussiaHere the process would become even more difficult, because Russia is not obliged to provide any cooperation and, especially in the current political context, tends to ignore requests from international police forces.

• Fourth step: only by overcoming these levels, theoretically, could we get to the final origin server, which we have previously hypothesized could be hosted by a European provider such as OVH. However, this remains unlikely to be verified, because the multi-level infrastructure makes it extremely difficult to establish with certainty which is the actual provider.

In this model, therefore, we start from Cloudflare, but the next steps introduce layers of technical and jurisdictional opacity which make the identification of the origin highly complex making it virtually impossible to locate the final server, giving the forum a almost total level of anonymity.

In short words, phica.eu has focused on a protection model monolithic based solely on Cloudflare, which offers minimal shielding but does not solve the problems structural and legal linked to traceability. A truly innovative infrastructure intelligence-proof would have required a more advanced design, built to exploit legal gray areas and to create a multi-level offshore reverse proxy path which made it impossible or extremely complex to obtain useful data through official requests.

Considerations and reflections on the work of law enforcement and prosecutors.

Up to this point, we have analyzed the story mainly from a technical and systems point of view, focusing on the infrastructure of phica.net before and phica.eu Then, about the protections adopted, the vulnerabilities present, and how, theoretically, it would have been possible to trace or block the site. However, the latest news and numerous journalistic investigations raise an even more relevant question: How was it possible that a portal of this size, active for almost twenty years, remained online undisturbed?, although over the years they have been you file dozens and dozens of complaints by victims, families and associations?

This lack of decisive action by the competent authorities – prosecutors, postal police, judiciary – raises legitimate questions about how the reports were handled. When talking about a portal with over 800.000 subscribers, almost a million pages indexed and a massive presence of potentially illicit material, one would expect an investigative approach combined, which unites advanced OSINT techniques, international cooperation and tools immediate containment.

The technical alternatives that were possible but never implemented

In addition to server location and operator identification, there are several consolidated technical strategies that could have made phica.eu e phica.net unachievable for the majority of Italian users, without waiting for the portal's definitive closure.

1. DNS hijacking and seizure

One of the simplest and most widely used solutions against illegal portals for years would have been the implementation of a DNS seizure means DNS hijackingThis technique has been in use since decades and is commonly adopted by judicial authorities when a site violates the law.

The mechanism is simple:

• The judicial authority issues a seizure order.

• DNS providers of Italian ISPs are instructed to change domain resolutions.

• Instead of resolving the portal's real IP address, DNS responds with a redirection to a notification page that reports the seizure.

This measure would not have deleted the site globally, but it would have access blocked by most Italian users, making navigation considerably more complicated for those who do not have advanced skills and a VPN.

2. Blocking traffic through anti-piracy systems (dynamic IP blocking technique)

Another possible solution, even more effective, would have been the adoption of the system already used in Italy to combat the sports piracy, the one used against portals that illegally broadcast football events Sky e DAZN.

This system, defined “Dynamic IP blocking”, informally known as the “Anti Pezzotto Filter” is operated at the behest of theAGCOM (Authority for Communications Guarantees) and it works like this:

1. Identifying the incriminated IPs in real time.

2. AGCOM sends a immediate communication a all Italian ISPs.

3. ISPs implement routing rules at the backbone level, blocking traffic to the reported IPs.

4. Propagation occurs in few minutes, and the site becomes unreachable at the national level, regardless of domain or DNS changes.

This solution would have been particularly effective in the case of phica.eu, because it could have blocked access to the entire infrastructure, making any attempt to change domains or migrate servers futile.

Twenty years of immobility

What leaves you most perplexed, and in some ways bewildered, is that none of these options has been applied for almost 20 years. According to numerous reports newspapers who have investigated the case, over the years had been dozens and dozens of complaints have been filed: from individual victims who had seen their images spread without consent, by family of people involved and even from associations that deal with the protection of privacy and online security. Furthermore, several provides Italians were already informed for some time of the existence of this forum and its extreme social danger.

Yet, phica.net before and phica.eu then they continued to operate undisturbed, without any significant technical limitations, growing exponentially until reaching impressive numbers:

• Over 800.000 registered users.

• Millions of messages published in over two decades.

• Nearly a million pages containing images, videos and sensitive data of unaware people.

This operational silence by the competent authorities opens up worrying scenarios. On the one hand, the prosecutors were already aware of the phenomenon. On the other, the various specialized police units, including departments of the Postal Police and those dedicated to computer crime, they have not implemented any concrete measures to contain the problem. For example, there is no evidence that the following have been prepared:

• Domain blocking via DNS hijacking.

• Targeted interventions on network traffic through Dynamic IP blocking.

• Selective blackout of site infrastructure through international judicial channels.

This operational inertia has allowed the forum to strengthen its infrastructure over time, moving from phica.net a phica.eu, adopting Cloudflare as a level of protection and increasing the difficulty of tracing the origin servers. All this while, for nearly two decades, the authorities they were unable – or unwilling – to act effectively.

The picture becomes even more disconcerting when you learn that only after a strong political and media mobilization the situation has been unblocked. The public positions of some institutional figures, including the Prime Minister Giorgia Meloni, created the necessary pressure to push the prosecutors and the police forces to intervene.

Has been only thanks to this political push, and not to an autonomous intervention by the police, which within just 48 hours the authorities have taken the necessary actions to to black out and take offline a portal that he had been living undisturbed for over twenty years.

This dynamic highlights two critical aspects:

1. La lack of coordination between prosecutors' offices and specialized police departments.

2. The absence of a proactive strategy in dealing with complex digital phenomena, which are instead addressed only after a media explosion and not on the merits of the numerous previous complaints.

Conclusions

The whole story highlights a profound systemic deficiency in the management of complaints, in the cooperation between prosecutors and in speed of intervention by the competent authoritiesIt is not just a technical problem, but a combination of poor investigative strategies, lack of coordination between institutions and absence of operational planning to tackle complex digital crimes that require timely and integrated responses.

The story of phica.net e phica.eu However, it offers us a double food for thought: on the one hand, it highlights institutional errors and failures; on the other hand, it provides a useful overview to understand two fundamental aspects:

1. How to build truly anonymous and robust systems, from a technical and infrastructural point of view.

2. What OSINT techniques and analytics tools are available today to thoroughly investigate a website's infrastructure.

From a strictly technical point of view, tools such as the DNS hijacking or l 'Dynamic IP blocking would have allowed intervention much earlier: two established methodologies that could have greatly limited access to the portal, protecting hundreds of thousands of victims e containing the social impactThe first, the DNS hijacking, has been used for years to block illegal domains by changing DNS resolution at ISPs. The second, theDynamic IP blocking — already widely used to combat the sports piracy and managed in collaboration with theAGCOM — could have intervened at the national backbone level, preventing in real time routing traffic to IP addresses associated with phica.eu, regardless of any domain changes.

These tools were already available, and not only that: in recent years they have been extensively tested in other complex contexts. technology existed, as well as the technical skills necessary to implement a rapid and coordinated intervention. Yet, for reasons that are intertwined bureaucratic inertia, lack of strategic vision It is probably lack of political and judicial will, nothing was done until the case exploded in the media.

At the same time, the OSINT analysis carried out on the matter also offers a educational and technical valueTools such as:

• Shodan e censys to identify exposed services, SSL certificates, and potential vulnerabilities.

• security trails e RiskIQ PassiveTotal to rebuild the DNS history and the old IPs associated with the domain.

• crt.sh to analyze the certificates issued to subdomains and locate hidden endpoints.

• Subdomain enumeration and analysis of the sitemap to discover publicly accessible information.

All these tools, if used correctly, demonstrate how it is possible, even from an external perspective, to collect significant technical information and structure a detailed investigation. The fact that a single independent OSINT researcher has managed to identify flaws and traces left online for years, which proves that the skills were available, but they were not exploited by those who had the means and authority to do so.

In light of what happened, it becomes clear that the problem it wasn't a lack of technology or investigative tools: all of this was already available, and in some cases even consolidated by years of use. What was probably missing was a real political and judicial will to act promptly and an effective operational coordination between prosecutors' offices, guarantee authorities and specialized police units.

The lesson that can be learned is twofold:

• On the defensive frontPlatform managers must understand that complete anonymity requires much more complex infrastructure choices than simple protection with Cloudflare, because every historical error—traceable payments, unprotected logs, unobfuscated DNS—leaves traces that can resurface even years later.

• On the investigative front, the police have at their disposal today very powerful OSINT tools which, if used systematically, can map a complex infrastructure in detail and guide faster and more effective judicial investigations.

In summary, this case demonstrates how the gap between what was technically possible e what was actually done is huge, and represents a problem that goes far beyond phica.eu, touching the entire institutional approach to management of complex digital crimes.