You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Gary Smith <ga...@primeexalia.com> on 2004/03/02 01:40:52 UTC
Paypal spam... Bad issue
I just received this spam a little while ago. What many novice users will find is a site identical to paypal. The problem is the link actually goes to http://shelbycreative.com/alacarte/webscr.dll which emulates the paypal site exactly, pop's it up in a new window and asks you for all of your CC information.
I think it might be time to create a rule that says if the link domain (whatever.com) doesn't match the href domain (for at least two levels of the TLD) it should be considered spoof.
This might help out a lot. Unfortunately I'm on outlook web access so I can't get all of the headers.
Gary Smith
Dear PayPal user,
We recently reviewed your account, and suspect that your PayPal account may
have been accessed by an unauthorized third party. Protecting the security
of your account and of the PayPal network is our primary concern.
Therefore, as a preventative measure, we have temporarily limited access to
sensitive PayPal account features.
Click below in order to regain access to your account:
https://www.paypal.com/cgi-bin/webscr?cmd=_login-run <http://shelbycreative.com/alacarte/webscr.dll>
For more information about how to protect your account, please visit
PayPal's Security Center, accessible via the "Security Center" link located
at the bottom of each page of the PayPal website.
We apologize for any inconvenience this may cause, and appreciate your
assistance in helping us maintain the integrity of the entire PayPal
system. Thank you for your prompt attention to this matter.
Sincerely,
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be
answered. For assistance, log in to your PayPal account and choose the
"Help" link in the header of any page.
PayPal Email ID PP198
PayPal Email ID PP316
Re: Paypal spam... Bad issue
Posted by LuKreme <kr...@kreme.com>.
On Mar 19, 2004, at 2:15 PM, Bob George wrote:
> Kelson Vibber wrote:
>> Have you looked at the 99_FVGT_Spoof.cf ruleset posted at
>> http://www.merchantsoverseas.com/wwwroot/gorilla/rules.htm ?
>
> They're great rules. I'm just approaching it from a slightly different
> angle, namely using other "smells like phish" characteristics such as
> commonly-hit default rules. I'd like to find a combination that can
> detect phishy stuff from NON-expected domains as well. Existing,
> commonly forged domains are one characteristic, but there are other
> fingerprints as well. I'm really after a "I'm not who I say I am"
> rule, which the forged rule in the set you referenced starts on.
Interesting, I JUST posted a rule on a new thread "Paypal/Ebay spoof
spam" on this topic. I took what is perhaps a simplistic (perhaps
overly so) approach of checking the headers From and Return-Path.
I'd love to hear comments, especially since it is my first attempt at
writing a SA rule.
--
"Hain't we got all the fools in town on our side? And hain't that a
big enough majority in any town?" - Huckleberry Finn
Re: Paypal spam... Bad issue
Posted by Kelson Vibber <ke...@speed.net>.
At 01:15 PM 3/19/2004, Bob George wrote:
>>Also, checking /ebay\.com/ will trigger on anything that combines a word
>>ending in e with "bay" (I saw this on a log entry about a message from
>>someplace called azurebay.com, although I suspect that was spam as
>>well.) You should probably check on /\bebay.com\b/i instead.
>
>That will only match on " ebay.com " though, right? I'm interested in any
>occurence of ebay.com, embedded in URLs as well (i.e.
>http://blah.ebay.com/fasel/)
\b matches any word boundary (where one side is alphanumeric and the other
side isn't - or isn't there), so /\bebay\.com/ will match "ebay.com" or
"www.ebay.com" or "othersite/ebay.com"
Kelson Vibber
SpeedGate Communications <www.speed.net>
Re: Paypal spam... Bad issue
Posted by Bob George <ma...@ttlexceeded.com>.
Kelson Vibber wrote:
> Have you looked at the 99_FVGT_Spoof.cf ruleset posted at
> http://www.merchantsoverseas.com/wwwroot/gorilla/rules.htm ?
They're great rules. I'm just approaching it from a slightly different
angle, namely using other "smells like phish" characteristics such as
commonly-hit default rules. I'd like to find a combination that can
detect phishy stuff from NON-expected domains as well. Existing,
commonly forged domains are one characteristic, but there are other
fingerprints as well. I'm really after a "I'm not who I say I am" rule,
which the forged rule in the set you referenced starts on.
I'm still doing very early testing (thus the low scores assigned), but
have had good luck so far. The approaches are certainly complementary,
so there's no reason not to combine or use both independently.
> It sounds like you might want to work with those rules as well. (But
> note that citibank sends mail through citicorp.com servers, not just
> citibank.com, so you'll need to change/disable that rule if it hasn't
> been updated yet!)
I'm going to add more domains, definitely. The 'gorilla' set is far more
complete. Received rules are a for-sure as well.
> Also, checking /ebay\.com/ will trigger on anything that combines a word
> ending in e with "bay" (I saw this on a log entry about a message from
> someplace called azurebay.com, although I suspect that was spam as
> well.) You should probably check on /\bebay.com\b/i instead.
That will only match on " ebay.com " though, right? I'm interested in
any occurence of ebay.com, embedded in URLs as well (i.e.
http://blah.ebay.com/fasel/) Perhaps:
[/.:]ebay\.com[/ ]
?
Mis-matched URL/description detection would be good as well. Hmm..
someone posted one of those recently I think.
- Bob
Re: Paypal spam... Bad issue
Posted by Kelson Vibber <ke...@speed.net>.
Have you looked at the 99_FVGT_Spoof.cf ruleset posted
at http://www.merchantsoverseas.com/wwwroot/gorilla/rules.htm ?
It sounds like you might want to work with those rules as well. (But note
that citibank sends mail through citicorp.com servers, not just
citibank.com, so you'll need to change/disable that rule if it hasn't been
updated yet!)
Also, checking /ebay\.com/ will trigger on anything that combines a word
ending in e with "bay" (I saw this on a log entry about a message from
someplace called azurebay.com, although I suspect that was spam as
well.) You should probably check on /\bebay.com\b/i instead.
Kelson Vibber
SpeedGate Communications <www.speed.net>
Re: Paypal spam... Bad issue
Posted by Bob George <ma...@ttlexceeded.com>.
Lucas Albers wrote:
> [...]
> How bout this rule?
>
> Simpler,dumber, but should do the trick:
> --------------------------------------------
> header PAYPAL_RECEIVED Received =~ /paypal\.com/i
> describe PAYPAL_RECEIVED Received from a paypal site
> score PAYPAL_RECEIVED .01
>
> #from
> header PAYPAL_FROM From =~ /paypal\.com/i
> describe PAYPAL_FROM Sent from paypal address
> score PAYPAL_FROM 0.1
>
> meta PAYPAL_SPOOF (!PAYPAL_RECEIVED && PAYPAL_FROM)
> describe PAYPAL_SPOOF Mail pretending to be sent from paypal
> score PAYPAL_SPOOF 10
> ------------------------------------------------
I've been having good luck with the following matching phishy messages.
I do like your PAYPAL_RECEIVED check, and will incorporate that. I'm
trying to build a list of commonly spoofed domains and build
__LOCAL_URI_ rules for them, then test against common characteristics. I
look for some common phrases, tests often hit by phishy messages, then
combine via meta for a "smells phishy" score.
--- cut here --- cut here ---
# Anti-phishing tests
uri __LOCAL_URI_EBAY /ebay\.com/
uri __LOCAL_URI_PAYPAL /paypal\.com/
body __LOCAL_PHISHPHRASE /\b(verify|check).*your.*(information|account)\b/i
meta __LOCAL_PHISHY_SCORES (NORMAL_HTTP_TO_IP || HTTP_ESCAPED_HOST ||
HTTP_EXCESSIVE_ESCAPES || RAZOR2_CHECK || PYZOR_CHECK || HIDE_WIN_STATUS)
# Anything from legit sources shouldn't have phishy characteristics
meta LOCAL_PHISH_URI ((__LOCAL_URI_EBAY || __LOCAL_URI_PAYPAL) &&
__LOCAL_PHISHY_SCORES)
describe LOCAL_PHISH_URI Phishy URIs and SA scores
score LOCAL_PHISH_URI 0.01
# Anything with phishy phrasing and phishy scores is probably seafood
meta LOCAL_PHISH_PHRASE (__LOCAL_PHISHPHRASE && __LOCAL_PHISHY_SCORES)
describe LOCAL_PHISH_PHRASE Phishy phrases and SA scores
score LOCAL_PHISH_PHRASE 0.01
--- cut here --- cut here ---
- Bob
Re: Paypal spam... Bad issue
Posted by Lucas Albers <ad...@cs.montana.edu>.
Daniel Quinlan said:
> I tried writing such a rule before phishing became common (just trying
> to match spam) and it was not a great success due to false positives on
> legitimate mail, but I think the idea has merit. At worst, it could be
> restricted to commonly phished sites like paypal.
>
Daniel,
How bout this rule?
Simpler,dumber, but should do the trick:
--------------------------------------------
header PAYPAL_RECEIVED Received =~ /paypal\.com/i
describe PAYPAL_RECEIVED Received from a paypal site
score PAYPAL_RECEIVED .01
#from
header PAYPAL_FROM From =~ /paypal\.com/i
describe PAYPAL_FROM Sent from paypal address
score PAYPAL_FROM 0.1
meta PAYPAL_SPOOF (!PAYPAL_RECEIVED && PAYPAL_FROM)
describe PAYPAL_SPOOF Mail pretending to be sent from paypal
score PAYPAL_SPOOF 10
------------------------------------------------
--
Luke Computer Science System Administrator
Security Administrator,College of Engineering
Montana State University-Bozeman,Montana
Re: Paypal spam... Bad issue
Posted by Daniel Quinlan <qu...@pathname.com>.
"Gary Smith" <ga...@primeexalia.com> writes:
> I just received this spam a little while ago. What many novice users
> will find is a site identical to paypal. The problem is the link
> actually goes to http://shelbycreative.com/alacarte/webscr.dll which
> emulates the paypal site exactly, pop's it up in a new window and asks
> you for all of your CC information.
It's called phishing.
> I think it might be time to create a rule that says if the link domain
> (whatever.com) doesn't match the href domain (for at least two levels
> of the TLD) it should be considered spoof.
I tried writing such a rule before phishing became common (just trying
to match spam) and it was not a great success due to false positives on
legitimate mail, but I think the idea has merit. At worst, it could be
restricted to commonly phished sites like paypal.
The code would not be too hard to write up in SVN HEAD... when closing a
link, compare the last URL with the last text.
Daniel
--
Daniel Quinlan anti-spam (SpamAssassin), Linux,
http://www.pathname.com/~quinlan/ and open source consulting