When a Tesla DNS Alias Sends Scans to the Wrong Server

Imagine opening a web server log and seeing a cloud scanner request one bizarre path, then another, then another. The requests carry Host: pool-ntp.tesla.com, a User-Agent label naming Assetnote, and payloads aimed at weaknesses in software the server does not run. It feels like Tesla is attacking you. The more careful reading is stranger: an automated attack-surface scan may have followed a DNS trail into somebody else’s machine.

The incident report behind this story recorded more than 50,000 requests from three recurring cloud addresses. The destination was a volunteer Network Time Protocol (NTP) server, unrelated to Tesla, that also happened to run a few web and mail services. How can a server with no corporate relationship receive corporate-scoped exploit probes? The answer begins with a small but consequential mistake: treating a DNS answer as proof of ownership.

A name is not an ownership certificate

DNS, the Domain Name System, translates human-readable names into numeric IP addresses. A CNAME, short for canonical name, is an alias record. It tells a DNS resolver—the software that looks up names—to continue its search at another name. In simplified form, the chain under investigation looked like this:

pool-ntp.tesla.com CNAME pool.ntp.org
pool.ntp.org A 67.215.249.229

An A record maps a name to an IPv4 address. The important detail is what the first line does not say: it does not turn every server behind pool.ntp.org into Tesla infrastructure. The CNAME relationship identifies an alias, not a transfer of ownership. (rfc-editor.org)

The NTP Pool is a shared, volunteer-run time service. Its DNS system distributes users among participating servers, often selecting machines that are geographically or operationally suitable. On September 12, 2026, the project listed 6,217 active servers. That scale is excellent for distributing time synchronization, but it creates a dangerous assumption for security tooling: one hostname can lead to many unrelated operators. (ntppool.org)

HTTP, the Hypertext Transfer Protocol used by web clients, adds another layer of confusion. A scanner can resolve a hostname, connect to the returned IP address, and still send the original hostname in the Host header. Servers use that header to distinguish among several websites sharing one address. So a volunteer machine may receive a request addressed to pool-ntp.tesla.com even though the machine itself has no connection to Tesla. That behavior is normal HTTP, not evidence that the destination belongs to the company.

Where an exposure scanner can lose the plot

Attack surface management, usually shortened to ASM, means discovering and checking an organization’s internet-facing systems: websites, APIs, certificates, cloud resources, subdomains, and exposed services. Assetnote was built for that kind of continuous external discovery and exposure testing. After its acquisition by Searchlight Cyber in 2025, the platform became known as Searchlight Exposure, but the underlying idea remains the same: find assets from an attacker’s point of view and test them. (slcyber.io)

The logs do not reveal the scanner’s internal algorithm, so the following is an inference rather than a confirmed implementation detail. A discovery system may have found pool-ntp.tesla.com, resolved its CNAME, received an address belonging to an NTP Pool member, and stored that address as part of Tesla’s asset inventory. The next stage then treated the address as authorized infrastructure and began active checks.

That is the boundary failure. A safer inventory would preserve the whole relationship:

company hostname → CNAME chain → current IP address → shared service

Those are four different facts. Collapsing them into one label—“Tesla asset”—turns a legitimate discovery result into a false ownership claim. DNS time-to-live values, or TTLs, make the problem harder because an address may be cached for a while and then change later.

Why the traffic looked like an attack

The scanner was not performing passive observation. It sent requests designed to provoke responses from vulnerable software. The logs included path-traversal attempts, probes for content-management systems, tests for unexpected administrative endpoints, and callback domains intended to reveal outbound connections.

One category was SSRF, or Server-Side Request Forgery. In an SSRF attack, an attacker tricks a server into making a request on the attacker’s behalf, potentially reaching internal services that are not exposed directly to the internet. A callback hostname gives the scanner a place to observe whether that outbound request happened. (owasp.org)

Another category involved Log4Shell, a serious vulnerability in the Apache Log4j logging library. Specially crafted input could cause vulnerable applications to perform dangerous Java Naming and Directory Interface lookups, which in some configurations enabled remote code execution. Testing for that weakness makes sense on an authorized application; sending the same test to a hobbyist server is a very different matter. (logging.apache.org)

These requests do not prove that the scanner gained access. In this case, the operator reported that none of the probes succeeded. They still consumed bandwidth, filled logs, touched unrelated services, and created the unsettling appearance of a targeted campaign. A custom response page explaining the mistake did not stop the traffic, which is another reminder that automated scanners may not read response bodies or understand unusual status codes.

The practical lesson is about identity

The logs also showed HTTP requests arriving on ports associated with SSH and mail services. That likely came from generic port-discovery logic: once a scanner finds an open socket, it tries a familiar protocol against it. A machine can provide NTP on one port, web traffic on another, and mail or remote administration elsewhere. An HTTP request landing on the wrong service is noisy, but it also reveals how quickly a broad scanner can move from “find an address” to “try everything.”

Safer exposure testing should:

• keep hostnames, CNAME chains, IP addresses, certificates, and ownership evidence as separate fields;
• treat dynamic or shared DNS destinations as third-party infrastructure until ownership is verified;
• attach active tests to an explicitly authorized hostname-and-address pair, not to an IP address alone;
• re-check DNS changes and respect the record’s TTL before continuing a scan; and
• provide a clear stop signal when a destination identifies itself as unrelated infrastructure.

Small operators can help themselves by preserving the full Host, User-Agent, source address, and request path in logs. A clear abuse report, rate limit, or firewall rule can reduce the noise. The larger fix, however, belongs in asset discovery systems: an IP address is a route to a service, not a deed proving who owns it.

The surprising lesson is not that DNS is broken or that security scanning is wrong. Both are useful. The trouble appears when a shared service, a changing DNS answer, and an aggressive testing workflow are forced into a single ownership label. Once that happens, a volunteer server can look like corporate infrastructure—and a defensive scan can feel indistinguishable from an attack.