ISRO ISTRAC malware report and refutation (2018)
What happened
In March 2018 security researchers reported that a computer associated with the Indian Space Research Organisation's Telemetry, Tracking and Command Network (ISTRAC) was infected with the XtremeRAT trojan, and the reporting carried the claim that the weakness could have allowed control of ISRO's rocket launch commanding. ISRO published a statement on the information-security incident of 10 March 2018 refuting the report. ISRO records that it received an alert about a trojan in ISTRAC, that subsequent analysis found it to be a false positive, that the address named in the alert was a UTM port not mapped internally to any system and intended for a multi-factor-authenticated login service for specific employees, that the alert derived from a search on a third-party website which wrongly listed the ISTRAC address as infected, and that it was concluded there was no XtremeRAT infection on ISTRAC systems and the reported incident was a false alert. ISRO disabled the reported port as a precaution and later re-enabled the service through an alternate mechanism, and stated that mission-critical systems in ISTRAC are not connected to the internet. A separate and unrelated matter, ISRO's receipt in September 2019 of an alert about Dtrack malware at the time of Chandrayaan-2, is not part of this record.
HOLD: recommended NOT to be imported as an incident. This record exists because SPARTA's bibliography cites the March 2018 press report at three techniques (REC-0004, REC-0009, RD-0002), and because the operator published a statement refuting it. ISRO's account is specific and testable: the flagged address was a UTM port not mapped to any internal system, the alert originated from a third-party site that wrongly listed it, and the conclusion was that there was no infection. Nothing in this batch's sources contradicts that. Edge-less by curation, and the stronger recommendation is that the platform should not carry an incident record for an event the operator investigated and found not to have occurred. The corrective value, which is real, is in showing that three SPARTA citations rest on a report the operator refuted; that belongs in the technique's reference commentary, not in the incident corpus. If the editor decides otherwise, the record is complete and the refutation is in the description rather than only in the gloss. Record confidence moved from low to moderate on 2026-08-18 under decisions entry 157, on the reading in docs/audits/2026-08-18-entry-148-confidence-value-audit.md: the account is established and what is missing is not the account. Entry 148 puts the actor and any one mapping outside this axis.
Attack vector
None established. ISRO's investigation concluded there was no infection and that the alert was a false positive derived from a third-party website's incorrect listing.
Operational impact
None. ISRO disabled the reported port as a precautionary measure and later re-enabled the service by an alternate mechanism.
Data compromised
None reported or alleged by the operator.
Affected segments
ground
Disclosed
2018-03-12
SPARTA techniques evidenced
No SPARTA technique is mapped to this record.
Considered and not mapped
These techniques were considered for this record because a source, a related record or SPARTA's own catalogue pointed at them. Each was read against what the sources say and not mapped. The reason is given in full.
RD-0002 requires that the adversary compromised existing infrastructure. ISRO states the flagged address was a UTM port not mapped to any internal system and that no infection existed. The technique's precondition is exactly what the operator denies.
The operator's investigation concluded there was no infection. There is no adversary behaviour to map, and mapping a reconnaissance technique to a refuted report would put a disputed claim into the corpus as a finding.
The operator's investigation concluded there was no infection, so there is no adversary behaviour to map. Note also that even taking the researchers' report at face value, it reported the presence of a remote-access trojan, not the collection of mission information; the launch-commanding claim was about what could have followed, which is the "what could have happened" reasoning this corpus excludes.
Sources
The published accounts this record rests on. The tier is SafeMode Space's own assessment of the source, and the reason for it is given beside it. What the tiers mean and how they are assigned: the source tiers.
A source is listed when a mapped technique rests on it, or when it disputes the account. One the curators read but neither cited nor recorded as disputing the record is not listed, so an absence here means neither is true rather than that nobody looked.
A source marked contradicting disputes the account above rather than supporting it. It is listed because a reader assessing this record should see it.
- On Information Security Incident of March 10, 2018Operator statement
Tier 1: The affected organisation's own published statement on the incident, hosted on its own domain. Authoritative on its investigation and its findings.
Tier 3: General-interest Indian daily reporting independent researchers' claim. This is the URL SPARTA's own bibliography cites for this incident at three techniques. It is the claim ISRO's statement refutes.
Every source SafeMode Space reproduces, and on what terms: sources and attribution.