I was also wondering if it was something like this... See the header below.
The spoofed domain was modified and replaced with 'example.com'.
========
Delivered-To: a...@theshcompany.com
Received: by 2002:a05:6020:ac0d:b0:310:9e0c:1a53 with SMTP id
nx13csp334454wdb;
Wed, 4 Dec 2024 07:35:38 -0800 (PST)
X-Forwarded-Encrypted: i=2;
ajvyccuqmynvi+2w9ko+zj11b+uh9sid1biehwiv4lxmglylhbw+dlpzhnneuewrp6g5l...@theshcompany.com
X-Google-Smtp-Source:
AGHT+IEUzyxkjDOfi7ff9PowG2PSRsWeRIHT1065GDjnXAWZGBQC4tsVUEdH4FYA36B/ea1aI/bQ
X-Received: by 2002:a05:622a:1a25:b0:461:4150:aaf4 with SMTP id
d75a77b69052e-4670c06ec55mr70133971cf.11.1733326537662;
Wed, 04 Dec 2024 07:35:37 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1733326537; cv=none;
d=google.com; s=arc-20240605;
b=C3s2/7kaXEOo7VkGGsVqVFwoWufRxUuOROevlDoJv4FQNU1tNNxlZiBJ8pa0vzeMpX
OpVkMoGmloUCON4qhbS9pJJpnXoK45r0LBooO2EVizoT6I3AuTBiW3dBFmZKxxmGj4Uy
HcyrLjNV+jp446YCiutjLY0OCKnnUTs2Kaelfwg0AhG8whaiD7hGkw/Qk1gA1lfkCG8G
sw+6UHJ4UY0CUnIgUkKi3a233tV93ciF6yA6zKM+WqKjVSgVx3n+w9vf9lqVqmoqXqaN
tKSRhiLMbUWsNuH8Idr9NB+3AUP51oGj1r3qRDZrG6Ihf9PZiXJPaMgJdEMQnRKrk4bg
B4+Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20240605;
h=content-language:mime-version:accept-language:message-id:date
:thread-index:thread-topic:subject:from;
bh=L9a15PF6bcK2nYCDvi+01a+IUoLHQgAvMPDicMMzSQI=;
fh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
b=fzWL7VxZynDqlKwrz+r0AQJmYwHn/bGu7PEbi8//9ckp2v/a0r0upZKxWp7aD29AIV
BjXqNjK5+nJ6LCxL8kj0xxg9ySKL1+U99eGmBV9w+DLdo09qBRY4IeDNu4N9xCqbam3e
9Ow8JUe1iPj4srQORMtudXeaMnEuBvCEGibRooa4Z35Or3g3Fu2MkxwPbcMB97GOJK/Y
rUJHVCc/2NzSdnz5dOMTUJZv0/a06jtanrtJvCHEjXqa6a91YFj8+tLWzfyhaNIm9vwM
09eW+aqCXowBq+PrB92mnycdK9NwpUAy4bqyoFVFnvOVtVvsfa8Iz3SGI7VIFa7jhZ11
B9Yw==;
dara=google.com
ARC-Authentication-Results: i=1; mx.google.com;
spf=pass (google.com: domain of pmoll...@example.com designates
170.10.133.179 as permitted sender) smtp.mailfrom=pmoll...@example.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
Return-Path: <pmoll...@example.com>
Received: from us-smtp-delivery-179.mimecast.com (
us-smtp-delivery-179.mimecast.com. [170.10.133.179])
by mx.google.com with ESMTPS id
d75a77b69052e-466c4258d83si167796611cf.595.2024.12.04.07.35.37
for <a...@theshcompany.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 04 Dec 2024 07:35:37 -0800 (PST)
Received-SPF: pass (google.com: domain of pmoll...@example.com designates
170.10.133.179 as permitted sender) client-ip=170.10.133.179;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of pmoll...@example.com designates
170.10.133.179 as permitted sender) smtp.mailfrom=pmoll...@example.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
===========
Best,
Alex
On Fri, Dec 6, 2024 at 2:11 PM Faisal Misle <fai...@emailgeek.eu> wrote:
> I'd love to see redacted headers. I wonder if it's similar to the
> Proofpoint bypass that was in the news a few cycles ago where any 365
> tenant can email through companies that have PFPT setup.
>
> On 12/6/24 1:43 PM, Alex Shakhov | SH Consulting via mailop wrote:
> > Hello, a few months ago, I was asked to audit emails and integrate a new
> > system for a company. The first thing I did was configure DMARC
> > reporting (replaced v=DMARC1; p=none;) and after two months of analyzing
> > their email traffic, I detected some spoofing activity along with a
> > messy SPF record and a misconfigured DKIM setup for Mimecast, which they
> > use to route outbound emails. The spoofed traffic was small, just <10
> > emails over two months.
> >
> > I reached out to their team and suggested adding the missing DKIM,
> > cleaning up their SPF record, and enforcing DMARC. I supported my
> > recommendations with detailed documentation and report. However, instead
> > of collaborating, they silently revoked my DNS access, removed the DMARC
> > policy I had set up, implemented the missing DKIM records, and
> > configured a free Postmark DMARC record. They then set the DMARC policy
> > to reject. The SPF record remained unchanged.
> >
> > A week later, I received a spoofed email from their domain with an
> > encrypted attachment. Surprisingly, my Google Workspace didn’t filter
> > it, and it landed directly in my inbox. I figured out that
> >
> > - The 'To' field was empty.
> > - DMARC was set to reject, but the email passed validation.
> > - SPF passed with 170.10.133.179 (a Mimecast relay).
> > - DKIM was missing.
> >
> > Their SPF record was still a complete mess, packed with unnecessary IPs
> > and services, although within the 10 DNS lookup limit. I have strong
> > reasons to believe that the combination of their improperly configured
> > SPF record and Mimecast's SEG setup allowed these spoofed emails to
> > appear legitimate and bypass filtering.
> >
> > I can’t say with 100% certainty that my explanation covers everything,
> > but this is definitely one version worth considering.
> >
> > For reference, here’s their SPF record:
> >
> > v=spf1 include:us._netblocks.mimecast.com <http://
> > netblocks.mimecast.com/> include:spf.protection.outlook.com <http://
> > spf.protection.outlook.com/> ip4:207.46.163.247 ip4:74.126.9.238
> > ip4:72.52.238.74 ip4:207.158.48.193/26
> > <http://207.158.48.193/26> ip4:209.216.210.32/28
> > <http://209.216.210.32/28> ip4:198.37.147.129
> > include:support.zendesk.com <http://support.zendesk.com/
> > > include:amazonses.com <http://amazonses.com/> include:_spf.smtp.com
> > <http://spf.smtp.com/> ~all
> >
> > Thank you for your attention.
> >
> > _______________________________________________
> > mailop mailing list
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
>
>
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
