Re: Better phish detection
On 3/18/2012 8:16 PM, sporkman wrote: Joseph Brennan wrote: Imagine one of your users sending mail to a list that another of your users subscribes to. I can't quite see the case there. My rule specifically matches a mismatch between the envelope-from and From: only when the From: purports to be one our staff/role accounts. I had it in testing for the last few days with a low score and it's doing pretty well. Well consider your email (the one to which I'm replying): Return-path: From: sporkman That would be a FROM header that mentions one of your staff accounts (assuming you're using such a qualifying account now. If not, use a bit of imagination) with a completely different MAIL command. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren
Re: Better phish detection
Joseph Brennan wrote: > > > > --On Thursday, March 15, 2012 19:21 -0700 sporkman wrote: > >> -envelope-from is not from our domain, From: line in the message is, >> being >> able to clobber that pattern would be quite helpful by itself. > > > Imagine one of your users sending mail to a list that another of your > users subscribes to. > I can't quite see the case there. My rule specifically matches a mismatch between the envelope-from and From: only when the From: purports to be one our staff/role accounts. I had it in testing for the last few days with a low score and it's doing pretty well. Always open to more ideas though... Charles -- View this message in context: http://old.nabble.com/Better-phish-detection-tp33478328p33529003.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Better phish detection
On 3/16/2012 1:11 PM, Joseph Brennan wrote: --On Thursday, March 15, 2012 19:21 -0700 sporkman wrote: -envelope-from is not from our domain, From: line in the message is, being able to clobber that pattern would be quite helpful by itself. Imagine one of your users sending mail to a list that another of your users subscribes to. This can largely be negated by skipping this test if there are any typical List-headers (List-ID, List-Unsubscribe, Mailing-List, etc)
Re: Better phish detection
sporkman wrote: -I'm not going to go into details, but the messages quite often have a from or envelope-from that we simply don't use when sending email to customers or replying to them. In fact, all of these samples have that wrong. Just reject that. No chance of false positives. No META needed. Joseph Brennan Lead Email Systems Engineer Columbia University Information Technology
Re: Better phish detection
--On Thursday, March 15, 2012 19:21 -0700 sporkman wrote: -envelope-from is not from our domain, From: line in the message is, being able to clobber that pattern would be quite helpful by itself. Imagine one of your users sending mail to a list that another of your users subscribes to. Joseph Brennan Lead Email Systems Engineer Columbia University Information Technology
Re: Better phish detection
Ned Slider wrote:
>
> On 16/03/12 02:21, sporkman wrote:
>>
>>
>>
>> Ned Slider wrote:
>>>
>>> On 12/03/12 17:02, David B Funk wrote:
On Mon, 12 Mar 2012, Paul Russell wrote:
> On 3/10/2012 16:43, Ned Slider wrote:
>>
>> This one is easy enough - if the latter is the only valid url that
>> should ever appear in an email, create a meta rule that looks for a
>> url containing bway.net (or even just bway or webmail or login etc),
>> but isn't https://webmail.bway.net/.
>>
>> Create meta rules for the common words you have identified. Link
>> these with a rule such as __HAS_ANY_URI or some of your webmail based
>> URI rules above.
>>
>> What other rules commonly hit - are they sent from freemail accounts?
>> Do they hit any DNSBL's?
>
> It's not that simple. If it were, the problem would not have been
> ongoing for at least 4 years.
Technically what Ned said is correct "This one is easy enough".
Yes THIS ONE (emphasis mine) is easy enough, but for some of us these
kind of spear-phishing attacks are an ever mutating problem and some
are damned clever.
>>>
>>> Exactly, if you only provide one snippet of an example you don't give us
>>> much to work with so the best we can do is suggest a rule that will
>>> catch that one very narrow example :-/
>>>
>>> Give us a tarball of (preferably unredacted) examples to work with - you
>>> must have hundreds collected over the last 4 years.
>>>
>>>
>>
>> Here's a collection from our support folks:
>>
>> http://home.bway.net/spork/phish/
>>
>> Some patterns of interest (including some of the excellent suggestions
>> upthread):
>>
>> -envelope-from is not from our domain, From: line in the message is,
>> being
>> able to clobber that pattern would be quite helpful by itself.
>> -I'm not going to go into details, but the messages quite often have a
>> from
>> or envelope-from that we simply don't use when sending email to customers
>> or
>> replying to them. In fact, all of these samples have that wrong.
>> -Most the messages contain a URL that includes our domain in it after the
>> host part of the URL. The ones that don't still include "bway" somewhere
>> in
>> the URL.
>>
>> If I could slap together a rule that detects those three anomalies
>> together,
>> I'd be pretty happy.
>
> Good - you have something to work with now.
>
> Here's a rule that will catch bway.net after the host part of the URL:
>
> uri LOCAL_URI_BWAY_NET m{https?://[^/]+/.{0,40}bway\.net}
> describe LOCAL_URI_BWAY_NET URL contains bway.net in the path
> score LOCAL_URI_BWAY_NET 1
>
> And many of your examples link to bway.htm so lets catch those too:
>
> uri LOCAL_URI_BWAY_HTM m{bway\.html?$}
> describe LOCAL_URI_BWAY_HTM Contains link to bway.htm
> score LOCAL_URI_BWAY_HTM 1
>
> Then I'd create some rules to make meta rules from. For example, not
> from our domain + has URI + URI contains "bway".
>
> Generally, the more rules you can create the better. Lots of small
> scoring rules will invariably outperform a few high scoring rules unless
> you are able to identify that one killer feature that identifies it as a
> phish to you.
>
It's probably been at least a few years since I made any custom rules, so
I'm a bit rusty, but here's a few things I'm trying out with a low score to
see how they work.
This one compares the envelope from to "From:" and if they don't agree,
there's a match:
header __ENV_FROM_TEST EnvelopeFrom !~ /\@bway.net/i
header __FROM_TEST From =~
/support|webmail|helpdesk|tech|info|sales|antispam\@bway.net/i
meta BWAY_PHISH_FROM (__ENV_FROM_TEST && __FROM_TEST)
describe BWAY_PHISH_FROM Mismatched From: and envelope-from
score BWAY_PHISH_MISMATCH_FROM 1.0
This one looks for our hostname in the URI, and if it's not there, but some
variation of our domain shows up in the rest of the URI, it matches:
uri_detail BWAY_PHISH_LINKS domain !~
/bway.net|www.bway.net|webmail.bway.net/ raw =~
/bway.htm|bway.html|webmail.bway.net/
describe BWAY_PHISH_LINKS Strange links that pretend to be webmail
score BWAY_PHISH_LINKS 1.0
I'm also toying with the idea of some meta rules that takes each of those
and also does a body check for the most common words (ie: "account",
"update", "deactivated", etc.) and bumps the score up further.
I'd never seen "uri_detail" before, but it seems pretty handy:
http://spamassassin.apache.org/full/3.3.x/doc/Mail_SpamAssassin_Plugin_URIDetail.html
--
View this message in context:
http://old.nabble.com/Better-phish-detection-tp33478328p33516999.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
RE: Better phish detection
-Original Message- From: David F. Skoll [mailto:d...@roaringpenguin.com] Sent: Monday, March 12, 2012 12:49 PM To: users@spamassassin.apache.org Subject: Re: Better phish detection Hi, I've been following this thread... not sure how many of you are aware of this project: http://code.google.com/p/anti-phishing-email-reply/ We use the phishing address list and it does catch a few things. We don't yet use the phishing URL list, but it looks like it might help. Naturally, this list is reactive, but if enough people used it and contributed to it, the results might be pretty good. Regards, David. --- We use it here; I've got a little python script that parses out recent entries from that project and builds a simple postfix static map to block mail attempts to them. I'm happy to share if anyone's interested. - Aaron Bennett Manager, Systems Administration Clark University ITS
Re: Better phish detection
On 16/03/12 02:21, sporkman wrote:
Ned Slider wrote:
On 12/03/12 17:02, David B Funk wrote:
On Mon, 12 Mar 2012, Paul Russell wrote:
On 3/10/2012 16:43, Ned Slider wrote:
This one is easy enough - if the latter is the only valid url that
should ever appear in an email, create a meta rule that looks for a
url containing bway.net (or even just bway or webmail or login etc),
but isn't https://webmail.bway.net/.
Create meta rules for the common words you have identified. Link
these with a rule such as __HAS_ANY_URI or some of your webmail based
URI rules above.
What other rules commonly hit - are they sent from freemail accounts?
Do they hit any DNSBL's?
It's not that simple. If it were, the problem would not have been
ongoing for at least 4 years.
Technically what Ned said is correct "This one is easy enough".
Yes THIS ONE (emphasis mine) is easy enough, but for some of us these
kind of spear-phishing attacks are an ever mutating problem and some
are damned clever.
Exactly, if you only provide one snippet of an example you don't give us
much to work with so the best we can do is suggest a rule that will
catch that one very narrow example :-/
Give us a tarball of (preferably unredacted) examples to work with - you
must have hundreds collected over the last 4 years.
Here's a collection from our support folks:
http://home.bway.net/spork/phish/
Some patterns of interest (including some of the excellent suggestions
upthread):
-envelope-from is not from our domain, From: line in the message is, being
able to clobber that pattern would be quite helpful by itself.
-I'm not going to go into details, but the messages quite often have a from
or envelope-from that we simply don't use when sending email to customers or
replying to them. In fact, all of these samples have that wrong.
-Most the messages contain a URL that includes our domain in it after the
host part of the URL. The ones that don't still include "bway" somewhere in
the URL.
If I could slap together a rule that detects those three anomalies together,
I'd be pretty happy.
Good - you have something to work with now.
Here's a rule that will catch bway.net after the host part of the URL:
uri LOCAL_URI_BWAY_NET m{https?://[^/]+/.{0,40}bway\.net}
describeLOCAL_URI_BWAY_NET URL contains bway.net in the path
score LOCAL_URI_BWAY_NET 1
And many of your examples link to bway.htm so lets catch those too:
uri LOCAL_URI_BWAY_HTM m{bway\.html?$}
describeLOCAL_URI_BWAY_HTM Contains link to bway.htm
score LOCAL_URI_BWAY_HTM 1
Then I'd create some rules to make meta rules from. For example, not
from our domain + has URI + URI contains "bway".
Generally, the more rules you can create the better. Lots of small
scoring rules will invariably outperform a few high scoring rules unless
you are able to identify that one killer feature that identifies it as a
phish to you.
Re: Better phish detection
>Here's a collection from our support folks: > http://home.bway.net/spork/phish/ Hi, I've added a few sigs to junk.ndb and phish.ndb which might help a little, if you are using ClamAV and Third-Party signatures. Cheers, Steve Sanesecurity.co.uk -- View this message in context: http://old.nabble.com/Better-phish-detection-tp33478328p33516249.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Better phish detection
Ned Slider wrote: > > On 12/03/12 17:02, David B Funk wrote: >> On Mon, 12 Mar 2012, Paul Russell wrote: >> >>> On 3/10/2012 16:43, Ned Slider wrote: This one is easy enough - if the latter is the only valid url that should ever appear in an email, create a meta rule that looks for a url containing bway.net (or even just bway or webmail or login etc), but isn't https://webmail.bway.net/. Create meta rules for the common words you have identified. Link these with a rule such as __HAS_ANY_URI or some of your webmail based URI rules above. What other rules commonly hit - are they sent from freemail accounts? Do they hit any DNSBL's? >>> >>> It's not that simple. If it were, the problem would not have been >>> ongoing for at least 4 years. >> >> Technically what Ned said is correct "This one is easy enough". >> Yes THIS ONE (emphasis mine) is easy enough, but for some of us these >> kind of spear-phishing attacks are an ever mutating problem and some >> are damned clever. >> > > Exactly, if you only provide one snippet of an example you don't give us > much to work with so the best we can do is suggest a rule that will > catch that one very narrow example :-/ > > Give us a tarball of (preferably unredacted) examples to work with - you > must have hundreds collected over the last 4 years. > > Here's a collection from our support folks: http://home.bway.net/spork/phish/ Some patterns of interest (including some of the excellent suggestions upthread): -envelope-from is not from our domain, From: line in the message is, being able to clobber that pattern would be quite helpful by itself. -I'm not going to go into details, but the messages quite often have a from or envelope-from that we simply don't use when sending email to customers or replying to them. In fact, all of these samples have that wrong. -Most the messages contain a URL that includes our domain in it after the host part of the URL. The ones that don't still include "bway" somewhere in the URL. If I could slap together a rule that detects those three anomalies together, I'd be pretty happy. -- View this message in context: http://old.nabble.com/Better-phish-detection-tp33478328p33514647.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Better phish detection
On 12/03/12 17:02, David B Funk wrote: On Mon, 12 Mar 2012, Paul Russell wrote: On 3/10/2012 16:43, Ned Slider wrote: This one is easy enough - if the latter is the only valid url that should ever appear in an email, create a meta rule that looks for a url containing bway.net (or even just bway or webmail or login etc), but isn't https://webmail.bway.net/. Create meta rules for the common words you have identified. Link these with a rule such as __HAS_ANY_URI or some of your webmail based URI rules above. What other rules commonly hit - are they sent from freemail accounts? Do they hit any DNSBL's? It's not that simple. If it were, the problem would not have been ongoing for at least 4 years. Technically what Ned said is correct "This one is easy enough". Yes THIS ONE (emphasis mine) is easy enough, but for some of us these kind of spear-phishing attacks are an ever mutating problem and some are damned clever. Exactly, if you only provide one snippet of an example you don't give us much to work with so the best we can do is suggest a rule that will catch that one very narrow example :-/ Give us a tarball of (preferably unredacted) examples to work with - you must have hundreds collected over the last 4 years.
Email addresses in a DNSBL (was Re: Better phish detection)
On Mon, 12 Mar 2012 14:47:41 -0500 (CDT) David B Funk wrote: > This concept was discussed/debated on this list about 2 years ago (~ > Apr 2009; search for the subject of "emailBL"). > There was some disagreement about how to handle the '@' within > the context of a DNS record and about privacy/security issues. In the case of APER, the entire list is publicly downloadable, so I don't think making it available via DNS introduces any additional privacy issues. Handling '@' within a DNS record is a solved problem (see the SOA record). You just replace it with a '.' If we were worried about the (extremely unlikely) clash between "b...@sub.example.org" and "bob@example.org", we could just use the sha1sum of the lower-cased email address as the DNS lookup key. Regards, David.
Re: Better phish detection
On Mon, 12 Mar 2012, Simon Loewenthal wrote:
Paul Russell wrote:
The list was originally started by a group of email administrators in
higher education who
were attempting to deal with an epidemic of compromised accounts that
were being exploited
to send password phishing spam, mostly to addresses at other colleges
and universities. At
that point in time, it was easier to filter by sender address or
reply-to address than
content. Over time, the phishers seem to have expanded the target
demographic to include
everyone everywhere.
The list could be accessed by DNS and used as an rbl.
This concept was discussed/debated on this list about 2 years ago (~ Apr
2009; search for the subject of "emailBL").
There was some disagreement about how to handle the '@' within
the context of a DNS record and about privacy/security issues.
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: Better phish detection
Paul Russell wrote: >On 3/12/2012 12:58, Simon Loewenthal wrote: >> >> At first glance: >> This is private black list of email assesses maintened by many. Free >to use, but it'll turn into a huge file for a server to parse. >> >> Eventually we moved from hosts files to DNS :) >> >> I should rather block content not email addresses. > >The list was originally started by a group of email administrators in >higher education who >were attempting to deal with an epidemic of compromised accounts that >were being exploited >to send password phishing spam, mostly to addresses at other colleges >and universities. At >that point in time, it was easier to filter by sender address or >reply-to address than >content. Over time, the phishers seem to have expanded the target >demographic to include >everyone everywhere. The list could be accessed by DNS and used as an rbl. -- Dogs are tough. I've been interrogating this one for hours and he still won't tell me who's a good boy. simon@klunky / .co.uk / .org
Re: Better phish detection
I have some statistics about the Anti-Phishing Email Reply project. Our quarantine currently has 1,906,179 messages of which 4022 were caught because of addresses on APER. All 4022 look like spam or phishing attempts. So even though APER caught only about 0.21% of our quarantined messages, the ones it did catch are potentially very nasty. (And of the 4022 on APER, 221 of them would have scored below the spam threshold were it not for APER.) Regards, David.
Re: Better phish detection
On 3/12/2012 12:58, Simon Loewenthal wrote: At first glance: This is private black list of email assesses maintened by many. Free to use, but it'll turn into a huge file for a server to parse. Eventually we moved from hosts files to DNS :) I should rather block content not email addresses. The list was originally started by a group of email administrators in higher education who were attempting to deal with an epidemic of compromised accounts that were being exploited to send password phishing spam, mostly to addresses at other colleges and universities. At that point in time, it was easier to filter by sender address or reply-to address than content. Over time, the phishers seem to have expanded the target demographic to include everyone everywhere. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame
Re: Better phish detection
On Mon, 12 Mar 2012 13:05:24 -0400 Paul Russell wrote: > Most of the phishing spam we see seems to come from > apparently-compromised accounts, so we seldom see the same sender > address for more than a few hours, or a few days, at most. Right... the list is reactive. I find it usually takes anywhere from an hour to a few hours for a compromised address to get on the list, so there is some value if the address is used for more than a few hours. Also, there's a lot of value in finding out that one of *your* users has been compromised. :) I see a couple of nd.edu addresses in the list, though the last-seen dates are old (Aug and October 2011.) > Phishing reply-to addresses and phishing URL's change less frequently. > There are several variants of phishing message text, and new variants > are introduced from time to time, but the message body seems to be > the most reliable source of filter fodder. I agree. The APER project is just one more tool in the toolbox. Regards, David.
Re: Better phish detection
On 3/12/2012 12:49, David F. Skoll wrote: Hi, I've been following this thread... not sure how many of you are aware of this project: http://code.google.com/p/anti-phishing-email-reply/ We use the phishing address list and it does catch a few things. We don't yet use the phishing URL list, but it looks like it might help. Naturally, this list is reactive, but if enough people used it and contributed to it, the results might be pretty good. Regards, David. Most of the phishing spam we see seems to come from apparently-compromised accounts, so we seldom see the same sender address for more than a few hours, or a few days, at most. Phishing reply-to addresses and phishing URL's change less frequently. There are several variants of phishing message text, and new variants are introduced from time to time, but the message body seems to be the most reliable source of filter fodder. YMMV, of course. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame
Re: Better phish detection
On Mon, 12 Mar 2012 17:58:22 +0100 Simon Loewenthal wrote: > At first glance: > This is private black list of email assesses maintened by many. Free > to use, but it'll turn into a huge file for a server to parse. Well yes, if you aren't smart about how you use it. :) We use it by throwing away any entries older than 6 months and putting the rest in a database. We happen to use PostgreSQL, but you could also use something like Berkeley DB. Then lookups are fast. > I should rather block content not email addresses. I think an email address *known* to have been compromised is a fine thing to block, especially if you block mail going *to* that address. The list of phishing URLs is potentially very useful too, but as I said, we haven't started using those yet. Regards, David.
Re: Better phish detection
On Mon, 12 Mar 2012, Paul Russell wrote:
On 3/10/2012 16:43, Ned Slider wrote:
This one is easy enough - if the latter is the only valid url that should
ever appear in an email, create a meta rule that looks for a url containing
bway.net (or even just bway or webmail or login etc), but isn't
https://webmail.bway.net/.
Create meta rules for the common words you have identified. Link these with
a rule such as __HAS_ANY_URI or some of your webmail based URI rules above.
What other rules commonly hit - are they sent from freemail accounts? Do
they hit any DNSBL's?
It's not that simple. If it were, the problem would not have been ongoing for
at least 4 years.
Technically what Ned said is correct "This one is easy enough".
Yes THIS ONE (emphasis mine) is easy enough, but for some of us these
kind of spear-phishing attacks are an ever mutating problem and some
are damned clever.
Even the not too clever ones are problematic if they're good enough
to fool the victims (which sadly doesn't take too much ).
We have to control it in the mail stream as we cannot control how
our clients read their mail.
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: Better phish detection
"David F. Skoll" wrote: >Hi, > >I've been following this thread... not sure how many of you are aware >of >this project: > >http://code.google.com/p/anti-phishing-email-reply/ > >We use the phishing address list and it does catch a few things. We >don't yet use the phishing URL list, but it looks like it might help. > >Naturally, this list is reactive, but if enough people used it and >contributed to it, the results might be pretty good. > >Regards, > >David. At first glance: This is private black list of email assesses maintened by many. Free to use, but it'll turn into a huge file for a server to parse. Eventually we moved from hosts files to DNS :) I should rather block content not email addresses.
Re: Better phish detection
On 03/12/2012 05:45 PM, Paul Russell wrote: On 3/10/2012 16:43, Ned Slider wrote: This one is easy enough - if the latter is the only valid url that should ever appear in an email, create a meta rule that looks for a url containing bway.net (or even just bway or webmail or login etc), but isn't https://webmail.bway.net/. Create meta rules for the common words you have identified. Link these with a rule such as __HAS_ANY_URI or some of your webmail based URI rules above. > What other rules commonly hit - are they sent from freemail accounts? Do they hit any DNSBL's? It's not that simple. If it were, the problem would not have been ongoing for at least 4 years. If I could get enough samples together, I'd be willing to run an auto rule creation routine and make them available somewhere. If anybody can contribute please contact me off list Axb
Re: Better phish detection
Hi, I've been following this thread... not sure how many of you are aware of this project: http://code.google.com/p/anti-phishing-email-reply/ We use the phishing address list and it does catch a few things. We don't yet use the phishing URL list, but it looks like it might help. Naturally, this list is reactive, but if enough people used it and contributed to it, the results might be pretty good. Regards, David.
Re: Better phish detection
On 3/10/2012 16:43, Ned Slider wrote: This one is easy enough - if the latter is the only valid url that should ever appear in an email, create a meta rule that looks for a url containing bway.net (or even just bway or webmail or login etc), but isn't https://webmail.bway.net/. Create meta rules for the common words you have identified. Link these with a rule such as __HAS_ANY_URI or some of your webmail based URI rules above. > What other rules commonly hit - are they sent from freemail accounts? Do they hit any DNSBL's? It's not that simple. If it were, the problem would not have been ongoing for at least 4 years. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame
Re: Automatic rule generation Re: Better phish detection
On Sun, 11 Mar 2012, dar...@chaosreigns.com wrote: The software used to generate the sought rules, or perhaps an old version of it, is in the spamassassin source tree. You can feed it a folder of known non-spams, and a folder of known spams, and it'll auto-generate rules that hit the spams but not the non-spams. I've been collecting phish spams for quite a while looking to do something for phishing similar to the ADVANCE_FEE GA-evolved rules, I've just never gotten the round tuits. If you do start doing sought_phish I'd be more than happy to contribute my corpus and continue to keep it fresh. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Failure to plan ahead on someone else's part does not constitute an emergency on my part. -- David W. Barts in a.s.r --- Today: Daylight Saving Time begins in U.S. - Spring Forward
Re: Better phish detection
Dave Funk wrote: >> >> As an admin on a site that regularly gets hit with phish attacks, I can >> answer that. The forms are most often a web-page, which are: >> >> 1) forms hosted on Google-Docs or legit servey sites.[0] >> 2) sites hidden behind URL-shorteners would you want to submit details to a site with a redirected url? Probably SA is not the right tool here, because it would have to mark detected mail as "caution" >> 3) forms hidden in pages hosted on compromised legit sites.[1] >> 4) forms attached to mail messages, the attachments obfuscated by being >> MIME-typed as application/octet-stream but the file names ending in >> ".htm" >> so SA won't try looking inside but mail-clients -will- automagically >> "just do the right thing"(tm) [2] sounds like a potential improvement on any filter: try to identify attachments by their first 512 bytes rather than by filename or mime type >> 5) URIs that are obfuscated by being buried inside javascript that >> dynamically generates them at message open time.[3] If there was a "caution" rather than just "potential spam" mark, it should certainly mark javascript >> [3] Damn people who insist that HTML should be acceptable everwhere. >> I tried creating rules that blacklist email containing javascript >> but there's legit sites (purchase confirmations, reservation notices, >> etc) that insist on doing that crap. >> My own way of life: a) messages that do not list me in either To or Cc (that is most mailing lists) must come from whitelisted senders, otherwise they do not even make it to SA b) I read mails on a text interface with a nice "read this one message in browser" pushbutton c) the actual sending email address should not be completely obscured in the mail reader, in favor of a display name I have implemented b) at the company where I work. For more than 50 % of mails handled by average staff, the same pushbutton means "open in application". When this project started a decade ago, I could not find a way to associate that particular class of mails (identified by sender, subject line, and mime-type) with an application in either Netscape or Outlook. So the incentive is: have better workflow for the majority of messages, in exchange for a need to hit "view in browser" for some messages
Automatic rule generation Re: Better phish detection
The software used to generate the sought rules, or perhaps an old version of it, is in the spamassassin source tree. You can feed it a folder of known non-spams, and a folder of known spams, and it'll auto-generate rules that hit the spams but not the non-spams. Ah, I documented it some here: https://wiki.apache.org/spamassassin/WritingRules svn checkout http://svn.apache.org/repos/asf/spamassassin/trunk cd trunk/masses/rule-dev ./seek-phrases-in-corpus ham:dir:~/Maildir/ spam:dir:~/Maildir/.bad.spam-missed/ On 03/10, sporkman wrote: > > Hello, > > We are getting a fair amount of very targetted phish attempts to our > userbase. Since we are relatively small, I don't think any of the URIBLs > really help (or phishtank or other lists) since we're not a large bank or > paypal or anything like that. > > I did see some gentleman make a rather valiant attempt at listing all the > common phrases here: > > http://old.nabble.com/introducing-body-J_MAILBOX_FULL-tc33207944.html#a33213220 > > It has a number of errors, and obviously that's not very efficient (I suck > at regexs, but I know enough to know that list can be collapsed). > > Any pointers to a good starting point to take a list like that and make it > usable? The phrasing on these is always very similar - stuff about > upgrading your webmail account, etc. > > We're running qmail/vpopmail, and our upgrade to postfix to at least > front-end qmail is still a ways off. I think with postfix we could probably > catch a bunch of this garbage at the front door. So for now, our only real > tool to fight this is SA. > > I assume we're not the only ones seeing this mess, what are others doing to > counteract this? > > Thanks, > > Charles > -- > View this message in context: > http://old.nabble.com/Better-phish-detection-tp33478328p33478328.html > Sent from the SpamAssassin - Users mailing list archive at Nabble.com. > -- "If you are not paranoid... you may not be paying attention." - j...@creative-net.net, on an IDPA mailing list http://www.ChaosReigns.com
Re: Better phish detection
On 10/03/12 20:27, sporkman wrote: Generally it is easier to offer suggestions if examples are provided (on pastebin) Here's the latest example: http://broomesol.com/upgrade.webmail.bway.net/main_login.htm Compare to our actual webmail login: https://webmail.bway.net/ This one is easy enough - if the latter is the only valid url that should ever appear in an email, create a meta rule that looks for a url containing bway.net (or even just bway or webmail or login etc), but isn't https://webmail.bway.net/. Create meta rules for the common words you have identified. Link these with a rule such as __HAS_ANY_URI or some of your webmail based URI rules above. What other rules commonly hit - are they sent from freemail accounts? Do they hit any DNSBL's? Thanks, Charles
Re: Better phish detection
Hi, the replica seems to be down Things that could be promising: a) the form target seems to be similar to your site name b) it is probably possible to detect similarity between your image and the replica I guess that the presence of upgrade or webmail and a form url with bway inside might work as a filter. Regards Wolfgang
Re: Better phish detection
On Sat, 10 Mar 2012, haman...@t-online.de wrote:
Hello,
We are getting a fair amount of very targetted phish attempts to our
userbase. Since we are relatively small, I don't think any of the URIBLs
really help (or phishtank or other lists) since we're not a large bank or
paypal or anything like that.
I did see some gentleman make a rather valiant attempt at listing all the
common phrases here:
Hi,
I would not feel inclined to update a filter every day so the question is:
what do
these things have in common?
It seems somebody wants your users to complete a form where would the form
be sent to?
A valid domain, or just some ip address
Regards
Wolfgang
As an admin on a site that regularly gets hit with phish attacks, I can
answer that. The forms are most often a web-page, which are:
1) forms hosted on Google-Docs or legit servey sites.[0]
2) sites hidden behind URL-shorteners
3) forms hidden in pages hosted on compromised legit sites.[1]
4) forms attached to mail messages, the attachments obfuscated by being
MIME-typed as application/octet-stream but the file names ending in ".htm"
so SA won't try looking inside but mail-clients -will- automagically
"just do the right thing"(tm) [2]
5) URIs that are obfuscated by being buried inside javascript that
dynamically generates them at message open time.[3]
I've got a number of invisible __rules that look for things such as URIs
that have the text "form" anywhere in it etc, look for various key words
("quota","passord","account", etc) and then a bunch of metas that tie them
together; but it's a never ending battle. ;(
[0] Have to regularly scan my spamtraps, look for such crap and then go
click the "report abuse" link.
[1] I wish I could dope-slap all the people who think they can set up a
WordPress site and just let it run with out ever updating/monitoring
it.
[2] How do you fight attacks that SA isn't even willing to try to look at?
Hey SA devs, can I make an enhancement request. I tried creating a
rule that looked for that sort of crap but there's legit mail that
does it too.
[3] Damn people who insist that HTML should be acceptable everwhere.
I tried creating rules that blacklist email containing javascript
but there's legit sites (purchase confirmations, reservation notices,
etc) that insist on doing that crap.
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: Better phish detection
hamann.w wrote: > >>> >>> >>> Hello, >>> >>> We are getting a fair amount of very targetted phish attempts to our >>> userbase. Since we are relatively small, I don't think any of the >>> URIBLs >>> really help (or phishtank or other lists) since we're not a large bank >>> or >>> paypal or anything like that. >>> >>> I did see some gentleman make a rather valiant attempt at listing all >>> the >>> common phrases here: >>> > > > Hi, > > I would not feel inclined to update a filter every day so the > question is: what do > these things have in common? > The message is always short, always mentions "webmail", "upgrade", "update", "your information" and then a link to an offsite URL. The list of words in the linked ruleset is pretty much on target for the type of phrases they include. Older variations did not link to a form, but instead simply asked the user to reply with their email and password (which, sadly always worked on a few of our users). hamann.w wrote: > > It seems somebody wants your users to complete a form where would the > form be sent to? > A valid domain, or just some ip address > Usually a valid, legitimate domain. Obviously a hacked site where they have installed a form that collects the login info. They used to hotlink our css and images until I started serving up a "different" version. Now they host the images and css with the form. Here's the latest example: http://broomesol.com/upgrade.webmail.bway.net/main_login.htm Compare to our actual webmail login: https://webmail.bway.net/ Thanks, Charles hamann.w wrote: > > > Regards > Wolfgang > > a fellow qmail user :) > > -- View this message in context: http://old.nabble.com/Better-phish-detection-tp33478328p33478504.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Better phish detection
>> >> >> Hello, >> >> We are getting a fair amount of very targetted phish attempts to our >> userbase. Since we are relatively small, I don't think any of the URIBLs >> really help (or phishtank or other lists) since we're not a large bank or >> paypal or anything like that. >> >> I did see some gentleman make a rather valiant attempt at listing all the >> common phrases here: >> Hi, I would not feel inclined to update a filter every day so the question is: what do these things have in common? It seems somebody wants your users to complete a form where would the form be sent to? A valid domain, or just some ip address Regards Wolfgang a fellow qmail user :)
