On 2024-01-01 at 16:28:04 UTC-0500 (Mon, 1 Jan 2024 16:28:04 -0500)
Charles Sprickman <sp...@bway.net>
is rumored to have said:
Hi all,
Full headers are here as well: https://pastebin.com/wHNmnvtE
I'm not really following what's going on here - a few things confuse
me...
- the empty from envelope, which I thought was more of a "bounce"
thing
Yes. You can safely reject mail with a null sender that does not meet
norms for mail-system-generated mail.
- that it does seem formatted like a bounce
Not in the headers... No one legit sends bounces with "Content-Type:
text/html" or with In-Reply-To headers without a References header or Cc
headers.
- across multiple servers I'm seeing a ton more spam just like this
the past few weeks coming in via MS
Everyone's spam is unique.
I see some similar stuff at various sites but nothing in the places
where I can really dig into details. I don't see much null sender spam
at all. I do see a few cases of $jjunk@$ggarbage.onmicrosoft.com senders
similar to the From: header in your example, but they are all getting
caught by SA.
- I had assumed that MS (or gmail, or any large provider) would be a
bit more tuned to this kind of abuse
By their own customers? Have you been paying any attention this century?
MS could kill this particular flavor of spam (identifiable by
correlating patterns in From and other headers) if they wanted to. They
CHOOSE as a corporation to be a bad neighbor as a matter of unstated
policy and unconscious strategy. In the same way a junkie chooses their
dope...
Anyone else seeing this and if so, what mitigations are you doing in
SA?
In the one place where I save SA-rejected mail, I see nothing with
"onmicrosoft.com" anywhere except in mail talking about this garbage. On
a larger system with less retained info I see some similar-ish messages
but nothing similar with null senders.
I don't see an obvious pattern of SA rule matches in the similar
messages that are being rejected on the systems I have access to. I also
see no null senders from MS hosts associated with UUID-like message-Id
local parts. Hmmm... that might be an interesting rule.
To me, it appears that a company with some kind of on-prem email
server is using MS' inbound/outbound filtering/relaying for their
email, and I'm assuming that the company (acquiretm dot com) has
compromised account(s) being used for spam,
Not sure how you got there...
Everywhere in those headers that I see that domain I also see it
attributed as the HELO from IP address 193.176.158.140, which has no
obvious connection to the domain. That IP address is allocated via RIPE,
but it might be in Russia, Estonia, Hong Kong, or France depending on
which registration records you think are relevant.
I'd bet that you could get a perfect score sniping that IP address in
the various MS attribution headers, but that probably will not be useful
for long.
and that this type of account is valuable since it's relayed through a
somewhat "trusted" entity (MS). Stumped on the empty envelope from
though...
I assume that your system is turning <> into <MAILER-DAEMON>...
Full headers inline:
My first-glance thoughts are embedded below.
Return-Path: <MAILER-DAEMON>
[internal stuff snipped]
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
(mail-dm6nam11hn2245.outbound.protection.outlook.com [52.100.172.245])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256
bits))
(No client certificate requested)
by mail.MYDOMAIN.COM (Postfix) with ESMTPS id 731A6CCE43
for <myem...@mydomain.com>; Mon, 1 Jan 2024 14:23:31 -0500 (EST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com;
cv=none;
b=Icl1NbdVBzy5nVKV4XGHyD5lhcUdtzirTQuOX40QfE0Qb4eogob5tBOWT7T7oxZ6O7oogwqarlyCmJXZfKwxDknw8W/1q9UzYGmNu0vt9l/C/TAQGHd2qdDo7k/S5rA/VkvSbwsWsPlPzHM5gpPvERtV1AwGRibQFb7IAJkW1bL6aTyG8R2JHPyDtSE5hG+0/XFuct7sSqoyr8J1hv7cOP6ZsOmlfLFuKxYoAEqFdi0qCsQD/CjfFzFNcaj9Sas09hbA1E/lEU5lf43EJFPOUX9ieGQA292aleu0PO2lqaU+TOwrr9UdnSHPyo89vQUHCiMd9+4ZMb51dxkvx6dLWQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=cMMl8FFbE2iyyDXVN5kGmj7djfYu1Ef14DADjnKqLVc=;
b=gBRRLW2K0klYaRjOr+bNZO7zS3m+Kb+mkggilqYBqELoa12h3G5gwGFye+aLoJjtPSDnS1d0/GUkPYWm2/JlQZtoKmq4YAqwA4tnT2HYRcckobGDbhOcaop7wKmcQutiBxdr2iG8Hjmbvkf6jkP2AHL9kVqZv73Byv60sg1djmVaNHR+2qJd3vyQ3kepYsngd9QtdsyjjFBb+VjyItwaijKmjO4IBSIr4X5i5CmK+v67YoalMVjoXnKaMEpK/4Qh3Eh5zyzGHjdT7+QzK/T4cDSu+1XA+rHcK7G4/BTwLRs+NBTOYMT52Zr4eo5462nuo/ITG3+SjPM9g8QXkfJ06Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none (sender
ip is
193.176.158.140) smtp.rcpttodomain=MYDOMAIN.COM
smtp.helo=mail.acquiretm.com;
dmarc=none action=none header.from=x1r862t.onmicrosoft.com; dkim=none
(message not signed); arc=none (0)
Weird that this says the message wasn't signed when MS saw it...
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=x1r862t.onmicrosoft.com; s=selector1-x1r862t-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=cMMl8FFbE2iyyDXVN5kGmj7djfYu1Ef14DADjnKqLVc=;
b=R1X4dpKSgryTH6OLmMzRy/tDWLnQEV8mHOEEtjH+lXKLhUWP1IcSU7ti48ZJoXOksGz7A4+ZbSb5s1wNp2A4dGS+psXMeDNERbCeNVeGFRy/0AfJX4BSO52imrh48OaXFvTjmcrwSondZQkeC2plLlatu2jWPXn+a48T+gCuUZtFOpy6+1OlQqtOhQd5Ork4w7yD6nIicaXcQ4GhpDX1YM6zU02EUOSl+pxEgJj5/WuHvXNbtuTmdsGid1JhRnmIyvR15jGzXHkyrD/KYHw3evZSOV8pJ8EMpUPDEiwdHjDGYt38j/Wwiho5yVfR/zNZa5wELOq9bYgLK0G91JywQA==
When there's a signature. Which your SA says was good.
X-MS-Exchange-Authentication-Results: spf=none (sender IP is
193.176.158.140)
smtp.helo=mail.acquiretm.com; dkim=none (message not signed)
header.d=none;dmarc=none action=none
header.from=x1r862t.onmicrosoft.com;
Again, a bit weird... MS says there's no DKIM, but there is.
Date: Mon, 01 Jan 2024 20:19:49 +0100
Importance: high
Never a good sign...
Subject: Your iCloud Storage Is Full. Receive 50 GB for FREE
X-TOI-MSGID: <1660898088.4bdab4ab9e89d.1704136789...@acquiretm.com>
In-Reply-To:
<952htcjgcsdxt5hydix5kfocgsan34o2gphcyv...@egw.x1r862t.onmicrosoft.com>
Content-Type: text/html; charset="UTF-8"
CC: myem...@mydomain.com
To: myem...@mydomain.com
An idiosyncrasy...
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Storage Notice <info_qwzrlpcp...@x1r862t.onmicrosoft.com>
So, how many legit correspondents have email addresses matching
/info_[a-zA-Z]{11}@[a-z0-9]{7}.onmicrosoft.com/ and send your users
email?
Message-ID:
<0e3b3785-6682-4c22-b6d7-87286c342...@cy4pepf0000ee34.namprd05.prod.outlook.com>
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE34:EE_|CO6PR20MB3698:EE_
I'm guessing that CY4PEPF0000EE34 is an important identifier here.
Maybe CO6PR20MB3698 as well.
I'm not sure exactly what any of these X-* headers mean, as I'm not MS,
but if they are correlating nonces, I'm fine with that.
[...]
X-OriginatorOrg: x1r862t.onmicrosoft.com
Ask yourself: Do I want email from non-paying Microsoft email customers?
If the answer is "NO!" then that header provides a hint at a strong
rule.
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jan 2024
19:23:21.7479
(UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id:
3b787f74-e97d-4744-853e-08dc0aff1ea0
X-MS-Exchange-CrossTenant-Id: aae3bce2-b5e6-4c64-9336-2909094ee8c9
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp:
TenantId=aae3bce2-b5e6-4c64-9336-2909094ee8c9;Ip=[193.176.158.140];Helo=[mail.acquiretm.com]
How many variations on a customer ID does MS need?
X-MS-Exchange-CrossTenant-AuthSource:
CY4PEPF0000EE34.namprd05.prod.outlook.com
Definitely: CY4PEPF0000EE34 is some sort of Tenant/Source identifier.
Maybe helpful...
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
Really? I wonder how often that happens? I'm always interested in
anonymous auth (either 'auth')
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR20MB3698
And there's that correlating nonce again...
I don't know if any of those thoughts will give ideas for good actual
rules for you (or anyone) but they are what comes to mi9nd when I look
at those headers.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
