Establishing duration and linkage on a live impersonation operation

SECURITY MEASUREMENT · PASSIVE METHOD · CASE RECORD

ALGIERS, DZ · UTC+01:00

A passive procedure for taking a suspected brand-impersonation operation from "this looks like phishing" to a documented record of what is linked, since when, and what the code actually does — without touching the operation, its users, or its data. Demonstrated on a live Algerian case. The operator is not named: individual attribution remains unestablished and naming an unattributed party would be an accusation, not a result.

Status
Live operation, still serving at time of writing. Report filed to brand owner, host and platform; publication follows coordination.
Contact attempted
Brand owner (Naftal), host (Vercel abuse), platform (Meta), national CERT. Details withheld until the coordination window closes.

1 — THE PROBLEM WITH "I FOUND A PHISHING SITE"

Finding a phishing site is trivial and proves nothing. The claims that matter are the ones a report has to survive:

  • LinkageAre these deployments one operation, or unrelated sites with a similar template?
  • DurationWhen did this exist? Not "I saw it today" — an interval a third party can verify.
  • FunctionWhat does the code do with what it collects? Claims about intent have to rest on the implementation, not on the domain name.

Each of these is answerable from public sources alone. The method below is the order I apply, with the test that discriminates a real linkage from a coincidence.

2 — THE PROCEDURE

2.1 Generator attribution — cheap, and usually decisive

observed

Check the generator meta tag and the build-artifact naming before anything else. AI site generators emit a machine-readable signature, and their deployment slugs follow a fixed pattern. In this case every page in the operation carried <meta name="generator" content="v0.app"/>.

This single observation collapses a lot of speculation. Deployment suffixes that looked like deliberate naming — a sequence of Greek letters across multiple hosts — are the generator's default slug algorithm, not an evasion tactic. A hypothesis that was previously carried as "possible takedown evasion" became refuted: no operator intent is required to explain it.

GENERATOR SIGNATURES · BUILD METADATA · HYPOTHESIS REFUTATION

2.2 Deployment correlation by content, not by name

observed

Similar names are not evidence of common ownership. Correlation requires matching artifacts: identical form field sets, identical contact strings, identical component vocabulary, and — the strongest signal — distinct deployment identifiers per host, each with its own server-action hash.

Here, two live hosts shared a branding layer and an identical data-collection purpose while carrying independent deployment IDs and independent action IDs. That is a common author or a common template authored once and deployed repeatedly. The distinction matters: it is the difference between "someone copied this" and "someone is running this."

ARTIFACT COMPARISON · DEPLOYMENT IDS · SERVER ACTION HASHES

2.3 The architectural contradiction test

observed

The useful question is not "does a payment form look suspicious" — a legitimate merchant checkout also asks for a card. The question is whether the pipeline behind the form can do what the form's own text claims.

Procedure: retrieve every JavaScript bundle the application loads, extract every absolute URL literal, and enumerate every network destination. Then compare that list against the claims the page makes about itself.

In this case, all 14 bundles from both hosts (642 KB) were retrieved. The complete set of destinations was framework and library documentation URLs, an analytics script, and the host's own feedback widget — no application endpoint, no data store, no payment gateway of any kind. The page nonetheless told visitors they would pay "through a secure official gateway." That claim has no implementation behind it.

The finding is therefore architectural rather than inferential: the page's own reassurance is contradicted by its own code. This is the difference between a domain-logic argument ("tires don't need card details") and a measurement.

BUNDLE ANALYSIS · ENDPOINT ENUMERATION · CLAIM-IMPLEMENTATION MISMATCH

2.4 Duration from infrastructure state

inferred

Nobody publishes a deployment timestamp to anonymous callers — the platform API returns 403 and the deployment ID is not a decodable timestamp. Duration has to come from observable state instead.

Two derivable signals: the edge cache age reported by the host on each response, and the first nonzero response across all record types for any domain the operation claims. Both are inferences from observed headers, and both should be labelled as such.

A domain check is where over-claiming is easiest. A name appearing in the operation's own contact strings is a lead, not an indicator. In this case the domain did not exist at all — WHOIS returned no match and every DNS record type returned NXDOMAIN. The apex zone SOA that appears in those responses is present on every NXDOMAIN for the TLD and is not evidence of a child zone. An inferred registration, published as fact, is the defect a reviewer will find first.

EDGE CACHE AGE · DNS RECORD SWEEP · WHOIS · INFERENCE LABELLING

2.5 Independent timestamping before escalation

method

Everything above is worthless if the operation disappears first. Archival to a third-party service must precede any notification, and the artifact hashes must be captured at retrieval time.

Order matters: archive, hash, then notify. Notifying first gives the operator the one signal they respond to, and the evidence chain is gone. Where the collected data has no external destination — as established in 2.3 — the host's own records are the evidence chain, which raises the priority of a preservation request from "useful" to "the entire case."

THIRD-PARTY ARCHIVAL · ARTIFACT HASHING · PRESERVATION SEQUENCING

3 — WHAT THE METHOD PRODUCES

A record in which each statement carries its own confidence, and the confidence is set by the acquisition method rather than by how convinced the analyst is:

  • ObservedHeaders, response bodies, bundle contents, DNS answers, WHOIS output — retrieved and hashed.
  • InferredDuration from cache age, common authorship from artifact overlap. Labelled, never merged with the above.
  • UnconfirmedAny claim of individual identity. In this case, distribution attribution is high, operational attribution is moderate, and individual attribution is unestablished — and stays unestablished until an account-level record says otherwise.

That last line is the point of the whole exercise. A public page linking to an operation proves the link exists; it does not prove who is behind it. Stating the limit is what keeps the finding usable.

4 — LIMITS

  • No individual attributionA distribution channel was identified. No account owner, no operator, no individual is attributed. Provider records would be required and were not sought by me.
  • Duration is inferredDeployment creation timestamps are not publicly retrievable. The interval is derived from cache-age headers and is stated as an inference.
  • No victim-side dataWhether anything is actually stored, and how much, is unverified. Confirming it would require either the operator's surface or provider records — both outside this method's boundary.
  • Blast radius unmeasuredNo traffic, impression or conversion data was accessed. The operation's reach is unknown.
  • Not exhaustiveOnly the hosts discovered by following the distribution channel were examined. Other deployments from the same author may exist and were not enumerated.

5 — BOUNDARY

What was not done, stated explicitly because it is the part that decides whether this is research or an incident:

  • No authentication attemptAn administrative surface was identified and deliberately not touched. Its existence is documented; its contents were never accessed.
  • No form submissionNot even with test data. A submission would have written into a system of unknown ownership.
  • No exploitation, fuzzing, or credential testing.
  • No interaction with any operator-controlled account or channel.
  • No user data accessed, in any form, at any point.

The operating rule: the method reads what the operation publishes to the world, and stops at the first door. Everything past that door belongs to a preservation request or a warrant, not to a researcher.

6 — WHY PUBLISH THE METHOD

The case will expire. Deployments get deleted, pages get removed, and the specific finding becomes a historical curiosity. The procedure does not expire, and it is the part that transfers.

Applied to this case, the sequence — generator signature, artifact correlation, claim-implementation mismatch, duration inference, archive before notify — took an operation from a suspicious URL to a documented record of linkage and function using nothing but public retrieval. Anyone can repeat it on any suspected operation, on any target, and get a comparable record.

That is the deliverable: not "an Algerian phishing site exists," which is unremarkable and unverifiable, but a repeatable way to establish that an operation is one operation, since when, and what its code actually does — with the boundaries stated so the record survives being argued with.