An illustrative case explaining the route

Shipments in transit and an encrypted operations system

A transport and logistics company with a mid-sized fleet and several warehouses. The operations system allocates trips and links them to drivers and customers, and integrates through interfaces with shipping partners and customer platforms. When the system was encrypted, dozens of shipments were genuinely in transit — and time here does not wait for recovery.

Transport & logistics

What was affected

  • The operations and trip allocation system.
  • The routes database and customer data.
  • The archive of signed proof of delivery.
  • Integration interfaces with shipping partners.

What had been tried before it reached us

  • Running trips over phone messages with no central record.
  • Reconnecting the integration interfaces with an admin account to see what still worked.
  • Restoring an old copy over the current database.

The route

  1. 01

    A fallback operation before any recovery

    A temporary record of in-flight trips was set up, because the first risk was losing track of shipments on the road, not losing data.

  2. 02

    Cutting integrations rather than fixing them

    Partner interfaces were stopped before examination, to stop the incident reaching their systems or pulling corrupted data into them.

  3. 03

    Looking outside the system

    A trip leaves a trace with the partner, the customer and the billing gateway, so data was gathered from those parties before relying on any single copy.

  4. 04

    Recovering the routes database

    The database file and transaction log were examined, and state was restored to the last consistent point.

  5. 05

    Gradual reconnection

    Partners were reconnected one at a time after verification, not all at once.

The outcome

What came back

  • In-flight trip data from partner records and customer platforms.
  • The routes database and customer data from a daily offline copy.
  • Billing from an external gateway that was unaffected.

What did not

  • Signed proof of delivery for the two days before the incident.
  • Driver notes on completed trips that had not synced.
  • Route amendments entered by hand on the morning of the incident.

What would have changed the outcome

  • Archiving proof of delivery to a second destination as soon as it is signed.
  • Separating operations and tracking systems from the office and email.
  • Written fallback run sheets for trips and delivery during an outage.
  • Integration accounts with limited rights, scoped per partner.

Isolate the device and keep the ransom note.

Send the file extension, the ransom note and a description of the affected devices. We assess the case without inaccurate promises.