I’m being cyberattacked by Tesla, Inc

我正遭受来自特斯拉公司的网络攻击

I’m being cyberattacked by Tesla, Inc. 2026-09-13 UPDATE: RESOLVED Patrik from Assetnote reached out to me with a very gracious message, it has been resolved. Thank you! 我正遭受来自特斯拉公司的网络攻击。2026年9月13日更新：问题已解决。来自 Assetnote 的 Patrik 联系了我，并发送了一条非常客气的消息，问题已经解决。谢谢！

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. 虽然 IPv4 互联网的阴暗角落里充斥着各种扫描流量和偶尔出现的异常执着的攻击者并不罕见，但在查看 nginx 日志时，我还是发现了一些奇怪的事情。有持续的攻击流量来自三个特定的 IP，奇怪的是，它们携带的 Host 或 Referer 头部信息均指向 pool-ntp.tesla.com，使用 Assetnote 的用户代理（User Agent），并试图通过 SSRF（服务端请求伪造）将我重定向到 Assetnote 的回调 URL。

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. 这些流量来自三个特定的扫描器：54.165.75.96、35.168.63.24 和 52.44.200.251。它们都位于亚马逊云科技（AWS）的自治系统（AMAZON-AES）中。Assetnote 是一款合法的攻击面管理工具（在营销材料中现称为 Searchlight Cyber），它确实使用此类持续威胁暴露扫描器来为客户资产执行自动化检查。假设这确实是 Assetnote 的流量（他们确实使用 AWS，所以这一点吻合），他们一定是把我误认为是特斯拉的内部资产了。

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. 事情是如何发生的：特斯拉将 pool-ntp.tesla.com 设置为指向 pool.ntp.org 的 CNAME 记录。pool.ntp.org 是 NTP 池，这是一个由志愿者提供的 NTP 服务器轮询系统，我也是其中一员。（顺便提一下，他们应该使用供应商区域，而不是在 tesla.com 下使用自己的 CNAME。）推测：Assetnote 抓取了在 tesla.com 下能找到的所有内容，包括 pool-ntp.tesla.com，该域名 CNAME 指向 pool.ntp.org，而后者可以解析到我的机器——67.215.249.229。资产清单将其保存为特斯拉资产，并开始向我这个陌生人发起攻击。

I emailed Tesla about this, and haven’t heard back yet. (The email explained that their asset discovery is unintentionally including every IP that pool-ntp.tesla.com resolves to as in-scope for active scanning, and warned them that they are throwing exploits at strangers’ IPs.) 我为此给特斯拉发了邮件，但尚未收到回复。（邮件中解释了他们的资产发现功能无意中将 pool-ntp.tesla.com 解析到的所有 IP 都纳入了主动扫描范围，并警告他们正在向陌生人的 IP 发起攻击。）

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. 他们的流量：他们尝试了各种针对我的攻击：路径遍历、Webshell 上传、探测软件内部结构、探测 WordPress 及其他 CMS 管理端点、SSRF、Log4Shell 等等。此外还有回调尝试。有 989 个请求嵌入了用于 Log4Shell 和 Text4Shell 检测的 assetnote-callback.com 主机名，另有 114 个请求指向 canary.assetnotessrf.com 进行 SSRF 探测。

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. 一件有趣且我无法解释的事情是，有 15 个请求携带了 Host 头部 login.solarcity.com，全部请求 GET /(S(x))/b/(S(x))in/System.Web.Mvc.dll，我认为这是一种试图将 /b/(S(x))in/ 解析为 /bin/ 的 ASP.NET 技巧。除了 Host 头部，我还发现了一些其他有趣的信息。扫描 Referer 头部、URL 和查询字符串，发现模板本身就内置了主机名，例如：GET /calendars/admin@lowlevelaccess.jlg.com/calendar/../../../mail/lowlevelaccess.jlg.com/admin/.x-attachment-1-y/new/../../../../../../../../../etc/shadow。

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. 出于某种原因，该扫描器还试图在它发现的每个端口上进行 HTTP 通信。我的 SSH、Postfix 和 Dovecot 收到了大量垃圾 HTTP 流量。9 月 8 日，我开始用非标准状态码 299 回应 pool-ntp.tesla.com 的 Host 请求（希望能引起查看扫描日志的人员的注意），并在每个路径的响应体中附带了通知。

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.) 遗憾的是，到目前为止，这种行为似乎并没有改变。他们的攻击均未成功，对此我感到自豪。自 8 月 21 日以来，我已收到来自 Assetnote 主机的超过 50,000 次请求。流量尚未停止；我会在未来更新这篇文章。（是的，我可以直接用防火墙屏蔽他们的 IP，但观察这一切非常有趣。）