Some clumsy coding discovered during an analysis of the Shamoon malware has led researchers to conclude that it is probably not related to the Wiper malware that hit some Iranian networks recently and likely isn’t the work of serious programmers.
A prime error appears to come from the main executable — the dropper — which in some systems is launched as a service to create a scheduled task, only the programming works incorrectly due to the date August 15, 2012 being hard-coded into the malware. Thus, if the current year is 2013 or later but the month is earlier than August, the malware reads the date as arriving before the August 2012 checkpoint value.
“This error indirectly confirms our initial conclusion that the Shamoon malware is not the Wiper malware that attacked Iranian systems,” wrote Kaspersky Lab researcher Dmitry Tarakanov in a Securelist post. “Wiper is presumed to be a cyber-weapon and, if so, it should have been developed by a team of professionals. But experienced programmers would hardly be expected to mess up a date comparison routine.”
“Wiper” was the name researchers gave to malware that was discovered earlier this summer on some networks in Iran erasing data from infected machines. Like that malware, Shamoon steals data from infected computers before overwriting the master boot record, rendering compromised machines unbootable. But upon further analysis, researchers realized the two pieces of malware differed.
In an earlier post by another Kaspersky Lab expert, Shamoon was considered an imitation of the earlier malware tied to energy systems. “It is more likely that this is a copycat, the work of a script kiddies inspired by the story. Nowadays, destructive malware is rare; the main focus of cybercriminals is financial profit. Cases like the one here do not appear very often.”
Tarakanov outlined evidence for such a conclusion by examining how the program runs in a typical 32-bit operating system. For instance, the program expects arguments that work like a list of IP addresses linked to computers targeted for infection. When the program runs without such arguments, it must rely on a service it installs locally, called a distributed link tracking server, to ensure the malware reboots and changes workstation configurations whenever the operating system loads.
“There is an easier way to force the OS to run a service at startup – just set up the appropriate option of a particular service,” Tarakanov wrote. “Moreover, ‘TrkSvr’ gets created by malware with that option adjusted to start automatically. Why the author followed this method, with dependencies, is difficult to understand.”
