When 100 phishing alerts were not 100 registered domains

Imagine opening Onlooker and finding more than 100 domains containing your brand name. That was the scene facing our team while reviewing findings for one of our beta test clients.

At first glance, it looked like a large, coordinated domain-registration campaign. More than 100 potential impersonation domains is the sort of signal that deserves immediate attention.

But alerts are the beginning of an investigation, not its conclusion. As our team worked through the evidence, an unusual pattern turned what looked like a mass phishing campaign into a useful lesson about certificate and DNS data.

One country-code domain kept appearing

The first clue was consistency: every domain ended in .ph, the country-code top-level domain for the Philippines. Each finding was associated with an issued TLS certificate, yet the apparent volume and concentration in a single top-level domain felt odd.

For privacy, we have replaced the client's brand and the infrastructure details in this article. The findings looked roughly like this:

• aexample.com
• bexample.com
• examplec.com
• exampled.com

A certificate can be an important signal. Newly issued certificates for domains that resemble a company name can indicate infrastructure being prepared for phishing, credential theft, or another impersonation campaign. In this case, however, the surrounding evidence did not fit that explanation neatly.

Following the usual investigation path

Our team began with the standard checks: certificate details, registration data, DNS records, and the infrastructure behind the hostnames.

The results became stranger as we compared the findings:

• Every hostname resolved to the same IPv4 address, shown here as 45.79.222.138.
• We could not find domain-registration records for the names in question.
• We found no meaningful historical certificate activity for the hostnames.
• The names appeared new, but there was no evidence that more than 100 separate domains had actually been registered.

An absence of certificate history is not unusual for newly prepared phishing infrastructure. Taken alone, that detail would not have reduced our concern. The shared IP address and missing registration data were more interesting, especially when repeated across every result.

The random-domain test

To test whether the pattern was specific to the client's brand, our team tried a randomly generated, apparently unregistered name under .ph. It returned the same DNS A record: 45.79.222.138.

That changed the direction of the investigation. If a random, unregistered name behaved exactly like the brand-matching findings, the shared response was probably a property of the domain or parking infrastructure rather than evidence that an attacker had registered each name individually.

We then reviewed the destination through urlscan.io. The page presented a generic "domain for sale" experience rather than a brand clone, login form, or other client-specific content.

The evidence suggested wildcard-like behaviour: queries for otherwise nonexistent .ph names were resolving to a common parking IP. Requests reaching that infrastructure appeared able to produce a valid certificate and display the same sales landing page.

How might the certificates have been triggered?

Our working theory is that an external scanner generated or tested many brand-containing .ph names. Those requests reached the shared parking infrastructure, which then initiated on-demand certificate issuance through Let's Encrypt. The resulting certificates became publicly observable, and Onlooker correctly surfaced the brand-matching names.

This is an inference from the common DNS response, parking page, certificate observations, and lack of corresponding registration data. Without access to the operator's systems, we cannot confirm precisely which scanner made the requests or how the certificate automation was configured.

That distinction matters. The certificates were real signals, but they did not necessarily represent more than 100 domains deliberately registered by a threat actor. In this case, automated scanning and wildcard-like parking behaviour offered a better explanation for the cluster of findings.

What our team learned

The investigation reinforced several principles we use when triaging domain and certificate findings:

• Treat a certificate as a lead, not a verdict. Issuance shows that infrastructure responded for a name; it does not, by itself, prove malicious ownership or intent.
• Compare the whole cluster. A shared IP address, identical page content, matching certificate patterns, and the same top-level domain can reveal infrastructure-level behaviour.
• Check whether the domain is actually registered. Certificate transparency and DNS observations should be assessed alongside registration data rather than treated as interchangeable evidence.
• Test the hypothesis with a control. A random, non-brand .ph name returning the same result was the observation that helped separate a systemic response from client-specific targeting.
• Keep uncertainty visible. We could explain the evidence without claiming to know who ran the scan or exactly how the parking provider's automation worked.

Most importantly, the initial alert was still valuable. Without it, we would not have identified and documented this unusual behaviour. Onlooker gave our team the starting point; investigation and correlation supplied the context needed to distinguish a likely infrastructure artefact from an urgent mass-registration incident.

Turn alerts into answers with Onlooker

Onlooker helps teams detect brand-matching domains and certificates, connect the surrounding DNS and infrastructure signals, and investigate what those findings actually mean.

Start your 7-day free trial of Onlooker and begin monitoring your domains today.