I'm being cyberattacked by Tesla, Inc

Exploitation attempts on your infrastructure may increase if your organization uses common DNS configurations that could be misinterpreted by automated scanning tools.

A website operator has reported being targeted by persistent cyberattack traffic originating from IP addresses associated with Tesla, Inc. The traffic, identified by Assetnote user agents, uses pool-ntp.tesla.com in its Host or Referer headers and attempts various exploits, including SSRF and Log4Shell. The website operator, who hosts an NTP server that is part of the NTP Pool, speculates that Tesla's asset discovery process may be misidentifying their server as an internal Tesla asset due to a CNAME record from pool-ntp.tesla.com pointing to pool.ntp.org. Similar traffic has been observed by another NTP Pool operator. The operator has attempted to notify Tesla via email but has not yet received a response. Despite over 50,000 requests from these sources since late August, none of the attacks have succeeded.

The incident highlights a potential flaw in how automated security scanning tools inventory and target assets, particularly when CNAME records create indirect associations. Tesla's use of a Tesla-owned CNAME pointing to a public service (NTP Pool) seems to have led Assetnote scanners to erroneously classify the public NTP server IPs as Tesla-owned. This suggests that organizations need to be more diligent in managing their DNS records and ensuring that their public-facing infrastructure does not inadvertently encompass external, non-owned resources within their asset inventory.

This situation underscores the risks associated with shared infrastructure and indirect DNS resolutions, potentially leading to widespread, albeit unintentional, scanning and exploitation attempts against unrelated parties. It raises questions about the efficacy of automated threat exposure management tools and the need for more sophisticated logic to differentiate between owned assets and those reachable through public services. Users of similar services or those with complex DNS setups should be aware of this potential for misclassification and proactively audit their external-facing configurations.