Overview
.jpg)
Three weeks ago, the Taipei Times reported that on April 5th 2026 a university student halted several Taiwan High-Speed Rail (THSR) trains by maliciously transmitting an unauthorized high-priority "General Alarm" message over its TETRA network after deducing the required parameters from SDR captures. While the safety impact was limited, the potential for serious disruption and psychological effects were not - especially if this scenario would have been carried out with more professional tradecraft.
At Midnight Blue, we have been warning asset owners of the risks faced by TETRA-based OT networks - specifically highlighting rail - ever since our TETRA:BURST research disclosures in 2023. Unfortunately, too often we have found that vendors and system integrators continue to downplay attack feasibility while asset owners are slow to adopt adequate mitigations.
In this blogpost, we will analyze the THSR incident using Taiwanese media sources, technical OSINT, and our TETRA and railway domain knowledge and address some of the incomplete or incorrect commentary that has been doing the rounds in the media as well as how something seems a bit off about the forensics explanation.
We will also address how widespread susceptibility to this kind of attack is since this incident and similar ones [1,2] in Poland show just how feasible RF-based attacks on critical infrastructure can be.
In part 2, we will discuss what could have happened if this had been a more sophisticated attacker.
Contrary to what has been widely reported in the cybersecurity media, we consider the most likely course of events for this incident to be roughly as follows:
Taiwan High Speed Rail Corporation (THSRC) operates a single, 350km long high-speed rail line along the western coast of Taiwan with a monthly ridership of roughly 7 million people. The system is based on Japan's famous Shinkansen bullet train and its rolling stock is derived from Shinkansen trainsets.
According to the Taipei Times on April 5th, 2026 at 23:23 local time an unauthorized so-called General Alarm signal was sent to TSHRC's control center from the Taichung area which caused several operating trains to temporarily halt services before restarting them at 23:43. The incident occurred during the traditional Qingming Ancestral Festival which typically sees holiday-related travel increases. The student maintained the incident was the result of an accidental button press on a cloned radio they had in their pocket.
Even though perceptions of delay acceptability are very different in East Asia, with THSR having a 99-100% puntuality rate and average delays of < 1 minute, this only caused a 48-minute delay so as far as actual cyber-physical impact is concerned the incident is negligible.
What made this incident worrying, however, was the technical simplicity of the attack and the fact it was carried out by a 23-year old student with cheap hardware was able to carry it out. With professional tradecraft and a slightly more sophisticated setup, the impact of the attack could have been greatly amplified - leading at least to much longer disruptions and possibly other impacts.
The other worrying aspect was that this attack was carried out against THSR's Terrestrial Trunked Radio (TETRA) network. Ever since our original TETRA:BURST research was published in 2023 (and privately in the year leading up to it) and our 2025 follow-up work we have been warning asset owners of the potential for abuse of this technology in Operational Technology (OT) networks.
Unfortunately, ETSI, vendors, and system integrators have continued to downplay, misrepresent, and misunderstand the nature of these vulnerabilities leaving many asset owners to take inadequate mitigations.
Since the incident was made public, there has been a lot of speculation and general commentary in the media which has highlighted a general lack of understanding regarding the security of TETRA and similar digital trunked radio systems.
A lot of the industry commentary has focused on deriding legacy technologies, security-through-obscurity, a cited lack of parameter rotation, insider threats and cloned authentication keys, and vaguely defined capture-and-replay attacks - none of which accurately describe what seems to have happened here.
The Taipei Times reported that the student had used a Software-Defined Radio (SDR) platform to capture and analyze TSHR TETRA signals and subsequently programmed them into TETRA handheld radios. Photographs show 11 professional radios were seized from the student's house, seemingly including at least 3 Motorola MTP3000 series TETRA radios, as well as an RTL-SDR Blog v3/v4 dongle, laptop, and two mobile phones.
Chinese-language media coverage from UDN and Newtalk, as first reported by RTL-SDR, mentioned that THSR's TETRA network has been in service for 19 years without "meaningfully rotating the parameters" - not specifying which parameters they mean but stating that the student "decoded the relevant parameters from captured traffic" in addition to being supplied with some "critical parameters" by a 20- or 21 year old accomplice before "programming the parameters into one of the handheld radios".
Taichung politician Ho Shin-chun stated during a Transportation Committee meeting that the student had cracked seven layers of verification mechanisms to transmit the false alarm. The Chinese-language reporting states that "due to public safety considerations police, fire, and railway radios are now encrypted; high-speed rail radios also have encryption and defense technologies, yet were still cracked by university students" while stating that it remains unclear how the "seven verification layers were bypassed".
The "General Alarm" (GA) signal transmitted from the student's radio functions as a safety-of-life signal which automatically instructs train drivers in a given area to switch to manual emergency braking. After the THSRC control center observed this signal being triggered, they called back to the source radio to verify the alarm with the person on the other end reportedly "giving contradictory answers and then powering the radio off" after which THSRC started investigating.
Further Chinese-language reporting stated the student was found to have conducted "large scale scanning and hacking" of other radio networks.
There has been a lot of confused industry commentary on this incident, with one example stating that the "lack of parameter rotation" allowed the student "to bypass seven verification layers once he had decoded the relevant credentials" and calling this the "core vulnerability in this case" stating that "the entire attack surface was created and maintained by operational negligence rather than a technical vulnerability in the TETRA protocol itself" with "SDR equipment capable of intercepting and replaying these signals [being] inexpensive and widely available". Other reporting [1,2] also frames the incident as a simple capture-and-retransmit replay attack of the kind integrated into the Flipper Zero - while simultaneously mentioning either authentication keys or TEA1.
It is important to clarify that any sort of replay attack on digital trunking networks such as TETRA, DMR, or P25 are not simple capture-and-retransmit attacks. Digital radio standards such as TETRA are built out of Protocol Data Units (PDUs) with fields enforcing a sensible protocol flow. You cannot just capture raw traffic and blindly retransmit it in the same way you cannot just capture a TCP packet and retransmit it without taking TCP sequence numbers into account. An attacker will need to decode the traffic, extract the parameters and content, and build a new traffic flow to properly transmit it. This requires not just hardware capable of transmitting (which the student's receive-only RTL-SDR dongle wasn't capable of) but also the proper software stack capable of constructing and transmitting valid TETRA traffic.
While at Midnight Blue we have built the TETRA-BLUESTATION FOSS TETRA base station stack, and there exists FOSS TETRA monitoring software, no such FOSS TETRA mobile station / transmission stacks exist. The alternative for the student would have been to either build their own FOSS stack or modify the firmware of an existing TETRA radio (requiring an instrumentation framework to be written after jailbreaking a radio like we did). While feasible for a more sophisticated actor, we consider it highly unlikely the student in question did this.
At Midnight Blue we have in-house tooling for TETRA security evaluations of this kind but building this is not a trivial effort. As such, the student had to program captured parameters into a regular TETRA handheld radio and was thus also bound to the limitations of a well-behaving TETRA software stack (rather than the kind of magic you can do otherwise...).
So far, the most extensive commentary on this incident was written with AI-assisted research and has claimed that the student was likely supplied with the TETRA Authentication Algorithm (TAA1) authentication key K by his accomplice and that this key, together with system parameters (MCC/MNC, Location Area (LA), talkgroup ID, etc.) captured through SDR were programmed into the handheld radio before triggering the General Alarm (GA).
We don't think this is what happened, as we'll explain below.
Based on the relatively scarce OSINT available, it seems that THSRC's TETRA network operates in the 380 MHz band and integrates a Computer-Aided Dispatch (CAD) system with the Motorola DIMETRA TETRA MSO (Mobile Switching Office). The TETRA network allows for both train controller voice communications with drivers as well as failure monitoring, alarm reporting, and passenger information exchange to and from train-borne TETRA radios connected to train computers, and passenger information systems (PIS). In addition, the Event Automatic Reporting System (EARS) receives real-time warnings and maintenance information over TETRA.
While there is no direct public information regarding the security parameters of THSRC's TETRA network, posts on a Taiwanese radio hobbyist forum discuss a broad interest in listening to railway TETRA networks and seem to suggest THSRC's TETRA network is encrypted. Whether it is actually encrypted or the radio hobbyists simply couldn't get their decoding stack to work properly cannot be ascertained - but it does match Chinese-language media reporting that THSRC's TETRA network had encryption or at least some sort of security.
A lot of media and industry reporting has talked about the "General Alarm (GA)" as the "highest-priority TETRA emergency function" which seem to mistake this as some sort of inherent TETRA protocol feature or signal - it is not.
This confusion likely arises from the General Alarm (GA) terminology first reported in Taiwanese media which was possibly derived from Public Address & General Alarm (PAGA) systems. PAGA systems in industrial environments integrate routine and emergency voice and alarm tone communications and are often integrated with handheld TETRA or DMR radios to make sure all personnel receive evacuation alarms (even if they're working in a remote part of an industrial site beyond reach of any sirens). Conversely, they allow for man-down / lone worker functionality on such handheld radios to be coupled to PAGA actions. For example: an injured train driver, heavy machinery worker, or process operator triggering an alarm which in turn raises a general alarm for all personnel and systems affected by the situation.
Handheld radios used in industrial or safety-critical environments typically have emergency functionality which allows for quick triggering of an alert in case a emergency button is pressed or a fall is detected. A worker can push and hold the button (typically for less than a second but long enough to not be too trigger happy) after which the radio will enter emergency operations mode.
Depending on radio configuration, this will send out an Emergency Alarm message to the infrastructure and can either automatically trigger an outgoing emergency call in hot mic mode or result in dispatch operators manually initiating a checkup call to the radio that sent out the alarm.
This seems to match what has been reported in the media: a "General Alarm" of some sort sent out by the student's cloned radio to the control center, which they claim was the result of an accidental button press, followed up by a voice call from the control center during which the student gave contradictory answers and powered off the radio. This also suggests that the identity of the radio the student impersonated was likely a train driver or maintenance worker, as an emergency from non-safety-critical personnel would likely not result in such a dispatcher response.
According to some Chinese-language media, the employee owning the original radio whose identity was cloned was on holiday during the incident with the radio lying in storage at the depot.
Now, from a technical point of view, the Emergency Operations Mode and Emergency Alarm are not part of the ETSI TETRA standard. These are Motorola-specific features (though other vendors have similar features). In ETSI TETRA standard terms, the Emergency Alarm is described as a special status message and likely implemented by most vendors as a Short Data Service (SDS) message with emergency priority. The content of this SDS could be a simple fixed status message or a generic SDS which contains additional metadata useful to the dispatcher.
Assuming this is what happened, and assuming these actions were triggered from a conventional well-behaving Motorola TETRA radio rather than through a SDR with a custom TETRA client stack, the "parameters" the student would have had to know are:
The first 3 parameter groups are fairly trivial to extract using passive interception and an SDR (though identity numbers can be encrypted, these can be either decrypted using the proper key or using deanonymization attack CVE-2022-24403) assuming one spent enough time observing the network.
The last 2 are a little more tricky however.
When considering the question of network authentication, we have to take into account the student used a regular well-behaving TETRA radio. Under such attacker conditions (but NOT when using a TX capable SDR or modified radio firmware), transmitting on an authenticated network requires the legitimate authentication key K.
Under those conditions, it will also require a Motorola Key Value Loader (KVL) device that will cost anywhere between several hundred and several thousand dollars 2nd hand or reverse-engineering the KVL interface (which we consider somewhat unlikely in this case). Knock-off cloned P25 KVLs are available for $100-200 but this does not seem to be the case for TETRA.
The pictures of the seized equipment do not show a KVL device but it is possible the student borrowed one from a friendly radio hobbyist. This still leaves us with the question of how key K was obtained.
While Midnight Blue has demonstrated in the past that exfiltration of TETRA key material from both Motorola and Sepura radios was possible through Remote Code Execution with only very brief physical access, we consider this approach unlikely for a hobbyist student.
The alternative, as industry speculation suggested, is that the student would have been provided with key K by an insider - the "critical parameters" supplied by the accomplice of the main suspect.
Chinese language news mentions that the no one the accomplice's family worked for THSRC. As such we consider it highly unlikely that these parameters included an authentication key since TETRA authentication keys K are always tied to a specific Individual Short Subscriber Identity (ISSI). The suspect would need the exact key K corresponding to the ISSI they are attempting to clone. Moreover, radio owners do not know their own key K since those never leave the infrastructure authentication center after provisioning. This means any insider would have to be either a system administrator or radio depot employee with access to provisioning files or backups.
A Taiwanese TV news segment gives a little more clarity by stating that "high-end walkie-talkies have their own unique device IDs / host numbers and only authorized numbers can access the system" in the context of the parameters provided by the accomplice which suggests this concerned ISSI numbers.
Chinese language reporting states that the perpetrator was looking for a radio which was not in use in order to prevent a conflict when cloning, the required parameters for which were provided by the accomplice. This seems to support the notion that what was provided was an ISSI number. The accomplice stated that these parameters were given to him by an online friend more than two years ago though it is impossible for us to determine whether there is any truth to that statement.
This scenario suggests the network was likely unauthenticated but may have been encrypted, which would match some of the reporting and radio hobbyist rumors, possibly making the network a so-called TETRA Security Class 2 network - which is pretty common for TETRA OT deployments.
If the network was indeed encrypted, this was likely done using TEA1 since this is what critical infrastructure typically gets access to. This means either the main suspect or his accomplice would have had to crack the corresponding key. While the backdoor in TEA1 which Midnight Blue discovered (CVE-2022-24402) showed this only requires a trivial 32-bit brute-force attack, there are some nuances in this case which haven't been reported before.
TEA encryption keys, regardless of cipher, are combined with network information (Carrier Number, Colour Code, Location Area identifier) into the so-called Encryption Cipher Key (ECK). For TEA1, the original 80-bit ECK is compressed into a 32-bit so-called reduced ECK. When brute-forcing TEA1 encrypted traffic, one recovers such a reduced ECK. This has two initial drawbacks:
These drawbacks require not just building a TEA1 brute-force cracker, but also code to reconstruct a full SCK/CCK from several reduced ECKs.
One likely scenario would be that the perpetrators cracked several TEA1 reduced ECKs from different cells or carrier frequencies and recovered the full SCK/CCK. While we typically do not publish weaponized attack code as a rule, some TEA1 cracker implementations of varying quality have started circulating online in the past year. It also cannot be ruled out the perpetrators developed all of their own attack code.
Another likely scenario would be that the perpetrators were provided with the TEA1 SCK by an insider, a fellow radio hobbyist working at or knowing people at THSRC. Contrary to authentication key K knowledge of statically programmed SCKs is typically more widespread in organizations using TETRA.
Another, slightly less likely scenario (if only because it would be quite hard to believe) would be that the THSRC TETRA network was both unauthenticated and unencrypted and all the perpetrators had to do was determine some basic network and radio parameters through passive interception.
The most widely reported version of events is based on the one from the Taipei Times which stated that the student transmitted the alarm using the cloned radio from his residence in Taichung. Various Chinese-language sources describe that when the THSRC control center attempted to verify the alarm through a radio call they subsequently went through their handheld radio fleet and verified every radio was accounted for. Concluding the offending radio had to be cloned THSRC went through TETRA base station logs to determine where the original uplink for the alarm was received, using multi-site signal strength indicators to narrow down the origin of the signal. According to news reports, police then used CCTV footage from around the coverage area to identify the student and trace him to his rental appartment.
Another Chinese-language source reports a different version of events. It states that on April 5th, around 23:00 (just before the incident) the student took a car from his rented apartment to the Wuri High-Speed Rail Station in Taichung. This source states that outside the station, the student turned on his radio and pressed the emergency button after entering the station. Reportedly, the control center observed that the ISSI of the offending radio did not correspond to Wuri station and initiated an investigation. Reportedly, Railway Police Bureau got involved on the 13th and reviewed nearby surveillance footage observing the student behaving suspiciously outside Wuri Station.
At first glance, both versions sound plausible enough. But once you think about it a little, several things don't add up.
First of all TETRA base station coverage areas are huge (one of the system's benefits), 4 to 5 km in dense Urban areas and up to several tens of kilometers in open areas. While at least a few base stations will likely register the same uplink burst and could combine insights into their respective signal strengths, the result is highly related to signal propagation conditions and requires coordination and signalling between base stations.
Taichung is Taiwan's 2nd largest city and has dense urban patches mixed with suburbs and industrial sprawl with underlying flat terrain eventually moving into foothills. It's full of urban canyons and lots of concrete, glass, steel, and moving vehicles causing signal reflections. It's unlikely this allows for meter-level signal geolocation using this approach. Instead, you'd likely get probablistic coverage areas of a few kilometers instead.
In this version of the story, police would have to comb over all CCTV footage in an area of 1-3 km2 looking for someone doing something with a handheld radio. Granted, it's a small time window to look for but gathering all public and private CCTV footage in a 1-3 km2 area and hoping the suspect is out there on a bench or sidewalk in full view of the varying quality CCTV footage you had access to is not a very pleasant search - even with AI assistance. According to Chinese-language media, police made their arrest on 4/28 at 14:00. Allowing some time for bureaucratic legal processes means police would have had to identify the suspect from CCTV in something between 1 and 10 days. This seems quite implausible. Besides, if the Taipei Times is correct then the student transmitted the alarm from his house and would likely not be visible on CCTV in the first place.
The other version of the story is more plausible, assuming the student was telling the truth and either accidentily pressed the emergency button or did so on purpose wanting to observe the result while near the railway station. This would likely have placed him near the train station in full view of CCTV at the exact moment of the Emergency Alarm event.
But there is another possibility: namely that a Location Report from the offending radio was sent to the THSRC network. This could be either the ETSI TS 100 392-18-1 Location Information Protocol (LIP) or Motorola's Location Request/Response Protocol (LRRP). LIP or LRRP are typically sent over SDS and while LIP is technically location determination technology independent, both tend to query a GNSS receiver built into the handheld radio for location data.
For LIP, location reports are transmitted with a confidence level and sometimes even parameters such as direction of travel and altitude. Dependig on radio configuration, location reports can be actively requested or triggered when a radio is powered on or off, a timer expires, or an emergency condition occurs.
Assuming the student's Motorola TETRA radio had its GNSS location service enabled, then it could have automatically transmitted its location to the control center upon pushing the emergency button or the control center could have requested it just before the radio was turned off. With GNSS' meter-level accuracy, it would have been much easier to locate the offender either through a smaller area for which to comb over CCTV footage or in case the student was at home by simply cross-referencing residents of an appartment block with a suspect profile (university student, HAM radio license, ...).
First of all it is critically important to note that merely rotating parameters as advised everywhere in the media is nowhere near enough to harden your TETRA networks. The choice of TEA cipher, key rotation frequency, handheld radio patch level, base station configurations, talk group policies, and the existence of unencrypted downlink injection and keystream oracle scenario's all need to be properly hardened or mitigated against.
This is not a trivial effort and requires a bespoke approach that fits an asset owners particular risk profile to prevent either over- or underspending on the right mitigations .
It is also of paramount importance to note that in TETRA network authentication (regardless of key strenght or rotation practices) does not protect against traffic injection attacks since the procedure is not cryptographically tied to Air Interface Encryption as per CVE-2025-52944. An attacker using an SDR rather than a well-behaving radio can completely ignore network authentication to injection traffic as we demonstrate on a demo electrical substation setup below:
Contrary to popular belief, TETRA is not just used for tactical voice communications but is also used to carry OT telecontrol traffic (over either SDS messages or IP networks via Packet Data) and operator voice commands. TETRA is widely used for this purpose in electric substation telecontrol, water distribution automation, and railway. Usage of TETRA for these purposes is particularly common in light and city rail throughout parts of Europe, Latin America, and Asia.
Similar to what's discussed above, the railway case is particularly interesting because TETRA is used to carry everything from Passenger Information System (PIS) data, Automatic Vehicle Location (AVL) data, and driver communications with dispatchers to vehicle alarms and train controls.
The Taipei Times further reported that police found that in addition to TSHR, the student had programmed radio frequencies of the New Taipei City Fire Department and the Taoyuan International Airport MRT Line. Historically, Taoyuan Airport MRT has used a Motorola Dimetra TETRA radio network and OSINT from system integrators shows that at least at some point, the Taoyuan TETRA network was used for Computer Aided Dispatch (CAD), suggesting a similar incident might have been feasible there too. The New Taipei City Fire Department seems (at some point) to have used a MOTOTRBO DMR network for CAD purposes. The presence of their frequencies in the seized equipment should cause every asset owner relying on TETRA, DMR, P25, or similar technologies to seriously reflect.
In addition, Taiwan Railway (TRA/TRC - not to be confused with THSRC), is the state-owned conventional passenger and freight railway operator in Taiwan. While a different entity from THSRC, TRA historically (and possibly still) used a Motorola TETRA network for rail automation purposes. Based on OSINT, TRA connects its TETRA-based train dispatching radio system (TDRS) to the Centralized Train Control (CTC) system. TDRS transmits alert messages for Automatic Train Protection (ATP) purposes to the CTC for real-time alarming and monitoring of onboard train system status. A similar risk may apply there as well.
For those interested in advancing their RF security skills, including analyzing digital trunking technologies such as TETRA, DMR, and P25, Midnight Blue will be delivering its Red Team SIGINT training at several conferences:
This practically-oriented course, aimed at red team operators and pentesters, will teach attendees the fundamentals of RF, SDR, and SIGINT before quickly moving on to effective guidance on identifying and decoding unknown signals as well as exploiting common pitfalls in RF security.
Where other SDR trainings tend to focus on enterprise and IoT RF protocols such as 4G/5G, WiFi, RFID, and BT, this training focuses on important but rarely addressed RF technologies such as automotive, aviation, marine, and physical access control RF protocols and mission-critical radio (e.g. TETRA, DMR, P25) used by police, military, private security, and critical infrastructure.
Hands-on exercises such as intercepting and decrypting handheld radio comms, analyzing drone video feeds and maritime RF communications, and breaking automotive security systems are alternated with thorough overviews of relevant RF protocols and their security posture as well as case studies of real-world RF attacks on railways, water utilities, drones, and police/military radios.
An overview of the course can be found here.
All items
