Fraud from Outlook.com

Problem reported by Douglas Foster - 9/25/2025 at 12:22 PM

Submitted

Below is an example of the security problems with Outlook.com.

The message is accepted from unauthenticated SMTP
SPF/DKIM/DMARC tests are performed on the message and documented with multiple authentication result headers. The headers confirm that the message was accepted without authentication.
The message is processed as if it was valid, and then a signature is added for yeshimconsulting.onmicrosoft.com. (If the domain had the correct CNAME entries configured, it would have received a signature for yeshimconsulting.com)
The message leaves Outlook.com with SPF Pass, and could have left with DMARC Pass as well.

The body of this message had a fraudulent link that requested review on an internal policy document.

Unfortunately, I have many legitimate correspondents who send messages that depend on this security hole. I could add full-header parsing logic so that I can detect this problem, then create a policy table with allow rules for the legitimate senders. I am reluctant to do that because my incoming filter process is taking an unacceptable amount of time to process each message already, but it may be necessary.

I have filed an abuse report with abuse@outlook.com, but they never acknowledge the submission. I am probably wasting my time, especially since they have clients who depend on the security hole.

I note that Microsoft Forefront checked the message for spam, but found nothing wrong, as usual.

FYI. Very frustrated.

Message Headers

Authentication-Results: smtp.<redacted>.com; arc=pass

Return-Path: <info@yes-himconsulting.com>

Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazon11022099.outbound.protection.outlook.com [40.93.195.99])

by <redacted>.com

with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256);

Tue, 23 Sep 2025 11:59:01 -0400

ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;

b=HmBubS0WzTbyO3UWt7ueOpABhX2UFQ8NX2rNx7rQVJNbE8WPM04SJ1+OvdXQ987wH0nnouLmyG+z+vTekZtgfdHH0KAB99nLvWUmLxiVe1bajAjt9v08lyV/ZRZ2woRPTXtySS9PI5a7L3SCLcTFJ+0vNWaBLYj0SNCqdvLKzI6stxarh4chDW9BxzjWFGvkuR9cMZd3ZcfqU+RygozhfX03PNCKtvlQ6p15gW5/O61HjhdLtxKj3emY3QHO5K10izNjEE2V33Gw7xl96Q/L4v+UBWxkgo8uRc+/xz4bC6V7cOpx9W0/5D/71Rwd+uP3UFwRE6AJTgqbvsyyzKVdFg==

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;

s=arcselector10001;

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=P/aLBHSm1ZdroTvLOQFBuM5um14DEQQ/RkJHuYeiioM=;

b=bt7Ks2XIoKEyaBlwN9/WWKiqfIlxSJvKdQ1KgrOzmEMYsN5cxBIntiDM7aAKwvHm3BVN5l0PgWjhNI6VUbneHbQ+XJzg3us6VeMLSmRE0474XTVjWpaNRvbgnWOaHnBeG6JVmscXUmoKbXgrc69uubfqkRSpsvgxp/OHrp2ZbFK0Nequt3wybJYDh1UbxmdJr2BBQe0D3pF2Bs9NZYaHxxilMWvO7/GrvF7AFtpjCA8FhZeOb8M5NvH89VN087nkmektWyeYZ7NiT0dfhEUOHmma/7Q+H36lN9uDxcO0sddeLdeTAYgBnla19Q/cXY12sg55kfF+HLSr0Aj57klqNw==

ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=fail (sender ip is

103.125.219.144) smtp.rcpttodomain=bayviewphysicians.com

smtp.mailfrom=yes-himconsulting.com; dmarc=fail (p=none sp=none pct=100)

action=none header.from=yes-himconsulting.com; dkim=none (message not

signed); arc=none (0)

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;

d=yeshimconsulting.onmicrosoft.com;

s=selector2-yeshimconsulting-onmicrosoft-com;

h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;

bh=P/aLBHSm1ZdroTvLOQFBuM5um14DEQQ/RkJHuYeiioM=;

