Alleged Stuxnet involvement in the INSAT-4B transponder failure (2010, claim refuted)
What happened
In July 2010 the Indian communications satellite INSAT-4B suffered a power failure in one of its two solar arrays, taking twelve of its twenty-four transponders out of service and affecting a large share of India's direct-to-home television capacity. On 29 September 2010 Jeffrey Carr published a post on the Forbes Firewall blog asking whether the Stuxnet worm had caused it. His argument was that the Indian Space Research Organisation is a Siemens customer and that engineers' resumes indicated the presence of Siemens S7-400 PLCs and SIMATIC WinCC at ISRO's Liquid Propulsion Systems Centre, the software combination Stuxnet targets. He raised the further possibility that China rather than Israel had authored Stuxnet and that India's space programme rather than Iran's enrichment programme had been the target. ISRO denied the hypothesis, stating that INSAT-4B has no PLC and that the chance of Stuxnet affecting it was therefore remote. The cause established on review was electrical arcing in a slip ring of one of the solar arrays. This record carries zero technique edges: the claim is an inference chain whose links are contradicted by the operator and superseded by the failure review.
This record exists to retire a claim, not to support one, and it carries no technique edges. The claim is an inference chain: ISRO uses Siemens industrial software somewhere, therefore Stuxnet could have been present at ISRO, therefore Stuxnet caused INSAT-4B's array failure. The last step is contradicted directly by ISRO, which states the satellite has no PLC, and superseded by the failure review's finding of electrical arcing in a solar-array slip ring. Mapping any technique would record an attack the available record says did not happen. SPARTA's bibliography cites the Forbes post against EX-0005, IMP-0006 and RD-0002; all three are rejected on the record, and that rejection is what this entry contributes. It is kept because the claim persists in space-cybersecurity surveys and in SPARTA's own bibliography, usually without the denial or the arcing finding attached, and a reference platform is worth more if a reader can check that here. Note the real sourcing weakness: the two statements that justify the zero-edge decision, ISRO's denial and the arcing finding, are the least well sourced in the record and reach it through secondary coverage. Attach an ISRO or programme anomaly source before publishing, or hold.
Attack vector
None established. The alleged vector was propagation of the Stuxnet worm into Siemens S7-400 PLC and SIMATIC WinCC systems at an ISRO facility; the established cause of the failure is electrical arcing in a solar-array slip ring.
Operational impact
Twelve of twenty-four transponders lost, affecting a large share of India's direct-to-home television capacity. The impact is real; the attribution is not.
Affected segments
space, ground
Disclosed
2010-09-29
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.
Cited in SPARTA's bibliography against the Forbes post. Nothing was corrupted. The array failure was electrical arcing in a slip ring, a mechanical and electrical fault mode with no software component.
Not in the bibliography, and considered because it is the obvious candidate for "Stuxnet did it". Rejected because the premise fails: ISRO states the satellite has no PLC for Stuxnet to act on, and an established non-malicious cause exists.
The transponder loss is real and is degradation of the mission. But the technique is an adversary impact, and no adversary act is established. A record maps techniques to what an actor did, not to what broke.
Also cited. No data were taken, and no source alleges any were.
Also cited. No infrastructure compromise is alleged, let alone established; the hypothesis is about malware reaching a facility, not about an adversary compromising infrastructure to reach a spacecraft.
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.
- Did The Stuxnet Worm Kill India's INSAT-4B Satellite?Researcher blog
Tier 3: A named contributor's blog post hosted on a major business title. It is the source of the claim rather than the source of any fact, and its own argument is explicitly speculative, which is why it is tier 3 despite the publisher.
Tier 1: The spacecraft operator's own statement, published as a PDF on its own site. Authoritative on the date of the failure, on the transponder counts, and on the fact that the cause was a power supply anomaly in one of the two solar panels which an expert team was still studying when it was published. It makes no attribution and names no cause beyond the solar panel.
Every source SafeMode Space reproduces, and on what terms: sources and attribution.