Domains are cheap, fast and disposable. The habits and infrastructure behind them are not. Every investigation of a scam network is really a search for the things an operator could not be bothered to change.
This field note describes an engagement for the fraud intelligence unit of an international retail bank. Identifying details have been changed and the domains below are fictional placeholders, but the sequence of pivots, the timings and the outcome are reported as they happened. The full engagement summary is in our case study.
The starting point: 14 domains and a pattern
Over six weeks the bank received 63 complaints from customers who had sent money to online "investment platforms" promoted through fake endorsement adverts. Combined customer losses had reached $2.3M. The complaints named 14 distinct domains. The sites were near-identical: the same dashboard showing invented returns, the same live-chat widget, the same pressure to deposit more before a "trading window" closed.
The bank had already done the obvious thing. It had reported the sites and several were taken down. Each takedown was followed within days by a replacement on a fresh domain, and the complaints kept coming. The fraud team's question to us was simple: is this one operation, and if so, who runs it and where does the money go?
Why the domain is the wrong unit of analysis
Treating each domain as a separate problem plays to the operator's strengths. Registering a new name costs almost nothing, privacy services hide the registrant, and content delivery networks hide the hosting. What operators rarely rebuild from scratch for every site is the supporting machinery:
- Advertising and analytics configuration, which takes real effort to set up and tune.
- Certificates, which are often requested in batches for convenience.
- Templates and admin panels, frequently bought or built once and reused.
- Payment rails, which are scarce, slow to obtain and expensive to lose.
- People, who carry their usernames, writing habits and working hours from one project to the next.
Each of those is a potential pivot: a shared attribute that lets an investigator move from one known item to others that share it. The craft lies in choosing pivots that are distinctive enough to mean something, and in testing whether a shared attribute reflects common control or mere coincidence.
Pivot one: the analytics container
Before touching anything else, we captured the 11 sites that were still live in full, including page source and every network request, and preserved archived copies of the three already taken offline. Every capture was hashed at collection. Reviewing the source, we found that all 14 sites loaded the same third-party analytics container identifier: a tag management container that the operator used to fire conversion pixels for their advertising campaigns.
Operators reuse containers because rebuilding conversion tracking for every new domain is tedious, and because their advertising accounts depend on it. That makes a container identifier one of the most valuable pivots in fraud work. We searched historical crawl data and source-code search indexes for the identifier and recovered 212 domains on which it had appeared over 22 months.
| Domain | Registered | Tag first seen | Certificate batch |
|---|---|---|---|
vertexyield[.]example |
2024-12-02 | 2024-12-02 | B-07 |
norhaven-yield[.]example |
2024-12-02 | 2024-12-03 | B-07 |
lumen-assets[.]example |
2024-12-03 | 2024-12-03 | B-07 |
quaybridge-fx[.]example |
2025-01-14 | 2025-01-14 | B-09 |
A shared identifier is a strong lead, not a conclusion. Identifiers travel when templates are copied, and we have seen unrelated operators running cloned sites that still carried the original author's tag. So we tested it. On 197 of the 212 domains, the container appeared within 24 hours of registration, which fits one operator deploying their own sites rather than strangers copying a template months later. The container configuration itself, preserved through archived copies of the script, referenced the same set of advertising conversion identifiers throughout.
Pivot two: certificate history and registration rhythm
Public certificate transparency logs record every certificate issued for a domain. Many of the 212 domains had been covered by multi-domain certificates whose subject alternative name fields listed between 6 and 14 domains each. Grouping domains by shared certificates produced 31 batches, and every batch fell entirely inside our set of 212. No certificate tied our domains to anything outside it.
The registration records told a consistent story. The domains were spread across nine registrars, but they were registered in bursts on weekdays, almost always within a single eight-hour working window in one time zone. There were no weekend registrations at all. That is the rhythm of a small team doing a job, not of a loose ecosystem of independent fraudsters.
Time-zone inference is weak evidence on its own. People travel, use schedulers and work odd hours. We treat it as supporting context and never as a basis for attribution. Here it was useful because it was consistent across 22 months and matched later findings.
Pivot three: the registrant who forgot
Privacy protection was enabled on every domain. Every domain, that is, except one for a brief window. The third domain the operator ever registered had been created without privacy protection, and for 41 hours its public registration record showed a personal webmail address before the protection was switched on. Historical registration records preserved that record.
The address itself proved little. Its local part, the username before the domain, proved more. The same distinctive username belonged to a profile on a freelance developer marketplace offering "trading platform templates". The profile's portfolio included a screenshot of an administration panel. The color scheme, layout and field labels matched the back end of the scam sites, and the browser's address bar in the screenshot showed a partial domain name that matched one of our 212.
The profile carried a name and a photograph. Searching for that photograph returned a professional networking profile under the same name, with an employment history that included web development work during the period the sites were built.
Following the money
We never deposit money into a fraud, so payment details came from two lawful sources: the bank's own records of transfers made by complaining customers, and the deposit instructions displayed publicly on the sites, which we captured during collection. Across live and archived deposit pages, the 212 domains drew on a pool of 37 payment accounts and 4 cryptocurrency deposit addresses.
On the public ledger, standard clustering heuristics, including common-input ownership and change-address analysis, linked all four deposit addresses to a single consolidation wallet. That wallet periodically forwarded funds to deposit addresses at two exchanges. Identifying the account holders at those exchanges requires legal process, which is a job for law enforcement, so we documented the flows and stopped there.
The card payments added the final link. Merchant descriptors on customer statements named two companies. Corporate registry filings showed that both companies had the same nominee director, and public court and property records tied that nominee to the operator's family.
The red team's question: one operator, or a kit?
Every attribution at Aldervane is challenged by a senior analyst who did not work the case. In this case the reviewer put the strongest alternative explanation on the table: the developer sold a template kit, the container identifier came bundled with it, and the 212 sites were run by many unrelated buyers. That hypothesis fitted the developer profile and the shared tag, and it would have made naming one operator a serious error.
We tested what the kit hypothesis predicts. Independent buyers would bring their own payment accounts and their own wallets, and most would replace the bundled analytics container with their own. Instead, deposit pages for all 212 domains drew on the same pool of 37 payment accounts, and every cryptocurrency deposit consolidated into one wallet. A kit explains shared code. It does not explain shared money. The reviewer accepted the attribution at high confidence for the operator and moderate confidence for the nominee's knowledge of the scheme.
A kit explains shared code. It does not explain shared money.
Outcome
Nineteen days after tasking, the bank received a finished report and an evidence bundle containing every capture, its hash and its collection time. It blocked payments to all 37 accounts and filed suspicious activity reports, and its referrals went to law enforcement in two jurisdictions with our package attached. Authorities froze $41.7M across accounts and exchange holdings. Three people were arrested within four months.
Lessons for fraud teams
- Pivot on what operators reuse. Analytics and advertising identifiers, certificate batches, templates, payment rails and usernames outlast domains by months or years.
- Capture before you take down. A takedown destroys evidence and tells the operator what you know. Preserve the full site, source and network requests first.
- Log every pivot. Record what you searched, when, from where and what came back. An attribution you cannot reproduce is an attribution you cannot defend.
- Test the kit hypothesis. Shared code is common in fraud. Ask what a single operator would share that independent buyers would not, and check it.
- Know where open sources stop. Exchange account holders, bank customer records and subscriber data belong to legal process. A good open-source package tells investigators exactly what to request and from whom.
The engagement summary, including timelines and the full outcome, is in the case study 212 domains, one operator. Our approach to grading the confidence of an attribution is explained in Attribution is a standard of proof.