I guess that brings up another question that's unclear - was this
message from the org's Mimecast actually determined to be malicious?
Based on the information available, it just sounds like someone at the
organization sent Alex a (valid?) encrypted attachment from their Secure
Messaging portal with Mimecast.
- Mark Alley
On 12/6/2024 7:11 AM, Faisal Misle via mailop 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
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
