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

The website Phica.eu (originally Phica.net), active continuously from 2005 to 2025 , was one of the most controversial Italian portals for twenty years, becoming infamous for hosting thousands of photos of women published without their consent . The content included images of famous people , such as 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 sharing . Many of these photos portrayed the victims in suggestive poses , up to completely explicit shots , distributed without the protagonists' knowledge.

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

In the remainder of this post, we will provide our technical perspective on the matter: we will analyze how the hosting services that allow the survival of illegal portals work , we will explain the errors committed by the Italian founder that led to their identification, and we will highlight the shortcomings, delays, and responsibilities of Italian prosecutors and other regulatory bodies . We will not address the issue from an ethical or moral perspective , confident that the legal framework 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-scale forum , based on XenForo 2 , one of the most powerful and popular commercial platforms in the world for managing online communities. XenForo is developed in PHP and relies on a MySQL-compatible DBMS — such as Percona Server or MariaDB — designed to handle heavy workloads and optimized for very high-traffic scenarios. Born as a natural evolution of vBulletin , XenForo inherits part of its architectural foundations but introduces significant improvements , both in terms of performance and functionality.

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

In this specific case, Phica.eu represented an extreme example of exploiting this potential : the forum hosted several million active discussions , with several billion total page views accumulated over the years. According to public estimates by SimilarWeb , the traffic generated was enormous, approximately 6 million monthly visits, with an average of 12 page views for each single visit, and a total of approximately 70 million page views per month , a figure 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 user base of approximately 800.000 members , making it one of the largest online communities in its sector in Europe.

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

Such a volume of traffic required a robust infrastructure , with multi-tiered caching systems , optimized databases, load balancers, and likely the use of a Content Delivery Network (CDN) to distribute static resources globally. Despite this, the site remained extremely responsive, a sign of meticulous technical optimization. It is precisely this combination of high-performance architecture , optimized databases , and horizontal scalability that has allowed Phica.eu to sustain massive 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 also stood out for its integration of multimedia content into discussions and user comments. The most common modus operandi involved embedding videos from external portals: users inserted links or embedded players from third-party platforms, replicating dynamics similar to those of YouTube, Vimeo, and smaller repositories.

However, Phica.eu didn't stop there: the portal had its own server infrastructure dedicated to the direct distribution of videos, organized as a self-hosted CDN . This network was highly visible to the public and structured on multiple dedicated nodes , identifiable through domains such as:

• 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 like HLS , MPEG-DASH , or RTSP , which divide content into dynamically loaded segments . This allows the user to skip 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 functioned as a repository of static files . When a user wanted, for example, to skip directly to the end of a video , the entire file had to have already been downloaded up to that point. This resulted in greater server load , high bandwidth , and a less fluid experience than modern streaming platforms.

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

Phica.eu's estimated and actual earnings

One of the most debated aspects surrounding the Phica.eu case concerns the earnings generated by the portal over the years. Based on market estimates for adult sites with similar traffic volumes, revenue is calculated using the RPM ( Revenue per Mille ) parameter, which is the average revenue generated for every 1.000 page views . For platforms of this type, the most reliable estimates indicate an average value ranging between 1 and 2 euros for every 1.000 views , with peaks that in some cases can reach as high as 3 euros depending on the quality of the traffic and advertising sources.

Remaining in the most conservative scenario , i.e. 1 euro for every 1.000 page views , and taking into account the approximately 70 million monthly pages 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 more in-depth analyses and some rumors appearing in the press, the hypothesis of an average RPM of 2 euros seems more realistic: this would mean approximately 140.000 euros in monthly revenue and over 1,6 million euros in annual revenue.

An important clue supporting this second hypothesis comes from an analysis of corporate data for Hydra Group Eood , one of the companies identified as a "connected party" to Phica's infrastructure. The company, registered in Sofia with a share capital of just 50 euros , reported a turnover exceeding 1,3 million euros ( 1.369.296,48 euros to be precise ). This is a clear disproportion, suggesting that seemingly small structures can become key hubs within complex digital architectures , moving very significant capital through distributed networks.

