Re: [mailop] Spam from Google Work Space sender domain via Google IP(s )

2021-04-29 Thread vsai--- via mailop 
Thank you Arne and Med for your valuable suggestions. I'm new here. Appreciate 
your help in this regard. Regards,Stanley V.

-- Original Message --
From: Arne Jensen 
To: "v...@netzero.net" , mailop@mailop.org
Subject: Re: [mailop] Spam from Google Work Space sender domain via Google IP(s)
Date: Wed, 28 Apr 2021 09:15:09 +0200


Den 28-04-2021 kl. 06:27 skrev vsai--- via mailop:
> I've been receiving spam and phishing scams from Google IP(s).
>
> All these messages have the sender domains associated either with
> Godaddy or with Google work space.
>
> Some of the sample sender domains are listed below:
>
> **

Several of these domains exists in Spam Eating Monkey's FRESH lists,
since they were registered very recently, some of them 2 days old, some
of them around 10 days.

-> https://spameatingmonkey.com/

You might be able to use the FRESH list to trigger on domains that were
registered (very) recently, with their FRESH lists.

A couple of the listed domains that does not appear in SEM FRESH, seems
to exist in URIBL's "black" zone:

-> https://uribl.com/


Licenses and terms/conditions for various of such "reputation" lists may
vary quite a lot, so you will seriously need to go through their
policies, to figure out if you are able to incorporate their data in
your systems.

Not doing so from the beginning, might cause severe consequences...


>
> I could see couple of patterns in these spam.
>
> 1. Spamming from Google groups with topic 25838:
>
>Example: List-Help:
> <https://support.google.com/a/bfjnusfg.lanawilliams.today/bin/topic.py?topic=25838>,

SEM FRESH and URIBL mentioned above would here require you to split it
out to the real domain, e.g. "lanawilliams.today", before you look it up.

Even if you  go to
"https://support.google.com/a/this.stuff.does.not.exist.invalid/bin/topic.py?topic=25838;,
you will also be redirected to
"https://support.google.com/a/topic/25838;, so you have some options here:

a) With the classic kind of learning spam/ham in spam filters, you might
be able to make your systems"learn" the full/exact link towards being
either spam/ham, but with the amount of different possibilities there
could be, e.g.:

->
https://support.google.com/a/this.stuff.does.not.exist.invalid/bin/topic.py?topic=25838
->
https://support.google.com/a/another.one.that.does.not.exist.invalid/bin/topic.py?topic=25838

That option may not be very feasible, ... for some.

b) You could split out the "real domain" from the URI if it matches the
Google link, and then look up the domain in various of those URI / RHS
lists.

->
https://support.google.com/a/bfjnusfg.lanawilliams.today/bin/topic.py?topic=25838
(lookup: lanawilliams.today)
->
https://support.google.com/a/a.very.simple.example.net/bin/topic.py?topic=25838
(lookup: example.net)
->
https://support.google.com/a/another.fancy.example.co.uk/bin/topic.py?topic=25838
(lookup: example.co.uk)

Depending on your systems, this may not be very simple, such as e.g.
getting "example.co.uk" and other second-, third- (or further level)
registrations like there.


For the extracting, I would however suggest using the Public Suffix list:

-> https://publicsuffix.org/

There are some libraries out there for many programming languages out there.

>
> 2. Received lines has lines either single or multiple "X-Received: by
> 2002"
>
>Example:
> ***
> X-Received: by 2002:ac2:5f75:: with SMTP id
> c21mr4375339lfc.600.1618693533415;
> Sat, 17 Apr 2021 14:05:33 -0700 (PDT)
IPv6 subnet 2002:ac2:5f75::/48, refers to IPv4 address 10.194.95.117.
> Received: by 2002:a05:6512:c22:: with SMTP id
> z34ls4162850lfu.2.gmail; Sat, 17
>  Apr 2021 14:05:32 -0700 (PDT)
IPv6 subnet 2002:a05:6512::/48, refers to IPv4 address 10.5.101.18.
> X-Received: by 2002:a19:7508:: with SMTP id
> y8mr7152413lfe.123.1618693532208;
> Sat, 17 Apr 2021 14:05:32 -0700 (PDT)
> ***

IPv6 subnet 2002:a19:7508::/48, refers to IPv4 address 10.25.117.8.

These IPv6 addresses/subnets are part of the 2002::/16 6to4 anycast
network. So I wouldn't put any weight to them.

Maybe if you expanded them to the IPv4 addresses (hex decode the IPv4
with the first two groups after 2002: minus any :'s in the middle
(ac25f75, a056512 & a197508)), and then maybe if these were actually
revealing other "public IP addresses", and not private/reserved IP
addresses, there might be a chance of using them to detect stuff.

