There's yet another variant in the ongoing campaign of HTML file
attachments with javascript malware payloads. :(
The trick is that it sets the Content-Type to "application/zip",
and uses an ".htm" file extension, for example (actual spam):
Content-Type: application/zip
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Wire_ID88283.htm"
This time, it WORKS as the spammer intends, with at least one
email client (see P.S.).
The payload looks like it's part of Blackhole (pretty much the same
code as was blasted out last week).
Full sample (with mildly/obviously redacted email addresses):
http://puffin.net/software/spam/samples/0012_malware_zip_fake.txt
The vast majority of my samples claim to be from popular phish
targets, including: UPS, LinkedIn, Craigslist.
Note that none of these is hitting test "T_HTML_ATTACH".
The SpamAssassin scores have ranged from 0.0 thru 3.0 - yes,
100% are sailing thru. (They're all being killed by the anti-zip
tests in my post-SA cleanup filter.)
Normally, I'd do a corpora check, to see whether there are any
legitimate instances of this ContentType file extension mismatch,
but in this instance, even if it did occur in Ham, it's so
phenomally STUPID, that I consider it a waste to allow for it.
Some ham was born to die. :\
That opens up the broader issue of mismatches between CTs and
extensions. The most common legit type I've seen are images,
almost always in niche newsletters, which usually have enough
other, um, "eccentricities" that they should only be mildly dinged.
When I get some time, I will write some code to analyze my corpora,
and post a detailed list of what mismatches I'm seeing in ham, in
the wild.
For now, I think it would be a good idea to heavily ding
all mismatches involving HTML file attachments. They have too much
potential for harm, and many SA users are small domains without
subject matter expertise (which is exactly how I came to use this
fantastic tool!), and with minimal to no other defensive layers.
Let's give the little guy/gal some help. :)
- "Chip"
P.S. I tested this by manually removing the base64 encoded payload,
substituting in the base64 portion of a non-attachment HTML part
from a ham, then reinjecting the raw file into my queue.
Eudora 7.1.0.9 translated it to an HTML file, and was able to open
it without any difficulty (it did show a generic warning dialog).
I'll be repeating that with a friend who uses MS clients.
I might put that defanged test case online if anybody would like to
use it to test less mainstream clients.
I used the same basic methodology to test a more elaborate "trick"
spotted two weeks ago. The file attachment of that variant was
correctly dropped by both Eudora and a couple of MS clients.
Thanks to list members who have kindly taken the time to test some
of my previous samples! :)
