A single phishing domain rarely tells the full story. In this domain clustering investigation case study, an analyst starts with one credential-harvesting hostname and uses registration, DNS, certificate, and naming signals to identify a broader campaign before additional domains become active.

The objective is not to prove that every related domain is malicious. It is to build a defensible cluster, score confidence at the domain level, and turn the result into detection logic that a SOC or threat intelligence pipeline can use immediately.

The Initial Signal

The investigation began with a domain reported in an email gateway alert: microsoft-auth[.]support-portal[.]top. The page imitated a Microsoft 365 login flow, forwarded submitted credentials to an external endpoint, and had been registered less than 24 hours earlier.

Taken alone, the domain was straightforward to block. The operational question was harder: was it an isolated registration, or one component in a larger set of domains staged for the same phishing operation?

A conventional Whois lookup offered limited value. Registrant fields were privacy-protected, the registrar was common, and the record did not explain what the actor might register next. The analyst needed signals with higher investigative value: temporal proximity, lexical construction, nameserver reuse, shared hosting infrastructure, certificate relationships, and passive DNS history.

Building the Domain Cluster

Clustering works when analysts treat a domain as a collection of observable attributes rather than a standalone indicator. Each attribute is weak in isolation. Several independent overlaps, especially when they occur within a short registration window, can establish a meaningful relationship.

For the seed domain, the investigation normalized the hostname into tokens: microsoft, auth, support, and portal. Brand terms alone were not considered strong evidence. They are widely used by unrelated attackers, researchers, and legitimate support services. The more useful feature was the phrase structure: a major brand token followed by generic authentication language, then a low-cost TLD.

The analyst queried newly observed domains registered during the prior 72 hours for similar token patterns. This produced 41 candidates. Most were discarded quickly because they lacked supporting infrastructure overlap or had clearly unrelated content.

The remaining candidates shared a narrower combination of traits. They used permutations such as office-auth, m365-secure, and outlook-support; were registered within a 19-hour period; and used the same pair of authoritative nameservers. Seven also resolved to addresses within the same small hosting allocation shortly after registration.

That did not prove common ownership. Shared nameservers and commodity hosting can create false positives, particularly among low-budget phishing operators. The cluster became actionable only after the analyst compared its DNS changes and TLS artifacts over time.

DNS and Infrastructure Correlation

The seed domain initially resolved to one IP address, then moved to a second address six hours later. Four candidate domains followed the same sequence: no DNS answer at first observation, a short-lived parking response, then an A record pointing to the first address, followed by migration to the second.

The timing mattered. Shared infrastructure is common. Matching infrastructure transitions on the same schedule are less common, particularly when domains were registered in a compressed period and follow a similar naming pattern.

Certificate transparency data added another connection. Five domains appeared in certificates issued through the same automated workflow, with closely aligned issuance timestamps. The certificates were not identical and the issuer was not unique, so this was treated as corroborating context rather than a primary clustering key.

The resulting high-confidence cluster contained 12 domains. Nine served credential phishing content or redirects when collected. Two had no active web content but matched the full registration and DNS sequence. One remained ambiguous and was retained as a watchlist candidate rather than blocked automatically.

What Made the Cluster Defensible

A useful investigation record must separate facts from inference. In this case, the analyst recorded the direct observations for every domain: first-seen time, registration time where available, current and historical DNS answers, nameservers, resolved IPs, certificate observations, HTTP behavior, and lexical features.

The relationship assessment then assigned weight to combinations of evidence. A shared IP alone received low weight. A shared IP combined with same-day registration, matching nameservers, and coordinated DNS migration received a substantially higher score. Content similarity raised confidence further, but the cluster did not depend on content collection alone because phishing pages often change or disappear quickly.

This distinction prevents a common failure mode in infrastructure analysis: treating a broad provider relationship as campaign attribution. A cluster can be operationally useful without naming a specific actor. The evidence supported a shared phishing workflow and common operational control. It did not establish the identity of the individual or group behind it.

Turning Findings Into Detection Logic

The investigation produced more than a list of 12 domains. It generated detection features that could identify the next wave.

The first rule watched for new registrations containing selected brand and authentication token combinations across the relevant TLDs. The second enriched matches with nameserver and DNS data. The third increased severity when a new domain appeared within 48 hours of related registrations and resolved through the infrastructure pattern observed in the cluster.

This layered approach matters because attackers rotate individual components. They may change IP addresses while retaining naming conventions. They may change nameservers while preserving registration timing and TLS automation. A rule built around one indicator will decay quickly. A rule built around multiple features can tolerate controlled variation.

For production use, the workflow should preserve the raw observations and the normalized features separately. Raw fields are necessary for auditing and retrospective analysis. Normalized fields make joins, scoring, and bulk matching practical across large domain populations. This is where cleaned domain intelligence has a direct operational advantage over inconsistent registration records or ad hoc scraping outputs.

Primitive Host is designed for this type of workflow: fresh domain coverage, normalized records, DNS enrichment, bulk analysis, and API access that can feed investigation and alerting systems without a separate ingestion project.

Where Clustering Can Go Wrong

Domain clustering is not a license to block every nearby domain. False positives are a material risk when investigators overvalue a single shared feature.

Common registrars, public DNS providers, free certificate issuers, and large cloud networks create broad, noisy relationships. A domain that shares only one of those attributes with a known phishing site should generally be treated as a lead, not a verdict. The same is true for lexical similarity. Brand impersonation vocabulary is common enough that token matching must be paired with temporal or infrastructure evidence.

There is also a trade-off between early detection and confidence. Watching newly registered domains can surface staging infrastructure before it serves malicious content, but the evidence will often be incomplete. Teams should use graduated outcomes: monitor low-confidence candidates, enrich medium-confidence candidates, and block or alert on high-confidence clusters with multiple independent signals.

Thresholds should reflect the consequence of action. A consumer email security product may block aggressively and provide a review path. An enterprise SOC may prefer an alert with supporting evidence before disrupting access. Detection engineering should make that policy explicit rather than hiding it inside a score.

Operationalizing the Next Investigation

The useful output from a clustering investigation is a repeatable pipeline: ingest new domains, normalize attributes, generate candidate relationships, enrich the strongest candidates, and store evidence with timestamps. The pipeline should also support reclustering. A domain that appears unrelated on day one may become strongly connected after DNS activation, certificate issuance, or hosting migration.

Start from the signal that is most stable for the campaign under review. For some operations, that will be registration timing and nameserver reuse. For others, it may be DNS infrastructure, redirect behavior, or a distinctive domain-generation pattern. The right model depends on the actor's tradecraft and the visibility available to the team.

The practical advantage is speed. When one suspicious domain arrives, the response should not end with a blocklist entry. It should create a structured path to identify adjacent infrastructure, quantify confidence, and deploy detections while the campaign is still forming.