The same analysts, Valerio Lilli and Lorenzo Romani , helped reconstruct the corporate structures and connections behind Phica.eu , using open sources and network analysis tools , including the Whois database. Although many domains were protected by privacy masking services (e.g., GoDaddy Domains by Proxy), cross-referencing metadata and registrations still allowed them to trace significant connections between individuals, companies, and infrastructures. It's important to emphasize that these aren't definitive proof of ownership , but rather plausible hypotheses based on technical and documentary evidence 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 independent viewing of the episode “THE PHICA CASE” of the program Corona On AIR – Falsissimo , we learned that Hydra Group EOOD and its administrator 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.

Due to the sensitive and risky nature of the content handled by Phica.eu , the founder knew he was exposing himself to complaints, lawsuits , and possible criminal liability . For this reason, he attempted to protect himself by adopting CloudFlare as a layer of anonymity and defense. CloudFlare is a Content Delivery Network (CDN) and reverse proxy service that, among other features, allows you to mask the real IP address of the origin server : instead of exposing the actual hosting IP, visitors are shown the IPs of CloudFlare , which interposes itself between the user and the server, filtering traffic, managing caching, and offering DDoS protection.

In this scenario, anyone making an HTTP request to Phica.eu never communicates directly with the real server, but with CloudFlare nodes , which then forward the connection back to the origin server. This approach apparently guarantees a certain degree of anonymity for the portal's administrators, because a user attempting to trace the real server's IP address will only see CloudFlare's public IP addresses.

However, it's important to understand how CloudFlare's "Abuse" management policy works . When a user—for example, a girl who finds her private photos published on Phica.eu without consent—sends CloudFlare a copyright takedown request (DMCA) or an abuse report , CloudFlare does not directly intervene on the content . Due to its net neutrality policy , the service acts as a mere technical intermediary : it receives the report, identifies the real IP of the origin server , and forwards the request to the hosting provider managing that server.

For example, if the Phica.eu server was hosted by a hypothetical provider like “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 the site or block disputed content because it does not host it and, by company and Net Neutrality policy, does not actively moderate it. The responsibility of evaluating violations and taking any legal or technical action always falls to the provider managing the origin server . In a context like Phica.eu , this dynamic made it more difficult to intervene quickly 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 to identify the origin provider , that is, the actual hosting behind CloudFlare 's protection , and understand how it decides to operate when it receives reports of abuse.

The applicable Italian legislation is Legislative Decree 70/2003 , which implements European Directive 2000/31/EC on electronic commerce. Specifically, Articles 14, 15, and 16 establish that:

• A Hosting Provider is not criminally or civilly liable for content uploaded by its customers until it is aware of their illegal nature.

• Liability begins when the hosting receives a formal notification (such as an abuse report , a DMCA notice , or a copyright or privacy infringement complaint ).

• From the moment the provider becomes aware of illegal content , it is obliged to remove it or prevent access to it , under penalty of civil or criminal liability for "complicity" in the dissemination of illegal material.

In the case of Phica.eu , when CloudFlare received an abuse report, it didn't remove the content (per its neutrality policy ), but forwarded the request to the origin provider that physically hosted the site. At that point, the host faced three possible scenarios:

1. Deliberately ignore the report

   • Some providers, especially those registered in countries with permissive jurisdictions , consciously decide not to intervene . This allows the portal to remain online for years, despite requests for removal.

2. Accept the customer's justifications

   • Often, upon receiving a notification from CloudFlare, the provider will inform the site owner and request an explanation. If the customer provides technical or legal reasons that the hosting provider deems plausible, the provider may decide not to suspend service.

3. Intervene by suspending or obscuring the service

   • In theory, if the customer does not respond or does not provide valid justification, the provider should deactivate the account , remove the content, or cooperate with the relevant authorities.

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

• CloudFlare Receives Notification →

• 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 aware of abuse reports : the provider is formally obligated to pass them on . However, if the hosting provider fails to act or decides to believe the customer's justifications , the site remains online.

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

• 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 dozens of complaints.

Legislative Decree 70/2003 highlights a fundamental point: a hosting provider is never criminally liable until it knows . But from the moment it knows, it is obliged to act . If it fails to do so, liability—at least in civil proceedings—also falls on it.

