Your VSOC, your PSIRT, your SIEM — and the fleet-API attack still drives your fleet.
It never breaks anything. It logs in with a real customer's stolen session, so behavioral detection sees a customer; it rotates across Amazon, Google and Azure, so your SIEM correlates a meaningless last IP; and by the time PSIRT has an advisory, the fleet's telematics is already resold. Two capabilities are missing from every connected-vehicle program — and neither of them is a new console.
whisper verify --trustless — anchored at the IANA DNS root. Our own API is not in the trust path.
No layer of your program is wrong. The attack is engineered to fall in the seams between them.
You specced cyber into every sourced component, stood up a VSOC, ran a PSIRT, and route it all into the SIEM. Here is what each layer sees when a fleet-API abuse campaign runs — and why the fleet still leaks.
A valid session, behaving like a customer
The credential is genuine and the requests are low-and-slow, under every rate limit. Behaviorally it is one of your drivers — there is nothing anomalous to alert on until the enumeration is already done.
A last IP that means nothing
Egress hops Amazon → Google → Azure, or a residential-proxy swarm, every few requests. Each event carries a fresh source IP, so correlation across them yields a rotating fog — and a block on noise.
An advisory after the scrape
By the time the pattern is understood and triaged, whole-fleet telematics is harvested and resold with no contract. It's a GDPR and EU-Data-Act incident, not only a security one.
Two structural gaps live in that seam, and every connected-vehicle program shares both. Close them and the attack has nowhere left to stand.
Strip the incident down and it isn't a hundred bugs. It's two.
Both are the kind a red-teamer names on sight — not a compliance checkbox. Here they are, and here's exactly how each closes.
Rate-limit an IP and they spin up a fresh one. The egress is disposable; the last IP was never the attacker. So you block noise while the operator keeps working.
The answer — the graph. A live internet-infrastructure graph — 7.44B nodes and 39.3B relationships of fused BGP, DNS, WHOIS, TLS, hosting and threat intelligence, answering in under 300 ms — fingerprints the operator, not the IP. Two levers, kept honestly separate: for cloud rotation the graph clusters shared ASN, hosting and certificate lineage into one infrastructure genealogy; for a residential-proxy swarm — where a subscriber IP gives an infra graph nothing to grab — a JA4/JA3 client fingerprint travels with the tooling regardless of the exit and collapses the swarm to one operator. Every answer returns a reproducible evidence chain your VSOC, your auditors and a regulator can replay.
"When they rotate residential proxies and fresh cloud IPs, can you actually attribute them — or just rate-limit an IP and move on?"
Track them. Infrastructure genealogy collapses the cloud rotation; a JA4 client fingerprint collapses the residential swarm. The egress IP is the one thing we don't rely on, and every finding lands in your SIEM as a reproducible, replayable evidence chain, not a hunch.
A stolen session or a leaked dealer-portal key is a valid credential. Behaviorally it's a customer. Nothing at the perimeter separates it, because the credential is a bearer secret — whoever holds it can present it.
The answer — identity. Bind the session to the car's own forge-proof /128 — an address derived from the key already sitting in the vehicle's secure element, one the car can prove and no aggregator can. A stolen token without the car's leaf key simply fails, and the failure is a first-class, loggable event your PSIRT can act on.
"A leaked API key or a valid dealer-portal session looks legitimate — how do you catch abuse that passes auth?"
You bind authority to the car, not the bearer. State-changing fleet commands terminate mutually-authenticated to the target car's /128 — the car co-signs — so a dealer or owner session can't reach a VIN it can't cryptographically address. A request that passes auth but can't prove the identity never had authority in the first place.
Gap 1 is detection made durable. Gap 2 is the root cause. Both arrive where your analysts already work — read on for the wiring.
Three planes on one primitive — and all three exit into the stack you already run.
The primitive is one line: the address is the identity — a routable IPv6 /128 out of 2a04:2a01::/32 (announced by AS219419), DNSSEC-anchored, DANE-EE pinned, verifiable by anyone with dig. Point it at your fleet and you get three planes, no new silo.
Identity
Each vehicle's or ECU's /128 is derived inside the secure element from the key it already holds — the TPM, the IEEE 802.1AR IDevID, with the VIN or ECU serial as the domain separator. The backend authorizes on the car's pinned identity, not a stealable token. Who is this, provably.
Attribution graph
The operator fingerprint across rotating clouds and residential proxies — infrastructure genealogy plus JA4/JA3 — with a reproducible evidence chain on every answer. Who's really behind this, when the IP rotates.
Agent governance
Every AI agent egresses from its own /128; every query and connection logged per-agent; a graph-first resolver enforces default-deny policy per query; one revoke and a kill-switch. What may talk to what, on the SDV surface you're about to run.
Findings arrive where your analysts already work — as evidence, not another alert to babysit.
Every attribution and identity finding is a reproducible, replayable JSON evidence chain. It fans out into your SIEM, into a form your peers and Auto-ISAC can ingest, and into the artifacts your type-approval file needs, from the same object.
# STIX 2.1 sighting — one operator behind a rotating egress, with the ATM tag
{
"type": "sighting", "spec_version": "2.1",
"sighting_of_ref": "indicator--fleet-api-enumeration",
"count": 41, # 41 exit IPs → 1 operator
"x_whisper_operator": "<fingerprinted>",
"x_whisper_ja4": "t13d1516h2_8daaf6152771_…", # tooling, not exit
"x_atm": { "tactic": "Initial Access",
"technique": "Exploit Connected-Vehicle API" },
"x_whisper_evidence": "https://verify… (signed, replayable)"
}
# the matching Microsoft Sentinel analytics rule — one line of KQL
# WhisperFindings | where OperatorConfidence > 0.9 | where DistinctVINs > 25The Splunk connector ships today, with Microsoft Sentinel and OpenCTI next and more on the roadmap. Findings map cleanly onto CEF and ECS fields, with STIX 2.1 over TAXII export on the roadmap; a Splunk CIM mapping and a sample Sentinel analytics rule ship in the docs. For PSIRT, a finding is not a raw alert — it is an attributed operator plus a signed evidence chain your triage can act on, and hand to a regulator unchanged.
And the raw material is already on your side of the wire: the per-/128 egress logs — every query and connection a car or its agents made, keyed to its own address — together with the attribution graph are ready-made UN R155 CSMS monitoring and forensics evidence. Each record is mappable to an Auto-ISAC ATM technique before it ever leaves your VSOC, so continuous monitoring and post-incident forensics come out of the same signed object your SIEM already ingests — not a second collection you have to stand up.
In your auth path — and safe there
If your backend authorizes against the DANE/verify path, that plane is built to fail open. A Whisper outage never bricks a car: the check degrades to the anchors you already ship, and connectivity is preserved. Conservative in what we emit, liberal in what we accept — a car is never denied because we were unreachable.
Mapped to R155, ISO 21434 and the Auto-ISAC ATM — as evidence you can file, not a dashboard you screenshot.
Every capability lands on a clause and produces an artifact. The Auto-ISAC Automotive Threat Matrix — the ATT&CK-for-cars, roughly 13 tactics and 80 techniques — is machine-readable, so findings tag cleanly to ATM tactics and techniques, with ATM JSON export to Auto-ISAC and your peers on the roadmap.
| Capability | Standard / clause | Evidence artifact |
|---|---|---|
| Attributed operator across rotating infrastructure | UN R155 — CSMS monitoring, detection & response | Signed, replayable evidence chain · STIX 2.1 sighting export (roadmap) |
| Post-auth identity binding (car co-signs) | ISO/SAE 21434 — cybersecurity controls · UN R155 CSMS | DANE-EE pin · verify transcript |
| Per-component identity + one-call revoke | ISO/SAE 21434 — TARA & interface agreements | Identity register · revoke log |
| Threat coverage, tagged to a shared taxonomy | Auto-ISAC ATM — tactics & techniques | ATM-tagged findings · ATM JSON export (roadmap) |
| Identity re-key on ECU swap / OTA | UN R156 — SUMS update lifecycle | Re-register / revoke lifecycle log |
| Authorized-user vs unauthorized-aggregator line | EU Data Act (in force 12 Sep 2025) · GDPR | Verifiable per-party identity · per-agent logs |
# ROADMAP — Auto-ISAC ATM (JSON) export · the shape a finding will take
{
"framework": "auto-isac-atm",
"findings": [
{ "tactic": "Initial Access",
"technique": "Exploit Connected-Vehicle API",
"operator": "<fingerprinted>", "distinct_vins": 41,
"evidence": "signed · replayable",
"iso21434_ref": "TARA / threat scenario",
"r155_ref": "CSMS 7.3.7 detection" }
]
}
# hand it to Auto-ISAC and your peers unchanged — machine-readable, not a PDFUsable in TARA and type approval, and shareable in the cross-OEM channel you already sit in — not a bespoke report a peer has to re-key. See the full mapping in the docs →
On-prem or your own tenant — and a vendor whose own posture survives your review.
Data residency & GDPR by construction
Run the graph and the per-agent logs on-prem or in your own tenant, in the jurisdiction your regulator requires. Nothing about your fleet leaves where you put it; there is no shared multi-tenant lake your data lands in by default.
No external dependency on the hot path
Resolution, identity verification and RDAP are answered by self-contained nodes — no chatty third-party call at serve time. If an upstream is slow or down, we fail open and keep serving. That's an availability property your assessors can test, not a promise.
A minimal, published attack surface
Standard ports, standard tooling (dig, kdig, curl), an SBOM you can diff, and a wire format that is strict on what it emits and liberal in what it accepts. The identity primitive is verifiable without trusting us — whisper verify --trustless anchors at the IANA root.
Real address space, operated as such
The identities live in production IPv6 (2a04:2a01::/32, AS219419) that we announce and run. This isn't a lab allocation — it's registry-anchored, RDAP-resolvable space, treated with the discipline that implies.
Priced so you can forecast it, from a vendor built to outlast the question.
And the timing isn't yours to choose. The EU Data Act — in force since 12 September 2025, accessibility-by-design from September 2026 — obliges you to open in-vehicle data to the third parties a user chooses, multiplying the parties calling your fleet APIs at the exact moment UN R155 obliges you to monitor and control them. That is the procurement forcing function: the Data Act makes you open the doors; Whisper is the doorway that knows who walked through — and can shut it on one.
Flat, predictable pricing
Per-VIN per-year and flat — not per-transaction, not usage-metered. Against 40-billion-API-call-a-month economics that's a line item you can forecast, not a metered cloud bill you can't, and not a rigid module bundle you have to justify. See pricing →
ROI your CFO can read
Analyst-hours saved not correlating disposable IPs. Warranty and recall exposure reduced when a compromised component is one revoke, not a fleet-wide OTA campaign or password reset. A GDPR/Data-Act incident avoided is the whole year's budget.
A vendor that will still be here
Real routable address space (AS219419), run by people who ran the internet's regional address registry and operated one of its root DNS servers. Auto-security startups fail — one raised roughly $60M and folded; we built infrastructure to outlast that question, not a feature to sell into it.
Feeds the SIEM you already run
Depth on top of the stack you own — a machine-readable feed that makes Recorded Future, Mandiant and Sentinel sharper. It doesn't replace them, and it doesn't add a console your analysts babysit. See the full comparison →
Spec it into your supply chain
Write Whisper identity into your cybersecurity interface agreements so every sourced TCU and ECU ships identity-ready from the supplier — the defense-in-depth you already require, extended to the network layer.
A procurement path with an off-ramp
Keyless POC today — verify and attribute with no account, no contract, no risk. Then a paid pilot on one model line, then enterprise across the fleet. Every stage is verifiable before the next, because our API is never in the trust path.
Don't take our word for it — our API isn't in the trust path.
Two tiers, by design. No key: anyone on your team can verify a car's identity — trustless, anchored at the IANA root. Your key: back-trace a suspicious host through the graph API, provision a vehicle, govern its agents, feed the findings into your SIEM, and revoke it worldwide.
# keyless — re-derive and verify any car's identity, trustless
$ whisper verify --trustless 2a04:2a01:1c0::c0de
✓ DNSSEC chain valid to the IANA root
✓ DANE-EE (TLSA) leaf matches the identity's key
✓ RDAP: registered under AS219419 · 2a04:2a01::/32
identity: VERIFIED — and our own API was never trusted
# who really operates a suspicious host — the public graph API (with your key)
$ curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \
-H 'content-type: application/json' -d '{"query":"CALL whisper.identify(\"34.90.x.x\")"}'
operator: <fingerprinted> · seen across AWS / GCP / Azure
residential swarm collapsed by JA4: same tooling, 41 exit IPs → 1 operator# give a car a name it can prove, and wire the findings into your stack
$ export WHISPER_API_KEY=whisper_live_xxx
$ whisper register --vin WVW… --from-idevid
→ identity 2a04:2a01:1c0::c0de DNSSEC + DANE live
$ whisper policy set --default deny --allow api.oem.com,ota.oem.com
$ whisper logs 2a04:2a01:1c0::c0de # per-/128 evidence for your SOC
# STIX/TAXII → your SIEM, and Auto-ISAC ATM (JSON) export — on the roadmap
$ whisper revoke 2a04:2a01:1c0::c0de # worldwide, at DNS-TTLAdditive to your stack. Mapped to your standards. Priced so you can say yes.
Durable attribution and post-auth identity, fed into the VSOC, PSIRT and SIEM you already run — on-prem, mapped to R155 / ISO 21434 / the Auto-ISAC ATM, from a vendor built to outlast the question. Keyless to try, one call to provision, one more to revoke.
Or run whisper verify --trustless right now.