Daixin Took Data on 5 Million AirAsia Passengers and Every Employee

The Daixin Team claimed a ransomware attack on AirAsia Group on 11 and 12 November 2022, reporting data on five million passengers and all employees. Reporting describes a passenger file containing passenger identifiers, full names and booking identifiers, and an employee file containing photographs, secret questions, secret answers, birth city, birth state, birth country and nationality.

Reporting indicates the airline engaged with the group, received a sample, and did not pursue negotiation further. The group subsequently said it had abandoned deeper attacks on the network, attributing this to the disorganised state of the airline’s internal configuration.

The passenger data is ordinary — names and booking references, unpleasant to lose and bounded in what it enables. The employee file is not.

Security questions and their answers are the fallback path into accounts everywhere else: the bank, the email provider, the government portal. The answers are facts about a person’s life, they were true before the employer collected them, and they remain true afterwards. We filed unresettable identifiers at 26-0726 and 22-0922, and this is that category arriving through an employer rather than a service.

Those three fields, reported together with the security answers, are the classic question set themselves — mother’s home town, place of birth, first school.

An organisation that stores both the questions and the answers has built a lookup table for the recovery flows of every other service its staff use. We have recorded employee data as the consistent and least-considered casualty at 23-1219 and 23-0808, and this is the sharpest instance: the staff had no choice about providing it and no way to invalidate it afterwards.

The group’s reported comment — that the network was too chaotic to be worth exploring further — is an attacker’s claim, offered by a party with reasons to be dismissive, and the desk records it as that.

It is worth recording because it inverts everything else in this database, where clarity of architecture is the thing that limits damage: the isolated system at 23-0217, the ministries kept off the shared platform at 23-0724. If disorganisation deterred anything here it did so after five million records had already gone, which makes it an outcome rather than a defence.