Who is the originating provider behind Phica.eu?

When discussing Phica.eu and trying to understand the origin provider that 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 Phica forum was officially launched in August 2005 under the domain phica.net . Over the years, it gradually became one of the largest Italian forums dedicated to pornographic content and, above all, non-consensual material, to the point of being defined as a revenge porn hub . For nearly 17 years , phica.net was the main access point to the platform, accumulating millions of posts and hundreds of thousands of registered users.

Then, in 2022 , an important strategic shift occurred: phica.net began automatically redirecting to phica.eu . This seemingly trivial move has a precise technical significance. The domain change could 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.

• Desire to shift operational focus towards a European provider and, likely, to exploit more favorable jurisdictions.

Figuring out the originating provider behind phica.eu is not easy, especially since the site currently relies on Cloudflare for security. Cloudflare acts as a reverse proxy 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 trace the origin of phica.eu , we can't just analyze the current infrastructure: we need to start from the beginning, when the platform used phica.net . This is essential because from 2005 to 2022, the forum operated without the same attention to privacy 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 up to the transition to phica.eu.

3. Analyze current protection layers and identify 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 through Serverplan , 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 preserve old A records and allow us to reconstruct historical variations in IP addresses.

During this initial phase, phica.net did not use any advanced security; the servers responded directly, and the IP address was publicly visible. It's likely that a significant amount of information was collected during this period, including physical providers, data centers, and configurations used.

3. The move abroad: France and Canada

After a few years, presumably to increase anonymity and protect itself from potential Italian investigations, phica.net migrated its infrastructure to France . It was hosted there for a limited period, likely using dedicated servers or high-traffic VPSs.

Subsequently, the forum moved permanently to Canada , where it found its "permanent home" for several years. Analyzing the DNS information, the most likely provider at this stage emerges as OVH , one of the European hosting giants, which has enormous data centers in both France and Canada.

OVH 's choice is not surprising: the group is among the largest European operators, with a well-established reputation for offering scalable, high-performance infrastructures and relatively favorable privacy policies for those seeking anonymity. However, there is an interesting aspect from an investigative perspective: OVH also has a commercial subsidiary in Italy . This presence in the country could represent a strategic access point for Italian law enforcement , who could leverage the local office to formally request data and information as part of an investigation, following the procedures established by international judicial cooperation.

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

1. Low costs 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 though – thanks to the Italian headquarters – law enforcement agencies would now have more leeway to act than in the past.

4. Introducing Cloudflare

With the forum's growing popularity and growing controversy, phica.net decided to adopt Cloudflare as an intermediate layer of protection. From then on, all requests to the domain passed through Cloudflare's infrastructure, which acted as a reverse proxy and masked 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 an active protection strategy by the forum, which becomes much more difficult to track.

5. Migration to phica.eu (from 2022)

The turning point came in 2022: the main domain became phica.eu . All traffic from phica.net was redirected via a 301 redirect to the new European extension.

The reasons could be many:

• Avoid .net domain blacklists or seizures.

• Seek a more favorable jurisdiction.

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

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

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

• We analyze the old DNS records related to phica.net before Cloudflare was adopted.

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

b) Subdomain Enumeration

• By analyzing active and inactive subdomains, you can identify endpoints that are not passing through Cloudflare and reveal their real IP.

• Tools like Amass , Subfinder , or crt.sh can help.

c) SSL Certificate Analysis

Through an in-depth analysis of digital certificates, we discovered that active Let's Encrypt certificates exist for several subdomains of phica.eu . To 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 finding is particularly interesting because if even one of these subdomains was not protected by Cloudflare – for example, a secondary endpoint, an old admin panel, or an exposed internal service – it could directly reveal the IP address of the origin server.

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

d) Shodan and Censys

By entering phica.net or phica.eu on Shodan you can find:

• • Old endpoints remained active.

  • Services on display.

  • Information about the real provider.

7. The flaws discovered in the infrastructure

During OSINT analysis of the forum, significant vulnerabilities emerged :

• Unprotected public sitemaps : Over 981.000 pages freely indexed.

• Clear emails associated with users: approximately 791.000 registered profiles, many with visible personal data.

