The Stuxnet worm that infiltrated sensitive systems associated with Iran's nuclear programme, eventually damaging equipment and delaying its progress, is "full of errors", according to an expert.
Speaking at the Black Hat DC conference this week, security consultant Tom Parker suggested that the code may not have been built by a single elite team as initially thought, but instead by two separate groups.
Parker built a tool to analyse the worm's code, and found that there appears to be a marked difference in quality between the code and exploits, and the subsequent weaponisation of the malware.
However not everyone in the industry agrees. Security researcher and blogger Alexander Sotirov wrote on Twitter: "I'm annoyed by all the armchair critics of Stuxnet. How many nuclear programmes have YOU hacked?"
The worm was coded to hide itself within the nuclear systems by recording the telemetry of normal operations, then playing this back to staff monitoring the systems while it was in the process of causing them to destroy themselves.
However, this was not good enough for security expert Neil Lawson, writing in his blog: "Rather than being proud of its stealth and targeting, the authors should be embarrassed at their amateur approach to hiding the payload."
Lawson added: "I really hope it wasn't written by the USA because I'd like to think our elite cyberweapon developers are at least aware of what Bulgarian teenagers were doing back in the early 90s."
The worm also allowed itself to propagate over the internet, which is unlikely to have been a deliberate capability as it made the code easier to detect.
Parker argued against recent thinking that a Western state had a hand in the worm's coding. "This was probably not a Western state. There were too many mistakes made. There's a lot that went wrong."
Successful leaders are infusing analytics throughout their organisations to drive smarter decisions, enable faster actions and optimise outcomes
Focus on cost efficiency, simplicity, performance, scalability and future-readiness when architecting your data protection strategy