I wanted to share some of the results of some long hours spent looking at this malware.  When the infection occurs, it immediately places copies of itself  locally on each share and on each share/mapped drive that it finds.  Based on this behavior, my initial thoughts were that the destructive payload would be carried out via shares and/or mapped drives as well.

I now have changed my initial thoughts on how the destruction would occur.  Here are some of my notes from my testing of this concept.  Here is the MD5 from the file I was using:
1c66904ecb846da5b1fb2072f9ea6e0e *New WinZip File.exe

The first test I did led me to believe that the destruction would be carried out via the shares and mapped drives.  In my intial test, I had two infected systems (one XP and one W2K) with drives mapped to each other.  I infected each box, changed the system time to Feb 2 at 11:50pm, launched ethereal, filemon and ran the the first shot using RegShot.  After an hour, I stopped the captures and launched my second shot of the hard drive with RegShot.  All my data files were now over written, zip files were corrupted, etc.  Everything was happening as I thought it would.  All my mapped drives had corrupted files. The security logs from each box showed accesses from the other. 

Then I looked at regshot.  It showed the following registry key was created and pay close attention to the middle value that was added:
----------------------------------
Keys added:1
----------------------------------
HKEY_USERS\S-1-5-21-2052111302-839522115-2092228675-1004\Control Panel\BMale

----------------------------------
Values added:3
----------------------------------
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SchedulingAgent\LastTaskRun: D6 07 02 00 05 00 03 00 02 00 3B 00 01 00 00 00
HKEY_USERS\S-1-5-21-2052111302-839522115-2092228675-1004\Control Panel\BMale\Update: "z: [\\192.168.6.130\c$]\"
HKEY_USERS\S-1-5-21-2052111302-839522115-2092228675-1004\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{75048700-EF1F-11D0-9888-006097DEACF9}
\Count\HRZR_EHAPCY:gvzrqngr.pcy: 08 00 00 00 06 00 00 00 60 C0 9A 42 D7 26 C6 01


Regshot showed a registry key being created on each that referenced my mapped drive to the other box.  Ethereal has traffic to from each box their respective mapped drives.  Everything pointed to the data being accessed via mapped drives.  However, to be sure I ran two more tests.

This time I tested from an infected W2K box to a clean XP box with mapped drives and some shares.  The malware placed copies of itself on all the mapped drives and shares.  I followed the same test procedures as described above using ethereal, filemon and regshot.  I set the time for each of these to be at 11:50pm on 2 Feb and waited.  The destructive payload occured right at 12:30am both times.  I think 12:30 is right on the money. The second time was 12:31, but I think filemon was logging slow due to the load.  So the 30 minutes is right on target.

According to the filemon results, it searches for each file type before moving on to the next file type.  However I did not see it search the same directories for each file type.  It appears some directories get searched for one file type, but not another. The order it occurred was:  

*.doc
*.xls
*.mdb
*.mde
*.ppt
*.pps
*.zip
*.rar
*.pdf
*.psd
*.dmp

Here is something of interest that I noted which I have not seen documented anywhere.  It also searched for two other files a *.ppl and *.exe files.  Below you see the last lines when it is looking for the *.dmp files.  

Update.exe:992    OPEN    C:\WINDOWS\system32\1037\    SUCCESS    Options: Open Directory  Access:   All    
79190    12:32:44 AM    Update.exe:992    DIRECTORY    C:\WINDOWS\system32\1037\    NO SUCH FILE    FileBothDirectoryInformation: *.dmp    
79191    12:32:44 AM    Update.exe:992    CLOSE    C:\WINDOWS\system32\1037\    SUCCESS        
79192    12:32:44 AM    Update.exe:992    OPEN    C:\WINDOWS\system32\1037\    SUCCESS    Options: Open Directory  Access: All    
79193    12:32:44 AM    Update.exe:992    DIRECTORY    C:\WINDOWS\system32\1037\    SUCCESS    FileBothDirectoryInformation: *    
79194    12:32:44 AM    Update.exe:992    DIRECTORY    C:\WINDOWS\system32\1037\    SUCCESS    FileBothDirectoryInformation    
79195    12:32:44 AM    Update.exe:992    DIRECTORY    C:\WINDOWS\system32\1037\    NO MORE FILES    FileBothDirectoryInformation    
79196    12:32:44 AM    Update.exe:992    CLOSE    C:\WINDOWS\system32\1037\    SUCCESS        
79197    12:32:44 AM    Update.exe:992    OPEN    C:\WINDOWS\system32\1041\    SUCCESS    Options: Open Directory  Access: All    
79198    12:32:44 AM    Update.exe:992    DIRECTORY    C:\WINDOWS\system32\1041\    NO SUCH FILE    FileBothDirectoryInformation: *.dmp