• Out-of-date services detected via Shodan , with potential known 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 originating provider is almost certainly a large European or North American operator, with OVH remaining the most likely candidate given the domain's history and geographic proximity to Cloudflare's European headquarters.

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

Discovering the origin provider behind phica.eu is no easy task. The domain change, the adoption of Cloudflare, and the distributed structure of subdomains make the investigation complex. However, reconstructing the forum's entire history starting from phica.net reveals important details:

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

• It then moved to France and finally to Canada , probably to OVH.

• Since 2022, with the birth of phica.eu , the entire infrastructure has moved behind Cloudflare.

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

In other words, although Cloudflare is now hiding its real IP address, historical data and technical evidence suggest that the forum's “parent company” has remained largely unchanged: a high-performance infrastructure, most likely based on Dedicated Servers located in Europe, with OVH as the 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's clear that several structural errors have been made, leaving behind technical, administrative, and commercial consequences . Despite the current use of Cloudflare as a security system, this is a rather basic solution , with all the inherent limitations. Cloudflare is effective at masking the originating IP address and protecting the site from DDoS attacks, but it's not sufficient to build an intelligence-proof infrastructure that's truly resistant to coordinated investigations across multiple jurisdictions.

To understand how phica.eu could have been made nearly impossible to trace, we must start with the initial mistakes made during the phica.net era . In the early years, the forum was hosted on Italian providers like Serverplan , leaving clear commercial traces : traceable payments, invoices in the user's name, and personal data associated with the accounts. At the time, cryptocurrencies did not exist , so payments were made almost exclusively via bank transfers, credit cards, or traditional systems , all easily accessible to law enforcement. This initial choice created a chain of historical evidence that can no longer be erased today.

A truly secure infrastructure would have required a very different approach, not only technical but also legal . The operational security of such a system is based on two pillars:

1. Multi-layered infrastructure protection.

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

From a technical standpoint, the most effective solution would not have been to rely solely on Cloudflare as the sole entry point. It would have been necessary to add at least two additional layers 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 layer: Public endpoint protected by Cloudflare , which acts only as an initial obfuscation layer.

• Second level: An offshore reverse proxy located in Russia , where access to the data by European or Italian authorities would be extremely difficult. 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 services and for 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 either with HTTP reverse proxies or 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 cybercrime, darknet, and high-risk website protection activities . In this scenario, any official requests from Italian or European authorities would have been ignored or bounced, forcing law enforcement to attempt international cooperation with hostile or deliberately uncooperative entities.

At that point, traffic from the Russian proxies would be forwarded to Malaysia , which in turn could send it to the final European server , for example hosted at OVH.

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

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

• Second step: Cloudflare would designate a reverse proxy located in Malaysia as the next node . In 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 the traffic to a second proxy located in Russia . Here, the process would become even more difficult, because Russia is not required to provide any cooperation and, especially in the current political context, tends to ignore requests from international law enforcement.

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

In this model, therefore, we start with Cloudflare , but the subsequent steps introduce layers of technical and jurisdictional opacity that make identifying the origin highly complex , making it practically impossible to identify the final server, guaranteeing the forum an almost total level of anonymity.

In short, phica.eu relied on a monolithic security model based solely on Cloudflare, which offers minimal protection but fails to address the structural and legal issues related to traceability. A truly intelligence-proof infrastructure would have required a more advanced design, built to exploit legal gray areas and create a multi-layered offshore reverse proxy system that would make 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 matter primarily from a technical and systems perspective , focusing on the infrastructure of phica.net first and then phica.eu , 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 , despite dozens and dozens of complaints filed over the years by victims, families, and associations?

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

The technical alternatives that were possible but never implemented

In addition to server location and operator identification, several established technical strategies could have made phica.eu and phica.net unreachable for the majority of Italian users without waiting for the portal's permanent closure.

1. DNS hijacking and seizure

One of the simplest and most widely used solutions against illegal portals has been the implementation of DNS hijacking . This technique has been in use for decades and is commonly used by law enforcement when a site violates the law.

The mechanism is simple:

• The judicial authority issues a seizure order.

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

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

This measure would not have eliminated the site globally, but it would have blocked access to it by most Italian users , significantly complicating navigation for those without 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 sports piracy , the one employed against portals that illegally broadcast football events from Sky and DAZN.

This system, called “dynamic IP blocking” , informally known as the “Anti Pezzotto Filter”, is managed at the behest of AGCOM (the Italian Communications Regulatory Authority) and works in this way:

1. Identify incriminated IPs in real time.

2. AGCOM sends an immediate communication to all Italian ISPs.

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

4. Propagation occurs within minutes , and the site becomes unreachable nationwide , 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 , rendering any attempt to change domains or migrate servers useless.

Twenty years of immobility

What is most perplexing, and in some ways disconcerting , is that none of these options were applied for almost 20 years . According to reports from numerous newspapers that investigated the case, dozens and dozens of complaints had been filed over the years : from individual victims who had seen their images shared without consent, from family members of those involved, and even from associations that work to protect privacy and online security. Furthermore, several Italian prosecutors' offices had already been aware of the existence of this forum and its extreme social danger for some time.

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

• Over 800.000 registered users.

• Millions of messages posted over two decades.

• Nearly a million pages containing images, videos, and sensitive data from unsuspecting people.

This operational silence from the competent authorities raises worrying questions. On the one hand, prosecutors were already aware of the phenomenon. On the other, the various specialized police units , including the Postal Police and those dedicated to cybercrime , 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 allowed the forum to strengthen its infrastructure over time, moving from phica.net to phica.eu , adopting Cloudflare as a security layer, and increasing the difficulty of tracing the origin servers. All this while, for nearly two decades, the authorities were unable—or unwilling—to act effectively.

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

It was only thanks to this political push , and not to an autonomous intervention by the police, that within just 48 hours the authorities took the necessary steps to block and take offline a portal that had been operating undisturbed for over twenty years.

This dynamic highlights two critical aspects:

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

2. The lack 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 entire affair highlights a profound systemic deficiency in the management of complaints, in cooperation between prosecutors , and in the rapid response of the competent authorities . This isn't just a technical problem, but a combination of deficient investigative strategies , a lack of coordination between agencies , and a lack of operational planning to address complex digital crimes that require timely and integrated responses.

The history of phica.net and phica.eu, however, offers us two food for thought: on the one hand, it highlights institutional errors and failures ; on the other, it provides a useful overview for understanding two fundamental aspects :

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

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

From a strictly technical standpoint, tools such as DNS hijacking or dynamic IP blocking would have allowed for intervention much earlier : two consolidated methodologies that could have significantly limited access to the portal, protecting hundreds of thousands of victims and limiting the social impact . The first, DNS hijacking , has been used for years to block illegal domains by modifying DNS resolution at ISPs. The second, dynamic IP blocking —already widely used to combat sports piracy and managed in collaboration with AGCOM — could have intervened at the national backbone level, preventing traffic from being routed to the IP addresses associated with phica.eu in real time , 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. The technology existed , as did the technical expertise needed to implement a rapid and coordinated intervention. Yet, for reasons that combine bureaucratic inertia, lack of strategic vision , and likely a lack of political and judicial will , nothing was done until the case exploded in the media.

At the same time, the OSINT analysis conducted on the incident also offers educational and technical value . Tools such as:

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

• SecurityTrails and RiskIQ PassiveTotal to reconstruct DNS history and old IPs associated with the domain.

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

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

All of these tools, when used correctly, demonstrate how it is possible, even from an external perspective, to gather significant technical information and structure a detailed investigation. The fact that a single independent OSINT researcher was able to identify flaws and traces left online for years demonstrates that the expertise was available , but was not exploited by those who had the means and authority to do so.

In light of what happened, it becomes clear that the problem wasn't a lack of technology or investigative tools : all of these were already available, and in some cases even consolidated over years of use. What was likely lacking was a genuine political and judicial will to act promptly and effective operational coordination between prosecutors' offices, supervisory authorities, and specialized police units.

The lesson that can be learned is twofold:

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

• On the investigative front , law enforcement agencies now have at their disposal extremely powerful OSINT tools which, if used systematically, can map a complex infrastructure in detail and direct faster and more effective judicial investigations.

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