In recent years, phishing targeting Italian citizens has shifted noticeably. We rarely encounter the traditional email with a suspicious link or a poorly written message promising an unexpected inheritance.

The model has become more structured and follows a multi-step workflow.

fake page → portal → multi-step procedure → identity verification → credential & data harvesting.

This evolution led to “The Phantom PA” experiment at MC Project Lab. Our goal was not to maintain a list of known malicious sites, but to answer a practical question.

Can we automatically detect and correlate technical signs of fake public service portals, even when the domain is completely absent from threat intelligence databases?

To investigate this, we designed and tested MC Project Lab Site Trust Analyzer. The most valuable takeaway from our research was not immediate success, but a controlled failure that led us to rethink our evaluation architecture.

When phishing becomes a digital service

Recent campaigns targeting citizens and public agencies show a clear shift. Fraudulent websites no longer stop at asking for a username and password on a static landing page, but simulate a complete online procedure.

  • simulated user identification;
  • step-by-step entry of personal details;
  • uploading identity documents with automatic format validation;
  • harvesting digital identity credentials such as SPID or CIE;
  • entering bank details or card numbers;
  • simulated payment checkouts and fake refund confirmations;
  • targeted file downloads customized for the visitor's device;
  • automatic redirects to real government portals to conceal the theft.

The core challenge is not just visual mimicry. We must examine page behaviour. An unfamiliar domain is a signal; a suspicious domain mimicking a public body is a stronger signal; if that page also hosts interactive forms harvesting sensitive information, the risk escalates immediately. Combining these independent factors is where our research focused.

Documented cases and the anatomy of fake portals

Before looking at technical details, it is helpful to examine documented cases recorded in 2026 by security authorities, including the Postal Police and CERT-AgID. These are not theoretical risks, but active, operational attacks.

Overview of documented digital impersonation cases of Italian Public Administration · CERT-AgID 2026 Selection
Figure 1 · Selection of documented digital impersonation cases of Italian Public Administration analyzed in the dossier (Sources CERT-AgID, State Police and forensic reports 2026).
Methodological note. The cases shown in the infographic do not imply a single author. Threat indicators, technical resemblances, and attribution to a specific threat actor are separate tiers of analysis. Technical correlation does not constitute attribution.

Site Trust Analyzer

Site Trust Analyzer was originally designed as a passive URL scanner. The first version inspected external attributes without querying the web server, evaluating the domain name, TLD, institutional keywords, punycode, government allowlists, known indicators, DNS records, TLS certificates, and RDAP data.

We later introduced Page-Aware analysis. Inside an isolated environment, without submitting personal data or running downloaded files, the analyzer checks several page elements.

  • the HTML page structure;
  • the presence and structure of interactive forms;
  • fields collecting passwords, PIN codes, or SPID credentials;
  • document upload controls;
  • tracking scripts and external redirects;
  • institutional logos paired with active data entry forms.

We also added a grouping engine (Campaign Cluster Engine). Its role is not to identify individuals, but to determine whether two suspicious sites share enough technical fingerprints to belong to the same campaign. Here too, the rule remains absolute, technical similarity does not prove authorship.

Pilot 01 and initial results

The initial version of the engine (v0.5.0) was tested on 27 sample cases. With default alert settings (score of 25 or higher), the preliminary metrics looked encouraging.

  • 8 True Positive, 0 False Positive, 15 True Negative, 3 False Negative;
  • Precision 100%  |  Specificity 100%  |  Accuracy 88.5%.

However, the evaluation had a methodological flaw. The seven documented phishing cases used in the test were already listed in our system database, while government sites were protected by the official allowlist. The test proved that the software recognized known examples, but did not guarantee its ability to catch novel threats in real conditions.

Pilot 02 and the blind test

For the second pilot, we removed all prior advantages. No known signatures were available for the test threats, and benign controls received no allowlist protection. We built a blind test set of 40 cases, including 15 unknown threats, 15 unprotected benign sites, and 10 trap cases (legitimate sites using words like SPID or tax, included specifically to test for false alarms).

The test ran blind against the frozen codebase (v0.5.0rc1), exposing immediate limitations.

  • 10 True Positive, 2 False Positive, 23 True Negative, 5 False Negative;
  • Precision 83.3%  |  Recall 66.7%  |  False Positive Rate 8.0%;
  • Maximum threat score assigned to an unknown threat reached 44 points.

Defense Lab audit checks blocked the release (PILOT 02 FAIL · CALIBRATION REQUIRED), holding back v0.5.0rc1.

Why failure was constructive

