From malicious domain to business identity: connecting the evidence

An analyst identifies a fraudulent payment website.

The page displays a familiar company logo. Its domain resembles the company’s name. The hosting address also serves several legitimate businesses.

Which organisation should the threat be linked to?

The company being impersonated? The hosting provider? One of the businesses sharing the infrastructure? The person who registered the domain?

Each may have a relationship with the evidence. Only some of those relationships are relevant to identifying who controls the fraud.

This is one of the harder problems in trust intelligence: connecting technical findings to real organisations without turning association into accusation.

A connection needs a meaning

A domain name, an IP address, an email address and a company name are different kinds of identifiers.

Joining them together can reveal useful context. But a connection needs to explain what it represents.

A domain might be:

• Owned by an organisation.

• Operated on its behalf by a supplier.

• Used by one subsidiary within a larger group.

• Hosted on infrastructure shared with unrelated businesses.

• Impersonating the organisation without its involvement.

• Historically associated with it, but now controlled by someone else.

A database that reduces all these relationships to “associated with Company A” discards the distinction the user needs most.

The useful question is not simply whether two things are connected. It is what the evidence establishes about that connection.

Start with the observation

Consider a fictional investigation.

A website presents itself as the payment portal for “Northbridge Components”, an invented supplier. It uses the company’s branding and asks customers to enter account credentials.

The analyst can initially record that the website claims to represent Northbridge Components.

That is an observation about the page. It does not establish ownership or authorisation.

If a verified representative of the company confirms that the portal is unauthorised, the assessment becomes stronger. If technical analysis also establishes credential theft, the analyst can describe the harmful behaviour and the company being impersonated.

The resulting finding should preserve both facts:

This website is being used for credential theft and impersonates Northbridge Components.

Describing it as Northbridge Components’ malicious website would make a substantially different claim.

Shared infrastructure is a common source of confusion

IP addresses can help connect domains to infrastructure. They rarely provide a complete business identity.

A hosting address may serve many unrelated customers. A content delivery network may stand between a website and its underlying server. The organisation responsible for the network may provide the service without operating the customer’s website.

Cloudflare explicitly warns that IP-based filtering can create false positives because malicious and legitimate domains can share IP addresses.

This creates an important limit for investigations.

If a fraudulent domain and a legitimate supplier’s website resolve to the same shared address, that establishes a technical overlap. It does not establish common ownership, cooperation or compromise.

The same caution applies to shared nameservers, registrars and email providers.

More distinctive combinations can justify further investigation. Their significance still needs to be explained against the possibility of shared services or coincidence.

Registration data provides clues, with limits

Domain registration records can contribute evidence about registration dates, registrars and, where available, registrant information.

They do not always identify the underlying operator publicly.

ICANN’s registration data framework allows for redacted information and privacy or proxy services. A lookup may therefore show limited details or information about an intermediary.

Missing public registrant details should not automatically be treated as evidence of malicious intent.

Equally, a company name appearing in a registration record should be assessed alongside other evidence. An identity claim needs corroboration before it becomes a confident ownership finding.

The registration service, domain registrant, hosting customer and person operating a website may also be different parties. An investigation should avoid silently treating them as one.

Company names are not unique identifiers

Linking a domain to a company introduces a second problem: identifying the right company.

A trading name may differ from the legal entity. Several businesses may use similar names. A brand may belong to a subsidiary, while its website is managed centrally by a parent group.

A useful business record should therefore distinguish between the brand, legal entity and corporate group wherever the evidence supports that detail.

Jurisdiction and company registration numbers can help resolve ambiguity. Official websites, filings and verified business communications can contribute corroboration.

But a real company registration number displayed on a suspicious website does not establish that the company operates the site. That information can be copied along with its address and logo.

Evidence that an organisation exists and evidence that it controls a particular domain are separate findings.

Email addresses need the same discipline

An email address can connect activity to a domain, a person or a business process. It does not automatically establish who performed a particular action.

For example, an address might identify:

• A legitimate shared accounts mailbox.

• An external contractor working for the organisation.

• An account that has been compromised.

• A contact address copied onto a fraudulent page.

• A lookalike address used to impersonate an employee.

Each situation supports different conclusions.

If an attacker uses a compromised mailbox, the address can remain genuinely associated with the company while the message is unauthorised.

If a fraudulent website displays a legitimate support address, that alone does not implicate the mailbox owner.

A useful assessment preserves the distinction between the identity referenced, the account used and the actor responsible.

Relationships need dates

Even a correctly established relationship can become misleading when its history is lost.

A domain may change ownership. An IP address may be reassigned. A supplier may stop operating a service for a customer. A subsidiary may leave a corporate group.

A historical connection can remain valuable to an investigation without describing the present situation.

Records should distinguish when the relationship was observed, when it was last confirmed and whether it is believed to remain current.

A new observation should not silently rewrite the past. An old observation should not silently become a present-day fact.

This is particularly important when combining historical DNS, registration records and recent threat findings.

A graph should preserve the argument

A graph can make complex relationships easier to explore. Its value depends on the meaning and evidence attached to each connection.

For our fictional payment portal, useful relationships might look like this:

• Website claims to represent Northbridge Components. It captured the branding and text. But it doesn't prove company ownership or authorisation.
• Domain resolved to an IP address. Timestamped DNS observation established. But it doesn't link to a dedicated server or prove common ownership with other domains.
• Company confirms the portal is unauthorised. Verification through an established contact. But it does not establish the attacker’s identity.
• Page sends credentials to a collection endpoint. Observed submission behaviour. But it does not established ownership of every service involved.
• Official domain belongs to the supplier. Corroborated company records and verified confirmation. But it does not establish authorisation of every message or page using that domain.

This structure lets an analyst explain how a conclusion was reached.

It also makes corrections possible. If one relationship is disproved, the system can identify which conclusions depended on it.

A visually dense network of connections is not, by itself, a strong case.

Match the response to the finding

Precise relationships support proportionate action.

A confirmed impersonation domain may justify blocking and brand-abuse escalation. A compromised supplier account may require verification through a separate contact and investigation by the supplier. A shared hosting connection may justify further research without supporting a warning against neighbouring businesses.

Automatically transferring risk across every connection can turn one harmful resource into a cloud of unsupported allegations.

The reverse is also dangerous: a connection to a legitimate organisation should not automatically make an unfamiliar resource trustworthy.

Each relationship contributes context. Its meaning determines how it should influence the decision.

What this means for ThreatPrevent

For ThreatPrevent, connecting domains, IP addresses and email addresses to legitimate organisations is valuable because it gives technical intelligence business relevance.

It helps answer questions such as: which supplier is being impersonated, which service is affected and who should verify the interaction?

That value depends on preserving the difference between ownership, service provision, compromise and impersonation.

Our view is that high-confidence intelligence should be able to explain both the finding and the relationship it relies on.

A connection becomes useful intelligence when you can explain what it means, what supports it and where the conclusion stops.