Preparing for Feb 3rd(CME-24)
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.
Update:
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,www.lurhq.com/blackworm.html; 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
%Windir%\Rundll16.exe
%System%\scanregw.exe
%System%\Winzip.exe
%System%\Update.exe
%System%\WINZIP_TMP.EXE
%System%\SAMPLE.ZIP
%System%\New WinZip File.exe
movies.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
computers.
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%\word.zip .exe >>
%username%_%computername%.rgh
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%\word.zip .exe" >>
%username%_%computername%.rgh
-----------------------------------------------------------------
Handler on Duty: Pedro Bueno ( pbueno //&&// isc. sans. org )
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.
Update:
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,www.lurhq.com/blackworm.html; 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
%Windir%\Rundll16.exe
%System%\scanregw.exe
%System%\Winzip.exe
%System%\Update.exe
%System%\WINZIP_TMP.EXE
%System%\SAMPLE.ZIP
%System%\New WinZip File.exe
movies.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
computers.
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%\word.zip .exe >>
%username%_%computername%.rgh
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%\word.zip .exe" >>
%username%_%computername%.rgh
-----------------------------------------------------------------
Handler on Duty: Pedro Bueno ( pbueno //&&// isc. sans. org )
Keywords:
0 comment(s)
Mozilla Firefox vulnerabilities and upgrade
According to secunia's security advisory, several vulnerabilities were found in Firefox. Fortunately, Mozilla released Firefox 1.5.0.1 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
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
Keywords:
0 comment(s)
CME-24 Analysis: The destruction does not appear to spread across Windows network shares
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!
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
*.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!
Keywords:
0 comment(s)
It is already Feb 3rd!
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).
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).
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments