?Order? e-mails and how to block them
The guys behind the Haxdoor Trojan we wrote about two days ago (http://isc.sans.org/diary.php?storyid=1508) are not giving up easy. It looks like they are constantly spamming new downloader binaries, which are modified just enough to evade detection with current signatures and/or heuristics.
These downloaders are pretty small, usually only about 3kb, and are obfuscated a bit to make analysis more difficult. The latest downloader we've received comes in exactly the same message as those previous, notifying you about the order you've placed and it's summary in the attachment.
Once executed, the downloader tries to download a file from http:// 81.95.146.133 / [removed].exe. At the time of writing this diary the file was not available.
Anti virus vendors are slowly updating definitions and starting to detect this downloader properly.
While we're on the subject of malware being spammed, one of our readers, Rick, wrote earlier to ask as about a resource which specifies filetypes/file extensions that are assumed to be dangerous and should be blocked.
Microsoft has a nice list of unsafe extensions that we would definitely recommend to be blocked at the gateway. Microsoft Outlook actually automatically blocks these attachments, so if you block them at the gateway, it should *not* impact your users a lot. You can find the list at http://support.microsoft.com/default.aspx?scid=kb;EN-US;q262631.
One thing we have to stress out is that you can't rely on extensions ? sure, you should block these obviously unsafe ones, but don't rely on this. A lot of Unix/Linux mail programs can use the "file" utility, which is a much better choice in this case as it can detect what the file really is by examining the magic headers.
This is not a silver bullet as there ways for evading the detection by using utilities which don't rely on the magic bytes used by the "file" utility. Besides this, the "file" utility would have to be able to use the same "magic" (from the /etc/magic file) that Microsoft uses to determine which program will be used to open a file. Also, depending on the environment, there are cases when some file formats just have to be allowed (like Microsoft Word or Excel documents), which can carry other malware (just remember all 0-day vulnerabilities in Office applications that have been published lately).
This being said, blocking executables and other "unsafe" extensions and file types is still a good first line of defense.
Update (07/27/06): Today we saw another downloader being spammed, by the same group. It behaves completely same as the one detected yesterday, but it has been (again) modified to evade the AV detection. The md5sum is:
3a3a4fe61c9a0a511624cde88bcd2abe WC2905036.exe
It again tries to connect to the same web server as above, to download the second stage executable, which (luckily) wasn't there when we checked last time.
One of our readers, Simon, reminded us on white lists for extension/file type blocking. Indeed, if you can afford to implement white lists, they are the way to go - just block everything and allow only extensions/file types that you know are needed for your organizations.
These downloaders are pretty small, usually only about 3kb, and are obfuscated a bit to make analysis more difficult. The latest downloader we've received comes in exactly the same message as those previous, notifying you about the order you've placed and it's summary in the attachment.
Once executed, the downloader tries to download a file from http:// 81.95.146.133 / [removed].exe. At the time of writing this diary the file was not available.
Anti virus vendors are slowly updating definitions and starting to detect this downloader properly.
While we're on the subject of malware being spammed, one of our readers, Rick, wrote earlier to ask as about a resource which specifies filetypes/file extensions that are assumed to be dangerous and should be blocked.
Microsoft has a nice list of unsafe extensions that we would definitely recommend to be blocked at the gateway. Microsoft Outlook actually automatically blocks these attachments, so if you block them at the gateway, it should *not* impact your users a lot. You can find the list at http://support.microsoft.com/default.aspx?scid=kb;EN-US;q262631.
One thing we have to stress out is that you can't rely on extensions ? sure, you should block these obviously unsafe ones, but don't rely on this. A lot of Unix/Linux mail programs can use the "file" utility, which is a much better choice in this case as it can detect what the file really is by examining the magic headers.
This is not a silver bullet as there ways for evading the detection by using utilities which don't rely on the magic bytes used by the "file" utility. Besides this, the "file" utility would have to be able to use the same "magic" (from the /etc/magic file) that Microsoft uses to determine which program will be used to open a file. Also, depending on the environment, there are cases when some file formats just have to be allowed (like Microsoft Word or Excel documents), which can carry other malware (just remember all 0-day vulnerabilities in Office applications that have been published lately).
This being said, blocking executables and other "unsafe" extensions and file types is still a good first line of defense.
Update (07/27/06): Today we saw another downloader being spammed, by the same group. It behaves completely same as the one detected yesterday, but it has been (again) modified to evade the AV detection. The md5sum is:
3a3a4fe61c9a0a511624cde88bcd2abe WC2905036.exe
It again tries to connect to the same web server as above, to download the second stage executable, which (luckily) wasn't there when we checked last time.
One of our readers, Simon, reminded us on white lists for extension/file type blocking. Indeed, if you can afford to implement white lists, they are the way to go - just block everything and allow only extensions/file types that you know are needed for your organizations.
Keywords:
0 comment(s)
My next class:
Web App Penetration Testing and Ethical Hacking | Amsterdam | Mar 31st - Apr 5th 2025 |
×
Diary Archives
Comments