The majority (if not all) of Google email headers seem to indicate
Google is using the 10.0.0.0/8 equivalent of the 6to4 IPv6 space (e.g.
2002:a00::/24  (2002:0a00:0

Re: [mailop] Spam from Google Work Space sender domain via Google IP(s)

2021-04-28 Thread Vsevolod Stakhov via mailop 
On 28/04/2021 05:27, vsai--- via mailop wrote:
> Hi,
>  
> I've been receiving spam and phishing scams from Google IP(s).
> 
> All these messages have the sender domains associated either with
> Godaddy or with Google work space.
> 
> Some of the sample sender domains are listed below:
> 
> **
> craigmaldonado.monster
> kepinbujang35.online
> kepinbujang247.online
> memekssuper247.online
> bujangmememks287.online
> baukkmemmek23792.online
> memekbusukk23.online
> memekssuper.online
> baukkmemmek23993.online
> kilokara.monster
> rogelioholland.today
> memekspromhome23.online
> bujangmememks248.online
> komkarasa.monster
> loduviskin.monster
> tommienguyen.world
> **

If you use Rspamd, then the solution recipe is pretty trivial. Use rbl
module with a custom selector to filter out fresh domains from the
X-BeenThere header (using, for example Spam Eating Monkey list). Here is
the complete example:

Add the following to the `/etc/rspamd/rspamd.local.lua` to register a
custom extraction routine:

```
-- Add to rspamd.local.lua
local lua_selectors = require "lua_selectors"
local rspamd_util = require "rspamd_util"

lua_selectors.register_extractor(rspamd_config, 'x_been_there_tld', {
  get_value = function(task, args)
local res = {}
local hdr = task:get_header_full('X-BeenThere')

if hdr then
  for _,h in ipairs(hdr) do
local email_maybe = rspamd_util.parse_mail_address(h.decoded,
task:get_mempool())

if email_maybe and email_maybe[1] then
  table.insert(res, rspamd_util.get_tld(email_maybe[1].domain))
end
  end
end
return res, 'string_list'
  end,
  description = 'Table with a list of X-Been-There eslds'
})
```

Then use this selector in the RBL module by adding the following to
`/etc/rspamd/local.d/rbl.conf`:

```
# local.d/rbl.conf
rules {
  SEM_FRESH_X_BEEN_THERE {
selector = "x_been_there_tld()";
rbl = fresh30.spameatingmonkey.net;
score = 4.0;
  }
}
```

This rule is pretty aggressive so I would also limit it with some list
of the most abused top level domains (such as `.today`, `.xyz` and other
crap).
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Spam from Google Work Space sender domain via Google IP(s)

2021-04-28 Thread Arne Jensen via mailop 

Den 28-04-2021 kl. 06:27 skrev vsai--- via mailop:
> I've been receiving spam and phishing scams from Google IP(s).
>
> All these messages have the sender domains associated either with
> Godaddy or with Google work space.
>
> Some of the sample sender domains are listed below:
>
> **

Several of these domains exists in Spam Eating Monkey's FRESH lists,
since they were registered very recently, some of them 2 days old, some
of them around 10 days.

-> https://spameatingmonkey.com/

You might be able to use the FRESH list to trigger on domains that were
registered (very) recently, with their FRESH lists.

A couple of the listed domains that does not appear in SEM FRESH, seems
to exist in URIBL's "black" zone:

-> https://uribl.com/


Licenses and terms/conditions for various of such "reputation" lists may
vary quite a lot, so you will seriously need to go through their
policies, to figure out if you are able to incorporate their data in
your systems.

Not doing so from the beginning, might cause severe consequences...


>
> I could see couple of patterns in these spam.
>
> 1. Spamming from Google groups with topic 25838:
>
>    Example: List-Help:
> ,

SEM FRESH and URIBL mentioned above would here require you to split it
out to the real domain, e.g. "lanawilliams.today", before you look it up.

Even if you  go to
"https://support.google.com/a/this.stuff.does.not.exist.invalid/bin/topic.py?topic=25838;,
you will also be redirected to
"https://support.google.com/a/topic/25838;, so you have some options here:

a) With the classic kind of learning spam/ham in spam filters, you might
be able to make your systems"learn" the full/exact link towards being
either spam/ham, but with the amount of different possibilities there
could be, e.g.:

->
https://support.google.com/a/this.stuff.does.not.exist.invalid/bin/topic.py?topic=25838
->
https://support.google.com/a/another.one.that.does.not.exist.invalid/bin/topic.py?topic=25838

That option may not be very feasible, ... for some.

b) You could split out the "real domain" from the URI if it matches the
Google link, and then look up the domain in various of those URI / RHS
lists.

->
https://support.google.com/a/bfjnusfg.lanawilliams.today/bin/topic.py?topic=25838
(lookup: lanawilliams.today)
->
https://support.google.com/a/a.very.simple.example.net/bin/topic.py?topic=25838
(lookup: example.net)
->
https://support.google.com/a/another.fancy.example.co.uk/bin/topic.py?topic=25838
(lookup: example.co.uk)

Depending on your systems, this may not be very simple, such as e.g.
getting "example.co.uk" and other second-, third- (or further level)
registrations like there.


For the extracting, I would however suggest using the Public Suffix list:

-> https://publicsuffix.org/

There are some libraries out there for many programming languages out there.

>    
> 2. Received lines has lines either single or multiple "X-Received: by
> 2002"
>
>    Example:
>     ***
>     X-Received: by 2002:ac2:5f75:: with SMTP id
> c21mr4375339lfc.600.1618693533415;
>     Sat, 17 Apr 2021 14:05:33 -0700 (PDT)
IPv6 subnet 2002:ac2:5f75::/48, refers to IPv4 address 10.194.95.117.
>     Received: by 2002:a05:6512:c22:: with SMTP id
> z34ls4162850lfu.2.gmail; Sat, 17
>      Apr 2021 14:05:32 -0700 (PDT)
IPv6 subnet 2002:a05:6512::/48, refers to IPv4 address 10.5.101.18.
>     X-Received: by 2002:a19:7508:: with SMTP id
> y8mr7152413lfe.123.1618693532208;
>     Sat, 17 Apr 2021 14:05:32 -0700 (PDT)
>     ***

IPv6 subnet 2002:a19:7508::/48, refers to IPv4 address 10.25.117.8.

These IPv6 addresses/subnets are part of the 2002::/16 6to4 anycast
network. So I wouldn't put any weight to them.

Maybe if you expanded them to the IPv4 addresses (hex decode the IPv4
with the first two groups after 2002: minus any :'s in the middle
(ac25f75, a056512 & a197508)), and then maybe if these were actually
revealing other "public IP addresses", and not private/reserved IP
addresses, there might be a chance of using them to detect stuff.

The majority (if not all) of Google email headers seem to indicate
Google is using the 10.0.0.0/8 equivalent of the 6to4 IPv6 space (e.g.
2002:a00::/24  (2002:0a00:::::: -
2002:0aff::::::)) in their internal networks.

>     
> Please let us know if anyone is observing same trend of spam and what
> measures are taken to prevent these patterns.

Personally, I'm not currently experiencing it with Google, however - the
trend of using (... very) fresh domains seems to have raised over the
last months, and I do not mind rejecting domains younger than e.g. 30
days myself.


Another situation you could do to above, but which can cause collateral
damage in several situations, would be to look up each

[mailop] Spam from Google Work Space sender domain via Google IP(s)

2021-04-27 Thread vsai--- via mailop 
Hi, I've been receiving spam and phishing scams from Google IP(s).

All these messages have the sender domains associated either with Godaddy or 
with Google work space. 

Some of the sample sender domains are listed below:

**
craigmaldonado.monster
kepinbujang35.online
kepinbujang247.online
memekssuper247.online
bujangmememks287.online
baukkmemmek23792.online
memekbusukk23.online
memekssuper.online
baukkmemmek23993.online
kilokara.monster
rogelioholland.today
memekspromhome23.online
bujangmememks248.online
komkarasa.monster
loduviskin.monster
tommienguyen.world
**

I could see couple of patterns in these spam.

1. Spamming from Google groups with topic 25838:

   Example: List-Help: 
,
   
2. Received lines has lines either single or multiple "X-Received: by 2002" 

   Example: 
***
X-Received: by 2002:ac2:5f75:: with SMTP id 
c21mr4375339lfc.600.1618693533415;
Sat, 17 Apr 2021 14:05:33 -0700 (PDT)
X-BeenThere: rak825@bfjnusfg.lanawilliams.today
Received: by 2002:a05:6512:c22:: with SMTP id z34ls4162850lfu.2.gmail; Sat, 
17
 Apr 2021 14:05:32 -0700 (PDT)
X-Received: by 2002:a19:7508:: with SMTP id 
y8mr7152413lfe.123.1618693532208;
Sat, 17 Apr 2021 14:05:32 -0700 (PDT)
***

Please let us know if anyone is observing same trend of spam and what measures 
are taken to prevent these patterns. 

Does any one have any contact with Google, where we could forward such 
complaints. I've tried sending mails to Google IP abuse contact address(s) and 
also to  Google work space domain contact  & 
 but of no use. 

Appreciate your help in this regard. 

Regards,
Stanley V

Sponsored by 
https://www.newser.com/?utm_source=part_medium=uol_campaign=rss_taglines_more

Appalachian Trail Killer Headed to Psych Facility
http://thirdpartyoffers.netzero.net/TGL3231/6088e459a6bb164595c28st02vuc1
'Children Are Being Cremated. Newlyweds Are Being Cremated'
http://thirdpartyoffers.netzero.net/TGL3231/6088e459ca03664595c28st02vuc2
Finances of 2 Groups Hit Hardest During Pandemic
http://thirdpartyoffers.netzero.net/TGL3231/6088e459ed55464595c28st02vuc3___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop