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."
Courtesy by Annie Satia
No comments:
Post a Comment