A few lines later, this occurs:
80626   12:32:51 AM     Update.exe:992    OPEN    C:\Program Files\    SUCCESS    Options: Open Directory  Access: All    
80626    12:32:51 AM    Update.exe:992    DIRECTORY    C:\Program Files\    NO SUCH FILE    FileBothDirectoryInformation: *.exe    
80627    12:32:51 AM    Update.exe:992    CLOSE    C:\Program Files\    SUCCESS        
80628    12:32:51 AM    Update.exe:992    OPEN    C:\Program Files\    SUCCESS    Options: Open Directory  Access: All    
80629    12:32:51 AM    Update.exe:992    DIRECTORY    C:\Program Files\    NO SUCH FILE    FileBothDirectoryInformation: *.exe    
80630    12:32:51 AM    Update.exe:992    CLOSE    C:\Program Files\    SUCCESS        
80631    12:32:51 AM    Update.exe:992    OPEN    C:\Program Files\    SUCCESS    Options: Open Directory  Access: All    
80632    12:32:51 AM    Update.exe:992    DIRECTORY    C:\Program Files\    NO SUCH FILE    FileBothDirectoryInformation: *.exe    
80633    12:32:51 AM    Update.exe:992    CLOSE    C:\Program Files\    SUCCESS        
80634    12:32:51 AM    Update.exe:992    OPEN    C:\Program Files\    SUCCESS    Options: Open Directory  Access: All    
80635    12:32:51 AM    Update.exe:992    DIRECTORY    C:\Program Files\    SUCCESS    FileBothDirectoryInformation: *    
80636    12:32:51 AM    Update.exe:992    DIRECTORY    C:\Program Files\    SUCCESS    FileBothDirectoryInformation    
80637    12:32:51 AM    Update.exe:992    DIRECTORY    C:\Program Files\    NO MORE FILES    FileBothDirectoryInformation    
80638    12:32:51 AM    Update.exe:992    CLOSE    C:\Program Files\    SUCCESS        
80639    12:32:51 AM    Update.exe:992    OPEN    C:\Program Files\    SUCCESS    Options: Open Directory  Access: All    
80640    12:32:51 AM    Update.exe:992    DIRECTORY    C:\Program Files\    NO SUCH FILE    FileBothDirectoryInformation: *.ppl    
80641    12:32:51 AM    Update.exe:992    CLOSE    C:\Program Files\    SUCCESS        
80642    12:32:51 AM    Update.exe:992    OPEN    C:\Program Files\    SUCCESS    Options: Open Directory  Access: All    
80643    12:32:51 AM    Update.exe:992    DIRECTORY    C:\Program Files\    NO SUCH FILE    FileBothDirectoryInformation: *.exe    
80644    12:32:51 AM    Update.exe:992    CLOSE    C:\Program Files\    SUCCESS        
80645    12:32:51 AM    Update.exe:992    OPEN    C:\Program Files\    SUCCESS    Options: Open Directory  Access: All    
80646    12:32:51 AM    Update.exe:992    DIRECTORY    C:\Program Files\    NO SUCH FILE    FileBothDirectoryInformation: *.exe    
80647    12:32:51 AM    Update.exe:992    CLOSE    C:\Program Files\    SUCCESS        
80648    12:32:51 AM    Update.exe:992    OPEN    C:\Program Files\    SUCCESS    Options: Open Directory  Access: All    
80649    12:32:51 AM    Update.exe:992    DIRECTORY    C:\Program Files\    NO SUCH FILE    FileBothDirectoryInformation: *.exe    
80650    12:32:51 AM    Update.exe:992    CLOSE    C:\Program Files\    SUCCESS        


It only occured in this small burst and only searched the one directory.  However, it occurred right after the last search for the *.dat files. However, none of the searches were directed to my mapped drives or shares.  They were only searching on the local hard drive.

If that wasn't exciting enough, I recorded lots of activity to my mapped drives.  Keep in mind that it did access them easily to put copies there on the initial infection.  Here are some excerpts:

Update.exe:992    OPEN    Z:\ [\192.168.6.130\c$]\    PATH NOT FOUND    Options: Open Directory  Access: All    
80560    12:32:49 AM    Update.exe:992    OPEN    Z:\    SUCCESS    Options: Open Directory  Access: 00000000    
80561    12:32:49 AM    Update.exe:992    CLOSE    Z:\    SUCCESS        
80562    12:32:49 AM    Update.exe:992    OPEN    Z:\ [\192.168.6.130\c$]\    PATH NOT FOUND    Options: Open Directory  Access: All    
80563    12:32:49 AM    Update.exe:992    OPEN    Z:\    SUCCESS    Options: Open Directory  Access: 00000000    

However, the only files that were destroyed were those on the local system.  None of the files on the shares or mapped drives were touched.  I'm not sure why at this point.  I have packet captures during this time from that correlate with access to those drives occuring, but no destruction.  In the search for files, I never saw any searches being conducted via shares and/or mapped drives.  It only occured on the local hard drive.

I again ran the same test from an infected XP box to a clean W2K and repeated the above process.  I still have registry keys being created and traffic to the shares/mapped drives, but no file modification happening.  The results were almost identical.  Remember the registry key above?  It was not pointed at the mapped drive on this test, but rather at the D:\ which is the CDROM.

At this point, I do not believe that the destructive payload will occur via shares and/or mapped drives.  Infected boxes however, will have all their files destroyed if they fall into one of the file types above.  As for the *.ppl and *.exe, I have no good explanation for at this time.  Good luck folks!