The blind test revealed three practical weaknesses that synthetic checks had never uncovered.

  1. Text-based false alarms. Educational or news portals gained risk points simply by mentioning words like “SPID” or “password” in articles. Discussing security topics is not equivalent to stealing credentials.
  2. Restricted scoring for unknown attacks. Without the boost from historical database matches (+55 points), a new threat with aggressive harvesting forms topped out at 44 points. Because the high-risk bracket started at 50, new threats could not be labeled high priority.
  3. Offline cluster limitations. Without external network telemetry, the cluster engine struggled to match identical page layouts with slightly altered text, stalling at 37% similarity instead of clearing the strong 75% threshold.

Moving to version 0.6

Rather than patching the system by manually adding the 5 missed cases (a shortcut that harms general reliability), we kept the baseline frozen and re-engineered the inner workings of Site Trust Analyzer v0.6.0 with four core adjustments.

1. Multi-signal compound scoring

The engine checks whether multiple warning signs appear together. An institutional keyword alone does not trigger an alert, nor does a generic form. However, when institutional branding coincides with credential collection fields outside approved domains, a compound rule triggers (+20 points), moving the score into the high-risk tier (70–74 points), even for newly registered domains.

2. Verifying interactive forms

Sensitive terms such as SPID, password, or bank details in editorial copy no longer raise flags if the page lacks an interactive submission form. Describing an official process does not steal data. In addition, the weight assigned to generic TLDs lacking forms was reduced from 6 to 4 points.

3. Automatic detection of form input patterns

Analysis evaluates input field properties directly to uncover credential harvesting behavior without relying on domain names.

4. Cleaner DOM parsing for clustering

We excluded boilerplate HTML tags shared by nearly all websites, which previously created misleading resemblances. Structural comparison now focuses solely on meaningful technical indicators.

The decisive test on unseen holdout data

To confirm that improvements were genuine and not tailored to previous test data, we evaluated version v0.6.0 against 40 brand new cases never used during development or tuning (15 unknown threats, 15 benign sites, and 10 trap cases).

Experimental Comparative Results (Site Trust Analyzer v0.6.0 GA)

Metric v0.5.0rc1 Baseline (Pilot 02) v0.6.0 Pilot 02 Replay v0.6.0 Unseen Blind Holdout
Precision 83.3% 100.0% 90.0%
Specificity 92.0% 100.0% 96.0%
False Positives (FP) 2 of 25 0 of 25 (Zero FP) 1 of 25 (FPR 4%)
Hard Negatives (Trap Cases) 8/10 passed 10/10 passed 10/10 passed (100%)
Peak Unknown Threat Score 44 (Capped in Attention) 70 (HIGH bracket) 74 (HIGH bracket)
Detection at HIGH Threshold (≥ 50) 0.0% (0/15) 53.3% (8/15) 40.0% (6/15)
Cluster Engine Benchmark 5/10 passed 10/10 passed (100%) 10/10 passed

Verdict RELEASE GATE APPROVED · MCPL Site Trust Analyzer v0.6.0 GA. Development closed and frozen with SHA-256 manifest tracking 60 files, complete with validation artifacts and test evidence.

60% is not 100% and real defensive boundaries

This is the central point of the research. Site Trust Analyzer does not detect all unknown threats. In the blind holdout, it identified 9 out of 15 threats (a 60% detection rate). The remaining 6 threats, which lacked obvious harvesting indicators or resembled basic informational pages without active forms, did not trigger the alarm threshold.

For this reason, we do not present this tool as an infallible shield, nor do we present 96% specificity as an absolute achievement. That figure reflects an objective observation. In our test set, the system correctly categorized 24 out of 25 benign websites, substantially reducing false alarms and passing all 10 trap cases. These metrics represent that offline setup and those 40 specific cases, not the entire internet.

Correlating without attributing

Alongside detection, we refined the clustering engine. All ten evaluation benchmarks passed successfully. Two visually identical pages with minor text variations, which previously scored only 37% similarity, now reach 78.4%. At the same time, pages sharing only a web server or basic graphic assets but having distinct code structures remain capped at 25%, avoiding faulty groupings.

Our stance remains deliberately cautious. The tool can indicate strong technical correlations between web pages, but cannot conclude that they share a single author. Legal attribution requires judicial findings and field intelligence.

A rigorous testing methodology

This work reinforced a clear operating workflow, spanning threat analysis, blind evaluations, and final releases. In the second evaluation, we specifically introduced tests designed to challenge the system rather than confirm assumptions. When the software failed, we did not adjust scores or lower criteria. We accepted the failure, used it as a baseline, and measured our adjustments against completely fresh data.

What we learned

Our research delivers a clear takeaway. No single technical clue is enough to unmask a fake public service. An unusual URL is not enough, a government crest is not enough, an HTTPS padlock is not enough, an official acronym is not enough, and a web form is not enough. Success lies in evaluating the simultaneous presence of several independent technical indicators.

We will continue to advance on this foundation. Our goal is not to design systems claiming absolute infallibility, but to deliver practical defensive tools that provide clear, demonstrable warnings when enough technical anomalies occur on a page to require prompt attention.

Primary sources and official documentation