Threat Level: green Handler on Duty: Rob VandenBrink

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2006-02-02 InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Preparing for Feb 3rd(CME-24)

Published: 2006-02-02
Last Updated: 2006-02-03 12:49:58 UTC
by Pedro Bueno (Version: 1)
0 comment(s)
Preparing for Feb 3rd(CME-24)

We received a lot of suggestions about measures against CME-24. In other words,
how to prepare for Feb 3rd, in despite of the Anti-virus.

What follows bellow is a compiled list of those. Some were tested, but some not.


Javier Romero sent a link to a Spanish Article regarding CME-24 detection:
"Cómo detectar el virus CME-24 Kamasutra /Nyxgen / MyWife / Blackworm antes del 3 febrero"

- The rule bellow, made by Per Kristian Johnsen with Telenor Security Center,
is said to detect attempts to copy WINZIP_TMP.exe to shares. According to the author,
they are being able to detect infected machines where the already published
snort/sourcefire rule couldn't:

alert tcp any any -> any 135:139 (msg:"Nyxem attempting to copy WINZIP_TMP.exe to shares"; flow:to_server,established; content:"|57 00 49 00 4e 00 5a 00 49 00 50 00 5f 00 54 00 4d 00 50 00 2e 00 65 00 78 00 65|"; reference:url,; classtype:trojan-activity; sid:5000173; rev:1;)

- We had another user that used sms to scan drives files with a size of 95,690 named

%System%\New WinZip File.exe
Zipped Files.exe

- A security Dweeb at a large California municipal government agency wrote a batch script that:

"1) looks for the infected file names existence
on %windir% and %sysdir% using simple DIR /B commands. Output is sent to
uniquely named text file (with a non-standard extension). Infected
workstations will show a non-zero file size. Batch file is below; uses
environment vars that are unique to user and computer name.
2) The batch file will be placed in the login script for all
3) Ensure that verified backups are completed tonight (Wed).

Batch file:
@echo off
dir /b %WinDir%\system\\Winzip.exe >> %username%_%computername%.rgh
dir  /b %WinDir%\system\Update.exe  >> %username%_%computername%.rgh
dir /b  %WinDir%\system\scanregw.exe  >> %username%_%computername%.rgh
dir  /b %WinDir%\Rundll16.exe  >> %username%_%computername%.rgh
dir  /b %WinDir%\winzip_tmp.exe  >> %username%_%computername%.rgh
dir  /b c:\winzip_tmp.exe  >> %username%_%computername%.rgh
dir  /b %Temp%\                                        .exe  >>

Although dangerous, we think we have a very low chance of a problem.
According to LURQ, there are only 15K computers in US that have
contacted the "counter" site. And we have other protections in place
(blocking of all executables in mail attachments, current anti-virus
updates, etc.)"

Update: Another user suggested quotes in the script above, as showed bellow:
dir  /b "%Temp%\                                        .exe"  >>

Handler on Duty: Pedro Bueno ( pbueno //&&// isc. sans. org )
0 comment(s)

Mozilla Firefox vulnerabilities and upgrade

Published: 2006-02-03
Last Updated: 2006-02-03 20:42:57 UTC
by Swa Frantzen (Version: 2)
0 comment(s)
According to secunia's security advisory, several vulnerabilities were found in Firefox. Fortunately, Mozilla released Firefox to fix them.

See the release notes and the list of security fixes.

If you still use FireFox 1.0.7, please note it is vulnerable to some of the problems as well. I'm expecting a 1.0.8 to be released but since it's taking it's time it might be easier to take the step to the 1.5 series.
Swa Frantzen

0 comment(s)

CME-24 Analysis: The destruction does not appear to spread across Windows network shares

Published: 2006-02-02
Last Updated: 2006-02-02 17:39:40 UTC
by Lorna Hutcheson (Version: 1)
0 comment(s)
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: [\\\c$]\"
\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:  


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:\ [\\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:\ [\\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!

0 comment(s)

It is already Feb 3rd!

Published: 2006-02-03
Last Updated: 2006-02-03 13:00:46 UTC
by Pedro Bueno (Version: 2)
0 comment(s)
Ok, in some parts of the world it is already Feb 3rd and some damage is already probably done.
If you know any story related to this event, please share with us .

Samir Datt wrote to tell us about "unconfirmed reports" of damage in Bangalore, Ludhiana and Delhi. (email arrived 1am EST, 6am GMT).

0 comment(s)
Diary Archives