Not part of a guided workflow —
Next best move:Open the platform atlas Atlas
Automotive Red Team Command Center

Authorised emulation · synthetic digital twin

Attack the trust path before an adversary does.

Select a historically demonstrated or emerging automotive attack pattern. Assign it to an authorised supplier, identity, system or component. AutoResilience reconstructs how the exposure could propagate, identifies which controls should stop it, and reveals the exact production and VIN population reached if they do not.

Synthetic digital twin only. No real supplier system is contacted, scanned or altered. No payload, malware or credential is produced or stored. Emulated results are never presented as an actual incident.

Operating modes
Scenario library — 10 archetypes

Remote telematics compromise

RT-01
Historical method adapted to this footprint

The 2015 Uconnect security recall demonstrated that software vulnerabilities could permit unauthorised remote modification and control of certain vehicle systems. NHTSA has described the event as the first cybersecurity safety recall, affecting approximately 1.4 million vehicles.

Public regulatory record — historical fact, quoted as published.

Simulation path

Cellular interface → Telematics unit → Vehicle network boundary → Selected vehicle functions

AutoResilience question

Which vehicle configurations, software versions and VINs inherit the affected telematics pathway?

Compromised supplier remote access

RT-02
Historical method adapted to this footprint

Adversaries commonly combine external remote services with valid accounts to obtain or maintain access.

Established adversary technique catalogue (MITRE ATT&CK) — method, not an automotive incident.

Simulation path

Third-party remote service → Valid supplier / MSP identity → Engineering environment → Release workflow

AutoResilience question

What downstream production authority does this identity indirectly possess?

Trusted software-build manipulation

RT-03
Historical method adapted to this footprint

Software supply-chain compromise is defined as manipulating software or its delivery mechanisms before receipt by the consumer. The documented SolarWinds campaign shows malicious code inserted into a normal build and distributed through trusted updates. This is not an automotive incident, but it is a credible cross-industry method to test against automotive development and OTA trust paths.

Public technique definition and documented campaign — method, adapted to synthetic records.

Simulation path

Development dependency → Build environment → Valid signature → Approved release → ECU lot ECU-LOT-0412

AutoResilience question

Can a signed release be independently proven to match the authorised source and build?

OTA integrity failure

RT-04
Historical method adapted to this footprint

NHTSA's vehicle cybersecurity guidance emphasises maintaining the integrity of over-the-air updates and update infrastructure.

Public regulatory guidance — expectation, not an incident.

Simulation path

Update server / signing authority → OTA package → Campaign population

AutoResilience question

Which VINs are eligible, scheduled, updated, independently verified or still exposed?

Malformed supplier data

RT-05
Synthetic Red Team

The validated exposure is unavailable, stale, contradictory or unsupported supplier information — not a claim that adversaries commonly falsify supplier records.

Synthetic exercise against the digital twin.

Simulation path

Supplier API / file submission → Ingestion service → Quality or genealogy record

AutoResilience question

Can malformed or strategically manipulated supplier data alter the decision boundary without changing the physical component?

Manufacturing availability attack

RT-06
Modelled future scenario

Modelled from present architecture: plant-facing services with shared dependencies and no independent fallback record.

Modelled scenario — not evidence of any event.

Simulation path

Supplier or plant-facing service → Request flooding / resource exhaustion → MES / build / quality dependency

AutoResilience question

Which line stops first, when does it stop, and what alternate source or operating mode remains independently supported?

Sensor or perception manipulation

RT-07
Modelled future scenario

Modelled from shared perception components across configurations. No confirmed vehicle behaviour change is asserted.

Modelled scenario — not evidence of any event.

Simulation path

Sensor input → Processing component → Control unit

AutoResilience question

Which component, software and vehicle configurations share the affected perception chain?

Mobile / API-to-vehicle pathway

RT-08
Modelled future scenario

Modelled from the shared authorisation path between owner application, backend service and remote vehicle commands.

Modelled scenario — not evidence of any event.

Simulation path

Compromised account or API authorisation → Backend service → Remote vehicle command

AutoResilience question

Which identities, APIs, backend services and vehicle configurations share the authorisation path?

Keyless or wireless abuse

RT-09
Modelled future scenario

Modelled from hardware generations sharing one wireless authentication implementation.

Modelled scenario — not evidence of any event.

Simulation path

Wireless interface → Authentication weakness

AutoResilience question

Which hardware generations, suppliers and VIN ranges share the affected implementation?

Recovery compromise

RT-10
Synthetic Red Team

Synthetic exercise: recovery provenance trusted from the same authority as the primary environment.

Synthetic exercise against the digital twin.

Simulation path

Primary environment → Backup and build provenance → Attempted recovery

AutoResilience question

Is recovery independently clean, or does it inherit the same compromised trust source?

This feature must not
  • — Exploit real supplier systems
  • — Scan third parties without written authorisation
  • — Generate deployable malware
  • — Store or use stolen credentials
  • — Interact with criminal marketplaces
  • — Provide attack payloads
  • — Send malformed data into production
  • — Alter production systems
  • — Present emulated evidence as a real incident
Every exercise requires
  • — Named exercise owner
  • — Written scope
  • — Authorised targets
  • — Synthetic / test / live designation
  • — Start and end time
  • — Kill switch
  • — Immutable audit trail
  • — Data isolation
  • — Approval before any connected test
  • — Automatic cleanup and evidence preservation