You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "David F. Skoll" <df...@roaringpenguin.com> on 2013/03/01 18:43:37 UTC
Yahoo single-link spam common elements
Hi,
These are the common elements as far as I can see in the text/plain part
of the spam:
1) The URL always matches this regex:
http://\S+/\S+\.\s+\?
In other words, there's always a dot in the URL (not counting the dots
in the domain name itself) and a question mark.
2) The URL is then followed by possible whitespace and the name or address
of the sender.
3) This is followed by more possible whitespace and then the date and
time in a format that matches this regex:
\d{1,2}/\d{1,2}/\d{4} \d{1,2}:\d{1,2}:\d{1,2} [AP]M
Can others confirm this pattern?
Regards,
David.
Re: Yahoo single-link spam common elements
Posted by Martin Gregorie <ma...@gregorie.org>.
On Sat, 2013-03-02 at 01:11 +0000, Ned Slider wrote:
> That said, I just checked my example, and __MANY_RECIPS failed to fire.
> Here's the current rule:
>
> header __MANY_RECIPS ToCc =~ /(?:\@[^@]{5,30}){3}/
>
> Can someone explain the regex and why it fails to fire for 7 recipients?
>
Is the limit of 30 ^@ characters enough?
Martin
Re: Yahoo single-link spam common elements
Posted by Wolfgang Zeikat <wo...@desy.de>.
In an older episode, on 2013-03-02 02:19, Benny Pedersen wrote:
> Ned Slider skrev den 2013-03-02 02:11:
>
>> header __MANY_RECIPS ToCc =~ /(?:\@[^@]{5,30}){3}/
>>
>> Can someone explain the regex and why it fails to fire for 7 recipients?
>
> as i read it, it fires if there is more then 4 domains, not only 5
> recipients, just a wild guess from me since i am not good at perl yet
At least 3 domains rather. IMHO, the regexp means:
{3} repetitions of (@ followed by 5 to 30 characters that are _not_ @)
Hope this helps.
Cheers,
wolfgang
Re: Yahoo single-link spam common elements
Posted by Benny Pedersen <me...@junc.eu>.
Ned Slider skrev den 2013-03-02 02:11:
> header __MANY_RECIPS ToCc =~ /(?:\@[^@]{5,30}){3}/
>
> Can someone explain the regex and why it fails to fire for 7
> recipients?
as i read it, it fires if there is more then 4 domains, not only 5
recipients, just a wild guess from me since i am not good at perl yet
Re: Yahoo single-link spam common elements
Posted by John Hardin <jh...@impsec.org>.
On Sat, 2 Mar 2013, Wolfgang Zeikat wrote:
> In an older episode, on 2013-03-02 02:40, John Hardin wrote:
>
>> >
>> > header __MANY_RECIPS ToCc =~ /(?:\@[^@]{5,30}){3}/
>> >
>> > Can someone explain the regex and why it fails to fire for 7 recipients?
>>
>> (@, followed by 5-30 non-@ characters) repeated three times.
>
> Does that mean the same sequence of (@, followed by 5-30 non-@ characters),
> repeated 3 times?
The *same* sequence, no. Matching a repeating specific sequence would
involve capturing the match (using parens without the ?:) and
backreferences to refer to the capruted match later in the RE; it would
look something like:
/(\@[^@]{5,30})\1{2}/
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
So Microsoft's invented the ASCII equivalent to ugly ink spots that
appear on your letter when your pen is malfunctioning.
-- Greg Andrews, about Microsoft's way to encode apostrophes
-----------------------------------------------------------------------
12 days until Albert Einstein's 134th Birthday
Re: Yahoo single-link spam common elements
Posted by Wolfgang Zeikat <wo...@desy.de>.
In an older episode, on 2013-03-02 02:40, John Hardin wrote:
>>
>> header __MANY_RECIPS ToCc =~ /(?:\@[^@]{5,30}){3}/
>>
>> Can someone explain the regex and why it fails to fire for 7 recipients?
>
> (@, followed by 5-30 non-@ characters) repeated three times.
Does that mean the same sequence of (@, followed by 5-30 non-@
characters), repeated 3 times?
I wasn't sure about that earlier.
Regards,
wolfgang
Re: Yahoo single-link spam common elements
Posted by John Hardin <jh...@impsec.org>.
On Sat, 2 Mar 2013, Ned Slider wrote:
> On 02/03/13 01:40, John Hardin wrote:
>> On Sat, 2 Mar 2013, Ned Slider wrote:
>> >
>> > header __MANY_RECIPS ToCc =~ /(?:\@[^@]{5,30}){3}/
>> >
>> > Can someone explain the regex and why it fails to fire for 7 recipients?
>>
>> If the username + domain name + inter-address punctuation is longer than
>> 30 chars it won't work.
>>
>> I don't see a good reason for the upper limit, or at least for one that
>> restrictive. The To and Cc headers aren't going to be unboundedly long.
>
> Thanks John (and others).
>
> Yes, the limit of 30 looks too small. I just created a local rule upping the
> limit to 100 and it now fires as expected.
>
> John - can we increase the limit?
Upped to 100. I was going to suggest something smaller, but realized that
includes the user-visible-name part. 100 may not be enough given things
like encoded UTF-8 display names, but this will improve things.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
So Microsoft's invented the ASCII equivalent to ugly ink spots that
appear on your letter when your pen is malfunctioning.
-- Greg Andrews, about Microsoft's way to encode apostrophes
-----------------------------------------------------------------------
12 days until Albert Einstein's 134th Birthday
Re: Yahoo single-link spam common elements
Posted by Ned Slider <ne...@unixmail.co.uk>.
On 02/03/13 01:40, John Hardin wrote:
> On Sat, 2 Mar 2013, Ned Slider wrote:
>
>> On 01/03/13 19:55, Alexandre Boyer wrote:
>>> The famous 5 recipients...
>>>
>>> I had a (very) few exceptions while having the very same pattern in
>>> body. With 4 recipients instead of 5, and sometimes one among the 5
>>> with
>>> no To:address, just To:name, wich was harder to count...
>>>
>>> I removed the similar rule as your __RP_D_00040 from my systems to
>>> avoid
>>> false negatives.
>>>
>>> And no FP for a long time on this rule (this is an old bot, first saw
>>> last summer, but probably older but unnoticed).
>>>
>>
>> The example I posted earlier today had 7 recipients listed in To:
>> (sorry, I redacted them).
>>
>> Rather than using a rule specifically for 5 recipients, I would use
>> the existing __MANY_RECIPS rule in the meta rule.
>>
>> That said, I just checked my example, and __MANY_RECIPS failed to
>> fire. Here's the current rule:
>>
>> header __MANY_RECIPS ToCc =~ /(?:\@[^@]{5,30}){3}/
>>
>> Can someone explain the regex and why it fails to fire for 7 recipients?
>
> (@, followed by 5-30 non-@ characters) repeated three times.
>
> If the username + domain name + inter-address punctuation is longer than
> 30 chars it won't work.
>
> I don't see a good reason for the upper limit, or at least for one that
> restrictive. The To and Cc headers aren't going to be unboundedly long.
>
Thanks John (and others).
Yes, the limit of 30 looks too small. I just created a local rule upping
the limit to 100 and it now fires as expected.
John - can we increase the limit?
Re: Yahoo single-link spam common elements
Posted by John Hardin <jh...@impsec.org>.
On Sat, 2 Mar 2013, Ned Slider wrote:
> On 01/03/13 19:55, Alexandre Boyer wrote:
>> The famous 5 recipients...
>>
>> I had a (very) few exceptions while having the very same pattern in
>> body. With 4 recipients instead of 5, and sometimes one among the 5 with
>> no To:address, just To:name, wich was harder to count...
>>
>> I removed the similar rule as your __RP_D_00040 from my systems to avoid
>> false negatives.
>>
>> And no FP for a long time on this rule (this is an old bot, first saw
>> last summer, but probably older but unnoticed).
>>
>
> The example I posted earlier today had 7 recipients listed in To: (sorry, I
> redacted them).
>
> Rather than using a rule specifically for 5 recipients, I would use the
> existing __MANY_RECIPS rule in the meta rule.
>
> That said, I just checked my example, and __MANY_RECIPS failed to fire.
> Here's the current rule:
>
> header __MANY_RECIPS ToCc =~ /(?:\@[^@]{5,30}){3}/
>
> Can someone explain the regex and why it fails to fire for 7 recipients?
(@, followed by 5-30 non-@ characters) repeated three times.
If the username + domain name + inter-address punctuation is longer than
30 chars it won't work.
I don't see a good reason for the upper limit, or at least for one that
restrictive. The To and Cc headers aren't going to be unboundedly long.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
USMC Rules of Gunfighting #6: If you can choose what to bring to a
gunfight, bring a long gun and a friend with a long gun.
-----------------------------------------------------------------------
12 days until Albert Einstein's 134th Birthday
Re: Yahoo single-link spam common elements
Posted by Ned Slider <ne...@unixmail.co.uk>.
On 01/03/13 19:55, Alexandre Boyer wrote:
> The famous 5 recipients...
>
> I had a (very) few exceptions while having the very same pattern in
> body. With 4 recipients instead of 5, and sometimes one among the 5 with
> no To:address, just To:name, wich was harder to count...
>
> I removed the similar rule as your __RP_D_00040 from my systems to avoid
> false negatives.
>
> And no FP for a long time on this rule (this is an old bot, first saw
> last summer, but probably older but unnoticed).
>
The example I posted earlier today had 7 recipients listed in To:
(sorry, I redacted them).
Rather than using a rule specifically for 5 recipients, I would use the
existing __MANY_RECIPS rule in the meta rule.
That said, I just checked my example, and __MANY_RECIPS failed to fire.
Here's the current rule:
header __MANY_RECIPS ToCc =~ /(?:\@[^@]{5,30}){3}/
Can someone explain the regex and why it fails to fire for 7 recipients?
Re: Yahoo single-link spam common elements
Posted by Alexandre Boyer <bi...@gmail.com>.
The famous 5 recipients...
I had a (very) few exceptions while having the very same pattern in
body. With 4 recipients instead of 5, and sometimes one among the 5 with
no To:address, just To:name, wich was harder to count...
I removed the similar rule as your __RP_D_00040 from my systems to avoid
false negatives.
And no FP for a long time on this rule (this is an old bot, first saw
last summer, but probably older but unnoticed).
Alex, from prypiat.
Yes, I recycle.
On 13-03-01 02:45 PM, David F. Skoll wrote:
> On Fri, 01 Mar 2013 14:39:09 -0500
> Alexandre Boyer <bi...@gmail.com> wrote:
>
>> Pretty the same as what David suggests :-)
> My latest attempt is this:
>
> header __RP_D_00040_1 From:addr =~ /yahoo/i
> header __RP_D_00040_2 To =~ /(:?@.*?){5}/
> body __RP_D_00040_3 /http.{0,200}\d{1,2}:\d{1,2}:\d{1,2}/
> meta RP_D_00040 __RP_D_00040_1 &&__RP_D_00040_2 &&__RP_D_00040_3
> describe RP_D_00040 Yahoo single-line URL spam
>
> I'm a little worried about potential FPs, but we'll see how it goes.
>
> Regards,
>
> David.
Re: Yahoo single-link spam common elements
Posted by Alex <my...@gmail.com>.
Hi,
>>> header __RP_D_00040_1 From:addr =~ /yahoo/i
>>> header __RP_D_00040_2 To =~ /(:?@.*?){5}/
>>> body __RP_D_00040_3 /http.{0,200}\d{1,2}:\d{1,2}:\d{1,2}/
>>> meta RP_D_00040 __RP_D_00040_1 &&__RP_D_00040_2 &&__RP_D_00040_3
>>> describe RP_D_00040 Yahoo single-line URL spam
>>
>>
>> I'm seeing variations on this that aren't being caught, and I hoped
>> someone could help. I've pasted my example here:
>>
>> http://pastebin.com/ijb0PSep
>>
>> There are more than five recipients, and despite changing it higher,
>> it still doesn't work. The URL in my example is:
>>
>> http-://www.mahmut64.com/nkewyzvy/3yvbqe0s7nab8dyg7udx5k.ki?fq98xcccm
>>
>> (remove the initial dash)
>>
>> I can't figure out how the above URL differs from some of the others
>> that have been caught, such as:
>> http-://www.misbusquedas.com/armn/sac2c9s6ar1azb1hij1r8a.zyy?x1sy9d9zj06u
>
> The number in the domain name?
I misinterpreted how the rule actually works. Viewing in alpine
doesn't show the name and date, ala "2/27/2013 6:58:01" afterwards.
Now I understand the \d and colons.
My new example just has a bunch of crap afterwards, like:
http-://www.magickspellcraft.com/ddazfep/9tzbvn.jgbm36vlon?vl1j7qpfx0lb5rsnbntm
jwugzcv zwsymhxir.
vsd/
ysvmwtcvp jodij.
vsd/
Alex
Re: Yahoo single-link spam common elements
Posted by John Hardin <jh...@impsec.org>.
On Sun, 3 Mar 2013, Alex wrote:
> Hi,
>
>> My latest attempt is this:
>>
>> header __RP_D_00040_1 From:addr =~ /yahoo/i
>> header __RP_D_00040_2 To =~ /(:?@.*?){5}/
>> body __RP_D_00040_3 /http.{0,200}\d{1,2}:\d{1,2}:\d{1,2}/
>> meta RP_D_00040 __RP_D_00040_1 &&__RP_D_00040_2 &&__RP_D_00040_3
>> describe RP_D_00040 Yahoo single-line URL spam
>
> I'm seeing variations on this that aren't being caught, and I hoped
> someone could help. I've pasted my example here:
>
> http://pastebin.com/ijb0PSep
>
> There are more than five recipients, and despite changing it higher,
> it still doesn't work. The URL in my example is:
>
> http-://www.mahmut64.com/nkewyzvy/3yvbqe0s7nab8dyg7udx5k.ki?fq98xcccm
>
> (remove the initial dash)
>
> I can't figure out how the above URL differs from some of the others
> that have been caught, such as:
> http-://www.misbusquedas.com/armn/sac2c9s6ar1azb1hij1r8a.zyy?x1sy9d9zj06u
The number in the domain name?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@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
-----------------------------------------------------------------------
7 days until Daylight Saving Time begins in U.S. - Spring Forward
Re: Yahoo single-link spam common elements
Posted by Alex <my...@gmail.com>.
Hi,
> My latest attempt is this:
>
> header __RP_D_00040_1 From:addr =~ /yahoo/i
> header __RP_D_00040_2 To =~ /(:?@.*?){5}/
> body __RP_D_00040_3 /http.{0,200}\d{1,2}:\d{1,2}:\d{1,2}/
> meta RP_D_00040 __RP_D_00040_1 &&__RP_D_00040_2 &&__RP_D_00040_3
> describe RP_D_00040 Yahoo single-line URL spam
I'm seeing variations on this that aren't being caught, and I hoped
someone could help. I've pasted my example here:
http://pastebin.com/ijb0PSep
There are more than five recipients, and despite changing it higher,
it still doesn't work. The URL in my example is:
http-://www.mahmut64.com/nkewyzvy/3yvbqe0s7nab8dyg7udx5k.ki?fq98xcccm
(remove the initial dash)
I can't figure out how the above URL differs from some of the others
that have been caught, such as:
http-://www.misbusquedas.com/armn/sac2c9s6ar1azb1hij1r8a.zyy?x1sy9d9zj06u
Thanks,
Alex
Re: Yahoo single-link spam common elements
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Fri, 01 Mar 2013 14:39:09 -0500
Alexandre Boyer <bi...@gmail.com> wrote:
> Pretty the same as what David suggests :-)
My latest attempt is this:
header __RP_D_00040_1 From:addr =~ /yahoo/i
header __RP_D_00040_2 To =~ /(:?@.*?){5}/
body __RP_D_00040_3 /http.{0,200}\d{1,2}:\d{1,2}:\d{1,2}/
meta RP_D_00040 __RP_D_00040_1 &&__RP_D_00040_2 &&__RP_D_00040_3
describe RP_D_00040 Yahoo single-line URL spam
I'm a little worried about potential FPs, but we'll see how it goes.
Regards,
David.
Re: Yahoo single-link spam common elements
Posted by Alexandre Boyer <bi...@gmail.com>.
Right: the suggested pattern is working great, but there are some
variants as KAM says.
However I sense that these are not the same bots. The one with the "date
in body" is always the same (the spammer only changed the date format).
I heard about a cross site botnet exploit on Yahoo! and third party
website, but did not digged into that.
Here is what is working fine for me:
body __AJB_DATE_IN_BODY
m'\d{1,2}/\d{1,2}/\d{4}\s(\d{1,2}:){2}\d{2} [AP]M'
uri __AJB_RANDOMURI
m'/[a-z]{2,10}/[a-z1-9]{1,30}(\.[a-z1-9]{1,10}\?[a-z1-9]{1,30}|[\=\&][a-z1-9]{1,30})'
meta AJB_YAHOO_BOT AJB_REALYAHOO && HTML_MESSAGE &&
__AJB_DATE_IN_BODY && __AJB_RANDOMURI
score AJB_YAHOO_BOT 10.0
meta AJB_REALYAHOO __AJB_FROM_YAHOO && __RCVD_YAHOO
header __AJB_FROM_YAHOO From:addr =~ /\@yahoo\.c(a|om)/i
header __RCVD_YAHOO Received =~ m'\.yahoo\.c(a|om) .+ by
\S+\.zerospam\.ca'm
Pretty the same as what David suggests :-)
Also noticed that the To:, Reply-To: headers and the name in the
signature in the body matches. Wanted to code a plugin but the previous
rules are doing the job so...
Alex, from prypiat.
Yes, I recycle.
On 13-03-01 12:49 PM, Kevin A. McGrail wrote:
> On 3/1/2013 12:43 PM, David F. Skoll wrote:
>> These are the common elements as far as I can see in the text/plain part
>> of the spam:
>>
>> 1) The URL always matches this regex:
>>
>> http://\S+/\S+\.\s+\?
>>
>> In other words, there's always a dot in the URL (not counting the dots
>> in the domain name itself) and a question mark.
>>
>> 2) The URL is then followed by possible whitespace and the name or
>> address
>> of the sender.
>>
>> 3) This is followed by more possible whitespace and then the date and
>> time in a format that matches this regex:
>>
>> \d{1,2}/\d{1,2}/\d{4} \d{1,2}:\d{1,2}:\d{1,2} [AP]M
>>
>> Can others confirm this pattern?
> I can confirm this is ONE of the patterns we've seen but we have seen
> other variations.
>
> For example, here's one from yesterday that you'll note forges my
> brother as the sender:
>
> Return-Path: <ra...@yahoo.com>
> Received: from nm7.bullet.mail.gq1.yahoo.com
> (nm7.bullet.mail.gq1.yahoo.com [98.136.218.72])
> by intel1.peregrinehw.com (8.14.5/8.14.5) with SMTP id r1SI2WHg008621
> for <km...@peregrinehw.com>; Thu, 28 Feb 2013 13:02:33 -0500
> Received: from [98.137.12.61] by nm7.bullet.mail.gq1.yahoo.com with
> NNFMP; 28 Feb 2013 18:02:31 -0000
> Received: from [208.71.42.212] by tm6.bullet.mail.gq1.yahoo.com with
> NNFMP; 28 Feb 2013 18:02:31 -0000
> Received: from [127.0.0.1] by smtp223.mail.gq1.yahoo.com with NNFMP;
> 28 Feb 2013 18:02:31 -0000
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com;
> s=s1024; t=1362074551;
> bh=O2aFzcTOvDvCQALZoONOlZmCJiqlFu6WnhUAJG1clGI=;
> h=X-Yahoo-Newman-Id:Message-ID:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:Reply-To:Subject:Date:To;
> b=5sIC6wpAChfKFdhlWmr4OhjWCpNoMhTdxsbWPAIXYyD3f+O4QKMatwXxL7uvHeFc5TD//q4hW0HQDVJ+f/XJq71XHuBeWLySuYceP9ZP5gMRMnAR8uM9o9rWw0vnwSd7+3H3ff1rCd2FunGswYwlNAG5yz79uYE7xe+sXw5qs3c=
>
> X-Yahoo-Newman-Id: 533489.47072.bm@smtp223.mail.gq1.yahoo.com
> Message-ID: <53...@smtp223.mail.gq1.yahoo.com>
> X-Yahoo-Newman-Property: ymail-3
> X-YMail-OSG: jRlM9PUVM1m1fvPhWPzSnQEReLcFyK.eiCoVEK16XkMJTsp
> FUuOvETyd8ee4KmT2FuoE1n9krae3pEbGP2MbvtNXR6sdYnhJIxvfdiuEtob
> wr1ipSssPLDugG_B3KfoWpLJZs0YjG5TMqqVzDGih3D11pGQfAY6w.mgoOWY
> Vemeo4DqHYY8XYokWdUpIh65s1dDZlNaYvlqfF1MZudo2pV6wlPm_rMDWHvP
> DNawGoHaZr3qyELnp7ElYqt8BCCs0hushH3dTtn.mVpUMrTv3GzPnkMMGCvR
> O9U8mO_UIFwTMrWvkkzLcMKqdKdukq8.cPSh8VY5TRg_Xih7mDsVxksEIVcE
> OCOEMbBw9uApP4oRpc.pBlu9eDntaPpiUUPhpb9xxkQw4lcLJkx0RTt0GYD3
> uAMLNtukwnvce54PkLZl3JrIDGhvQuhKnZxYyRsne49aNjP11_3wZUo8wlvg
> guHiLuHcqkFb6lusTYz41fCHrSJ6VTYxwqlQcA0DioWPWPDZmkjLtrc2aER1
> MbKjYki6ceeLXQT21DGdb9Gui.eE43RA2Ix6qqTYRddM-
> X-Yahoo-SMTP: bHYtILuswBDzs9L.FhYpFEHr7NQ0kndD9GjKbx8-
> Received: from localhost (rasiel_mongado29@200.121.59.161 with login)
> by smtp223.mail.gq1.yahoo.com with SMTP; 28 Feb 2013 10:02:31
> -0800 PST
> From: TOBY MCGRAIL <ra...@yahoo.com>
> Reply-To: TOBY MCGRAIL <tv...@yahoo.com>
> Subject: KEVIN
> Date: Thu, 28 Feb 2013 10:05:47 -0800 (PST)
> To: Kevin <km...@peregrinehw.com>
>
> kevin, hey. look what I found!
> http://www.deguciumd-munged.lt/answerbabykevingreen/
>
>
> regards,
> KAM
Re: Yahoo single-link spam common elements
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 3/1/2013 12:43 PM, David F. Skoll wrote:
> These are the common elements as far as I can see in the text/plain part
> of the spam:
>
> 1) The URL always matches this regex:
>
> http://\S+/\S+\.\s+\?
>
> In other words, there's always a dot in the URL (not counting the dots
> in the domain name itself) and a question mark.
>
> 2) The URL is then followed by possible whitespace and the name or address
> of the sender.
>
> 3) This is followed by more possible whitespace and then the date and
> time in a format that matches this regex:
>
> \d{1,2}/\d{1,2}/\d{4} \d{1,2}:\d{1,2}:\d{1,2} [AP]M
>
> Can others confirm this pattern?
I can confirm this is ONE of the patterns we've seen but we have seen
other variations.
For example, here's one from yesterday that you'll note forges my
brother as the sender:
Return-Path: <ra...@yahoo.com>
Received: from nm7.bullet.mail.gq1.yahoo.com (nm7.bullet.mail.gq1.yahoo.com [98.136.218.72])
by intel1.peregrinehw.com (8.14.5/8.14.5) with SMTP id r1SI2WHg008621
for <km...@peregrinehw.com>; Thu, 28 Feb 2013 13:02:33 -0500
Received: from [98.137.12.61] by nm7.bullet.mail.gq1.yahoo.com with NNFMP; 28 Feb 2013 18:02:31 -0000
Received: from [208.71.42.212] by tm6.bullet.mail.gq1.yahoo.com with NNFMP; 28 Feb 2013 18:02:31 -0000
Received: from [127.0.0.1] by smtp223.mail.gq1.yahoo.com with NNFMP; 28 Feb 2013 18:02:31 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362074551; bh=O2aFzcTOvDvCQALZoONOlZmCJiqlFu6WnhUAJG1clGI=; h=X-Yahoo-Newman-Id:Message-ID:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:Reply-To:Subject:Date:To; b=5sIC6wpAChfKFdhlWmr4OhjWCpNoMhTdxsbWPAIXYyD3f+O4QKMatwXxL7uvHeFc5TD//q4hW0HQDVJ+f/XJq71XHuBeWLySuYceP9ZP5gMRMnAR8uM9o9rWw0vnwSd7+3H3ff1rCd2FunGswYwlNAG5yz79uYE7xe+sXw5qs3c=
X-Yahoo-Newman-Id: 533489.47072.bm@smtp223.mail.gq1.yahoo.com
Message-ID: <53...@smtp223.mail.gq1.yahoo.com>
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: jRlM9PUVM1m1fvPhWPzSnQEReLcFyK.eiCoVEK16XkMJTsp
FUuOvETyd8ee4KmT2FuoE1n9krae3pEbGP2MbvtNXR6sdYnhJIxvfdiuEtob
wr1ipSssPLDugG_B3KfoWpLJZs0YjG5TMqqVzDGih3D11pGQfAY6w.mgoOWY
Vemeo4DqHYY8XYokWdUpIh65s1dDZlNaYvlqfF1MZudo2pV6wlPm_rMDWHvP
DNawGoHaZr3qyELnp7ElYqt8BCCs0hushH3dTtn.mVpUMrTv3GzPnkMMGCvR
O9U8mO_UIFwTMrWvkkzLcMKqdKdukq8.cPSh8VY5TRg_Xih7mDsVxksEIVcE
OCOEMbBw9uApP4oRpc.pBlu9eDntaPpiUUPhpb9xxkQw4lcLJkx0RTt0GYD3
uAMLNtukwnvce54PkLZl3JrIDGhvQuhKnZxYyRsne49aNjP11_3wZUo8wlvg
guHiLuHcqkFb6lusTYz41fCHrSJ6VTYxwqlQcA0DioWPWPDZmkjLtrc2aER1
MbKjYki6ceeLXQT21DGdb9Gui.eE43RA2Ix6qqTYRddM-
X-Yahoo-SMTP: bHYtILuswBDzs9L.FhYpFEHr7NQ0kndD9GjKbx8-
Received: from localhost (rasiel_mongado29@200.121.59.161 with login)
by smtp223.mail.gq1.yahoo.com with SMTP; 28 Feb 2013 10:02:31 -0800 PST
From: TOBY MCGRAIL <ra...@yahoo.com>
Reply-To: TOBY MCGRAIL <tv...@yahoo.com>
Subject: KEVIN
Date: Thu, 28 Feb 2013 10:05:47 -0800 (PST)
To: Kevin <km...@peregrinehw.com>
kevin, hey. look what I found! http://www.deguciumd-munged.lt/answerbabykevingreen/
regards,
KAM
Re: Yahoo single-link spam common elements
Posted by Niamh Holding <ni...@fullbore.co.uk>.
Hello David,
Friday, March 1, 2013, 5:43:37 PM, you wrote:
DFS> Can others confirm this pattern?
No.
URL in yesterday's is http://b23144.s3-website-ap-northeast-1.amazonaws.com
--
Best regards,
Niamh mailto:niamh@fullbore.co.uk