b=oFZDtau5Ml3gUwt8matzaY+iI3QMu+kBWD6Q2+gJQfeNcACNr9qDOZBec1Jw7Ggg3hOXrxsGjLgFjhrvMqD/QnlrYLep+WMW3qijRlRRBdyNE0o8Ad6tzp+NaR5Cr42uw4C8ibwUis6ETXMuffsN9Mpc9AGQetMk5lkKIudnhzo=

Received: from DM6PR06CA0042.namprd06.prod.outlook.com (2603:10b6:5:54::19) by

SJ2PR22MB3965.namprd22.prod.outlook.com (2603:10b6:a03:501::22) with

Microsoft SMTP Server (version=TLS1_2,

cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Tue, 23 Sep

2025 15:58:57 +0000

Received: from CY4PEPF0000EE3D.namprd03.prod.outlook.com

(2603:10b6:5:54:cafe::49) by DM6PR06CA0042.outlook.office365.com

(2603:10b6:5:54::19) with Microsoft SMTP Server (version=TLS1_3,

cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Tue,

23 Sep 2025 15:58:57 +0000

X-MS-Exchange-Authentication-Results: spf=fail (sender IP is 103.125.219.144)

smtp.mailfrom=yes-himconsulting.com; dkim=none (message not signed)

header.d=none;dmarc=fail action=none header.from=yes-himconsulting.com;

Received-SPF: Fail (protection.outlook.com: domain of yes-himconsulting.com

does not designate 103.125.219.144 as permitted sender)

receiver=protection.outlook.com; client-ip=103.125.219.144;

helo=103.125.219.144;

Received: from 103.125.219.144 (103.125.219.144) by

CY4PEPF0000EE3D.mail.protection.outlook.com (10.167.242.15) with Microsoft

SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.12

via Frontend Transport; Tue, 23 Sep 2025 15:58:56 +0000

Date: Tue, 23 Sep 2025 15:58:55 +0000

To: <redacted>

From: info@yes-himconsulting.com

Subject: <redacted company name> Revised Q4 Handbook 23 Sep, 2025 8AF4-SFRZ1F-VSH1

Message-ID: <97523728QiIe-1727jRUi756-u72RZ93263jD@yes-himconsulting.com>

MIME-Version: 1.0

Content-Type: multipart/alternative; boundary="===============2994925143539375055=="

Content-Transfer-Encoding: 8bit

Return-Path: info@yes-himconsulting.com

X-EOPAttributedMessage: 0

X-MS-PublicTrafficType: Email

X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE3D:EE_|SJ2PR22MB3965:EE_

X-MS-Office365-Filtering-Correlation-Id: a37f375b-fdd0-489e-db10-08ddfaba1a80

X-MS-Exchange-SenderADCheck: 1

X-MS-Exchange-AntiSpam-Relay: 0

X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|34070700014|36860700013|1800799024|110011033|8096899003;

X-Forefront-Antispam-Report: CIP:103.125.219.144;CTRY:JP;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:103.125.219.144;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(34070700014)(36860700013)(1800799024)(110011033)(8096899003);DIR:OUT;SFP:1102;

X-OriginatorOrg: yes-himconsulting.com

X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2025 15:58:56.6924 (UTC)

X-MS-Exchange-CrossTenant-Network-Message-Id: a37f375b-fdd0-489e-db10-08ddfaba1a80

X-MS-Exchange-CrossTenant-Id: 63d579c8-4752-4690-9aba-5b5db313fbf0

X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=63d579c8-4752-4690-9aba-5b5db313fbf0;Ip=[103.125.219.144];Helo=[103.125.219.144]

X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000EE3D.namprd03.prod.outlook.com

X-MS-Exchange-CrossTenant-AuthAs: Anonymous

X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem

X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR22MB3965

3 Replies

Reply to Thread

K T Replied

11/10/2025 at 8:57 PM

try integrate rspamd, test above message it gets 17.4 score.

K T Replied

11/11/2025 at 7:42 PM

just found rspamd will not work in "inbound smtp" but after process

Douglas Foster Replied

11/12/2025 at 7:03 AM

About the original problem:

The example was also caught by my content filtering product. The issue was the authentication problem, which Outlook creates by allowing the attack. The best response will be a filtering redesign to look for ARC sets from Microsoft servers that have i=1 with spf=fail (or anything other than pass.) The challenge is to invest the effort to detect these (currently rare) problems without killing throughput for everything else.

About rSpamdD:

When called from SmarterMail, rSpamd runs after the SMTP session is closed. When called from PostScript, it appears that it can run as a "milteer" process while the SMTP session is open. I used to think the SmarterMail implementation was a flaw that should be fixed, but over time my philosophy has changed and now I don't care, because I want to respond 250 OK to everything. If the message is from a known-bad sender, I discard silently because I don't want to give any help to an attacker. If the message is possibly-bad, I want to send it to quarantine, where the analysis can go several ways:

The sender and the message are both bad. The sender needs to be blacklisted and the message discarded.
The sender is good, but the message is nuisance advertising, discard the message with no change to the sender's ability to send future messages.
The sender and message are both good. Release the message and either whitelist the sender or disable the filtering rule that cause the quarantine action. With either action, future messages of the same type will be allowed without quarantine. Sender never knows that his message was briefly considered suspicious.

I have looked at rSpamd. I am intrigued by the possibility that their tokenized content filtering may allow me to approach commercial-level filtering techniques without acquiring a PhD in linguistic analysis. On authentication, it seems to have the same design failures as everything else that I have examined.

About filtering design failures:

The filtering flow for every product should be:

Analyze identity: who is the sender? Unauthenticated senders raise red flags.
Analyze sender reputation: what do we know about the sender? Some are explicitly trusted with a whitelist rule. Some are explicitly distrusted with a blacklist rule. Some are implicitly trusted because their previous messages have been accepted. Some are unclassified because we have never communicated with them before. These unknown senders also raise read flags.
Analyze message content: Is this message acceptable, given what we know about the sender? High score messages raise red flags.

Red Flag handling:

The best solution for all three types of red flags is quarantinem but quarantine is labor-intensive and delays messages. An alternative is to allow the message to be delivered, but identity problematic messages for after-the-fact investigation. The alternative speeds delivery in exchange for increased risk.

For authentication, authentication of every message requires more techniques than just SPF and DMARC. When those techniques are properly applied, relatively few legitimate messages will be quarantined because of authentication failure.

Whether a red-flag message is sent to quarantine or review-after-delivery, these outcomes are possible.

If a message is unauthenticated but acceptable, the sender is given an alternate authentication rule. The review process demonstrates that the message is not an impersonation and that the sender qualifies for "implicit trust" classification because the current message is acceptable. In some cases, the sender may be whitelisted at the same time, but whitelisting is in addition to alternate authentication.
If a message is unauthenticated and unacceptable, the sender is blacklisted. One-time review saves me a lifetime of bad messages.
If a message is flagged by content filtering or unknown sender status, quarantine review produces one of the three outcomes discussed earlier.

The big takeaways are:

Reputation cannot be accurately applied unless the identity is verified. The worst case would be to whitelist a message that impersonates a high-trust sender.
Content filtering is implicitly dependent on verified identity, because content becomes acceptable or unacceptable based on the sender. Medical advice from a trusted medical source is different from ":quick trick" medical advice received from an unknown source.
If you consistently monitor your incoming traffic and block unwanted traffic, essentially all of your malicious traffic will come from unknown senders.

Problems with many tools:

Slavish obedience to the DMARC RFC, instead of providing the techniques for authentication of all messages and the policy structures necessary to support alternate authentication.
Failure to distinguish between known and unknown senders.
Failure to provide a message review interface that allows for efficient review of all messages to disposition quarantined items and to review allowed and block items for disposition errors.
Failure to provide an efficient mechanism for converting quarantined items into sender allow and sender block rules.

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text