Technical details on the Stuxnet virus / malware

  • Thread starter Thread starter RayLopez99
  • Start date Start date
R

RayLopez99

Of interest is the DLL. Apparently (I could not figure this out) it
was synthetically reconstructed every time the computer booted up (the
Stuxnet malware was a rootkit it seems), and lived only in memory.

RL

http://arstechnica.com/tech-policy/...et-the-most-menacing-malware-in-history.ars/2

When you've seen as many viruses and worms as O Murchu has, you can
glance at a piece of malware and know instantly what it does—this one
is a keystroke logger, that one is a banking Trojan—and whether it was
slapped together sloppily, or carefully crafted and organized. Stuxnet
was the latter. It contained multiple components, all
compartmentalized into different locations to make it easy to swap out
functions and modify the malware as needed.

What most stood out, though, was the way the malware hid those
functions. Normally, Windows functions are loaded as needed from a DLL
file stored on the hard drive. Doing the same with malicious files,
however, would be a giveaway to antivirus software. Instead, Stuxnet
stored its decrypted malicious DLL file only in memory as a kind of
virtual file with a specially crafted name.

It then reprogrammed the Windows API—the interface between the
operating system and the programs that run on top of it—so that every
time a program tried to load a function from a library with that
specially crafted name, it would pull it from memory instead of the
hard drive. Stuxnet was essentially creating an entirely new breed of
ghost file that would not be stored on the hard drive at all, and
hence would be almost impossible to find.
 
Of interest is the DLL.  Apparently (I could not figure this out) it
was synthetically reconstructed every time the computer booted up (the
Stuxnet malware was a rootkit it seems), and lived only in memory.

that's not quite what the description says/means.

it's the *decrypted* version of the malicious DLL that only exists in
memory. the DLL is also stored on disk but in encrypted form.

in theory using encryption to obscure malware is not new, but doing it
in this particular way - decrypting an entire DLL file onto a 'virtual
drive' rather than simply performing run-time decryption of a process
- that's an interesting approach.
 
that's not quite what the description says/means.

it's the *decrypted* version of the malicious DLL that only exists in
memory. the DLL is also stored on disk but in encrypted form.

in theory using encryption to obscure malware is not new, but doing it
in this particular way - decrypting an entire DLL file onto a 'virtual
drive' rather than simply performing run-time decryption of a process
- that's an interesting approach.

I see. That makes sense, to decrypt rather than reconstruct it
everytime. As for virtual drive vs run-time decryption perhaps that's
done to avoid some AV engines.

RL
 
Back
Top