How this register was built

This register establishes what and who is behind the name of Mohammed Hamcho; the companies, the web addresses, the offshore vehicles, family members. The register maps this entirely from material anyone can look up: the public plumbing of the internet, business directories, registry filings, and the Internet Archive's memory of web pages that have since been taken down.

Start from the infrastructure, not the names

The intuitive way to investigate a business group is to start with a name and look for its companies. This register does close to the opposite. It starts from a piece of infrastructure — a single web server, a single registrar account — and asks what else is attached to it.

The reason is simple: a company can hide its ownership, but it cannot easily hide where its website and email actually live. Two companies that insist they are unrelated will still, if the same small IT shop runs both, point at the same servers, renew through the same account, and send their DMARC error reports to the same Gmail address. Those are technical facts, published in the open, and it seems the Hamcho group paid little attention to laundering them.

So the work runs outward from a single address. Every domain in the first cluster resolved to one machine. A reverse lookup on that machine turned up a second one running the group's corporate mail. That mail server, in turn, listed close to ninety hostnames — and several of them belonged to companies named directly in the sanctions designations.

Read the fingerprints that are hard to fake

A handful of technical details recur across the estate and act as fingerprints — not proof of ownership, but strong evidence that one operator sits behind many supposedly separate names.

The clearest is a single Gmail address that receives the delivery-error reports for domains across two different servers and two supposedly unrelated clusters. Alongside it: a single registrar account holding almost every domain, shared nameservers, and mail servers that show up over and over in the fine print of otherwise unconnected companies' records.

One late discovery shows why reading the fine print matters. Some of the older domains authorise mail servers belonging not to the current operator but to an earlier one — a separate Damascus web firm the group used before roughly January 2017. Those entries are fossils: leftover configuration nobody cleaned up. But because they only appear on domains registered before a specific week, they date the handover from one IT vendor to the next almost to the day, and reveal an entire operator the map had been missing.

Rate every claim, and keep the dead ends

The risk in this kind of work is that the story gets more satisfying than the evidence. A shared server starts to feel like proof of common ownership; a matching surname starts to feel like a proven family link. The register guards against that with a fixed, four-level rating attached to every claim, and the rule that a more coherent story is never, by itself, a reason to upgrade one.

• Confirmed — a primary source says so: the party's own filing, its own website, or an official designation. These reproduce the exact quote and its citation.
• Strong — several independent technical or documentary indicators agree and nothing contradicts them.
• Suggestive — consistent with the theory, but explainable other ways. Recorded, not relied on.
• Struck — investigated and disproven, and kept anyway, so nobody walks the same dead end twice.

The single governing sentence sits behind all of it: shared infrastructure proves a shared operator, never a shared owner. A sanctioned company and a neighbourhood rental app can live on the same machine and mean nothing by it. That caution is applied even where it's uncomfortable — to companies the register strongly believes belong to the group — because the moment it's relaxed for a convenient case, every claim in the file gets weaker.

Why it's built this way

The register is a set of plain data files that a program turns into the website — no database, no private back end. Every claim points to a source; every relationship is written down once and the connections are computed from there, so the two ends can't quietly drift apart. The point of that plumbing is auditability: a reader who doubts a conclusion can follow it back to the DNS record or the archived page it rests on, and check it themselves with the same public tools.