You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "Chip M." <sa...@IowaHoneypot.com> on 2016/04/21 15:33:01 UTC
malware campaign: javascript in ".tgz"
Starting about two hours ago, about 40% of my real-time
honeypot spam is a new malware campaign. About a third are
hitting "BAYES_00", with about 10% of all having negative SA
scores. :(
Full spample (with munged email addresses):
http://puffin.net/software/spam/samples/0040_mal_tgz.txt
That's not a valuable honeypot address, so I've left everything
else as-is, including the Message-ID.
So far, all of these have the _EXACT_ same Message-ID, From,
and Reply-To. I expect all to change, but they may be useful
for quick block rules. The From account is "FSPRD" and the
>From base domain is "covance".
The filenames are all the same length, pure numeric with three
leading zeroes. Here's a few examples:
0006449538.tgz
0007184777.tgz
0008205464.tgz
0007565676.tgz
0008113861.tgz
0001457696.tgz
0007535057.tgz
0008403752.tgz
0009470013.tgz
I'm blocking these by file extension (both ".tgz" and ".gz" to
be extra cautious).
A couple of years ago, I added a "mime prefix" rule to my post-SA
filter, and have added rules using that, in case the spammers try
the old trick of asking victims to rename the file.
I tried opening a benign ".gz" in Windows7, and it didn't
recognize it, but other versions may. These may be targeting
other platforms (e.g. I recently learned that Chrome OS has native
support for "rar" extraction, which may explain the recent rise of
rar javascript email malware).
I've only taken a quick look at the payload. It's javascript, but
definitely different from past campaigns.
I've been seeing a high level of "calibration" spam for over a
week, so I suspect this is a new botnet going live. :(
- "Chip"
Re: malware campaign: javascript in ".tgz"
Posted by Dianne Skoll <df...@roaringpenguin.com>.
Hi,
Yes, we are seeing tons of these. We look inside various archive files for
filenames and we quarantine .js files by default, so we didn't suffer any
0-day problems, and now I see that Sanesecurity is picking most of these up.
Regards,
Dianne.
Re: malware campaign: javascript in ".tgz"
Posted by Alex <my...@gmail.com>.
Hi Chip,
On Thu, Apr 21, 2016 at 9:33 AM, Chip M. <sa...@iowahoneypot.com> wrote:
> Starting about two hours ago, about 40% of my real-time
> honeypot spam is a new malware campaign. About a third are
> hitting "BAYES_00", with about 10% of all having negative SA
> scores. :(
>
> Full spample (with munged email addresses):
> http://puffin.net/software/spam/samples/0040_mal_tgz.txt
> That's not a valuable honeypot address, so I've left everything
> else as-is, including the Message-ID.
>
> So far, all of these have the _EXACT_ same Message-ID, From,
> and Reply-To. I expect all to change, but they may be useful
> for quick block rules. The From account is "FSPRD" and the
> From base domain is "covance".
>
> The filenames are all the same length, pure numeric with three
> leading zeroes. Here's a few examples:
> 0006449538.tgz
> 0007184777.tgz
> 0008205464.tgz
> 0007565676.tgz
> 0008113861.tgz
> 0001457696.tgz
> 0007535057.tgz
> 0008403752.tgz
> 0009470013.tgz
>
>
> I'm blocking these by file extension (both ".tgz" and ".gz" to
> be extra cautious).
> A couple of years ago, I added a "mime prefix" rule to my post-SA
> filter, and have added rules using that, in case the spammers try
> the old trick of asking victims to rename the file.
>
> I tried opening a benign ".gz" in Windows7, and it didn't
> recognize it, but other versions may. These may be targeting
> other platforms (e.g. I recently learned that Chrome OS has native
> support for "rar" extraction, which may explain the recent rise of
> rar javascript email malware).
>
> I've only taken a quick look at the payload. It's javascript, but
> definitely different from past campaigns.
>
> I've been seeing a high level of "calibration" spam for over a
> week, so I suspect this is a new botnet going live. :(
> - "Chip"
Thanks so much for posting this. Looks like we've received a handful
of these as well. Thankfully, all of which were blocked:
X-Amavis-Alert: INFECTED, message contains virus:
Sanesecurity.Malware.26070.JsHeur.UNOFFICIAL
You may also want to block on subject:
Subject: Dispatched Purchase Order
Regards,
Alex
>
Re: malware campaign: javascript in ".tgz"
Posted by Reindl Harald <h....@thelounge.net>.
Am 21.04.2016 um 18:30 schrieb Dave Funk:
> On Thu, 21 Apr 2016, Reindl Harald wrote:
>>
> [snip..]
>>> Content-Type: application/octet-stream; name="0005500922.tgz"
>>>
>>> I wonder how common octet-stream is with legitimate .tgz
>>> files
>>
>> sadly you need to expect "application/octet-stream" for nearly any
>> filetype, learned the hard way by doing mime-checks on webservers
>
> +1 for this, similar experience here.
>
> I've seen "application/octet-stream" typing on ".htm" components of mail
> messages created by major brand e-mail clients. The lazy authors assume
> that the correct file extension is all that is needed
nope - above i talked about "file" and the php mimtype-functions, so not
only lazy auhors fo clients, get the correct mimetype explains why
things are called "mime-magic" - it's more magic than predictable
Re: malware campaign: javascript in ".tgz"
Posted by Dave Funk <db...@engineering.uiowa.edu>.
On Thu, 21 Apr 2016, Reindl Harald wrote:
>
>
[snip..]
>> Content-Type: application/octet-stream; name="0005500922.tgz"
>>
>> I wonder how common octet-stream is with legitimate .tgz
>> files
>
> sadly you need to expect "application/octet-stream" for nearly any filetype,
> learned the hard way by doing mime-checks on webservers
+1 for this, similar experience here.
I've seen "application/octet-stream" typing on ".htm" components of mail
messages created by major brand e-mail clients. The lazy authors assume
that the correct file extension is all that is needed.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: malware campaign: javascript in ".tgz"
Posted by Reindl Harald <h....@thelounge.net>.
Am 21.04.2016 um 17:07 schrieb RW:
> On Thu, 21 Apr 2016 08:33:01 -0500
> Chip M. wrote:
>
>> Starting about two hours ago, about 40% of my real-time
>> honeypot spam is a new malware campaign. About a third are
>> hitting "BAYES_00", with about 10% of all having negative SA
>> scores. :(
>>
>> Full spample (with munged email addresses):
>> http://puffin.net/software/spam/samples/0040_mal_tgz.txt
>
>
> Content-Type: application/octet-stream; name="0005500922.tgz"
>
> I wonder how common octet-stream is with legitimate .tgz
> files
sadly you need to expect "application/octet-stream" for nearly any
filetype, learned the hard way by doing mime-checks on webservers
Re: malware campaign: javascript in ".tgz"
Posted by Martin Gregorie <ma...@gregorie.org>.
On Thu, 2016-04-21 at 16:07 +0100, RW wrote:
> On Thu, 21 Apr 2016 08:33:01 -0500
> Chip M. wrote:
>
> >
> > Starting about two hours ago, about 40% of my real-time
> > honeypot spam is a new malware campaign. About a third are
> > hitting "BAYES_00", with about 10% of all having negative SA
> > scores. :(
> >
> > Full spample (with munged email addresses):
> > http://puffin.net/software/spam/samples/0040_mal_tgz.txt
>
> Content-Type: application/octet-stream; name="0005500922.tgz"
>
> I wonder how common octet-stream is with legitimate .tgz
> files.
I'd say its not very common at all when included in a commercial e-mail
as an attached invoice, purchase order or similar document. I've never
seen one, but then again my mail volume is relatively low. In fact I
don't think I've ever seen a legitimate .tgz or .gz file that
originated outside the Linux/UNIX development environment.
As such, it should be quite safe to reject if it is detected by a
suitable meta-rule.
Martin
Re: malware campaign: javascript in ".tgz"
Posted by RW <rw...@googlemail.com>.
On Thu, 21 Apr 2016 08:33:01 -0500
Chip M. wrote:
> Starting about two hours ago, about 40% of my real-time
> honeypot spam is a new malware campaign. About a third are
> hitting "BAYES_00", with about 10% of all having negative SA
> scores. :(
>
> Full spample (with munged email addresses):
> http://puffin.net/software/spam/samples/0040_mal_tgz.txt
Content-Type: application/octet-stream; name="0005500922.tgz"
I wonder how common octet-stream is with legitimate .tgz
files.
Re: malware campaign: javascript in ".tgz"
Posted by Kevin Golding <kp...@caomhin.org>.
On Thu, 21 Apr 2016 14:33:01 +0100, Chip M. <sa...@iowahoneypot.com>
wrote:
> Starting about two hours ago, about 40% of my real-time
> honeypot spam is a new malware campaign. About a third are
> hitting "BAYES_00", with about 10% of all having negative SA
> scores. :(
I've just checked 4 that score between 10.1 and 14.9 (I don't see any
others.)
One had BAYES_80 and the rest were all BAYES_999 (having learnt the first
one). Just glancing at the messages I'd assume the 80 came from being so
similar to the frequent "invoice attached" type spams that have been
coming through for a while.
They all hit RDNS_NONE and DCC_CHECK too. TxRep seems to be adding a
couple of points each time too (scoring based on the email address).
The remaining points come from a variety of RBLs and some local rules I
use. While you're hitting BAYES_00 you'll be facing an uphill battle
though. I'd suggest feeding that some samples to at least try and negate
that issue. They seem to be fairly distinctive in the eyes of my bayes.