How is this possible? Client receiving spam emails from himself...

thecomputerguy

thecomputerguy

Well-Known Member
Reaction score
1,326
Occasionally one of my MSP clients will send me an email saying they got spam from themselves. I don't understand how this happens, maybe someone can provide some insight. Here is what I can give you about the account:

Office 365 (E3 license)
Account has a strong password with 2FA enabled
Azure logs show no compromising logins
Security Defaults enabled (POP/SMTP disabled)
DKIM for the Primary and the .onmicrosoft domain is enabled
DMARC Record: v=DMARC1; p=quarantine;
SPF Record: v=spf1 include:spf.protection.outlook.com -all
Security Policy: Standard Protection

The message appears in Outlook as "Unverified user" but it still shows his email:

1676657416207.png

Headers (I have tried to remove all identifying information, please let me know if I have missed something):
There are references in the Headers that reference "sendgrid.net" this is not something we use. I'm not sure what why or how SPF is passing, and the IP of the sender is from sendgrid.net in Colorado

Received: from SJ0PR14MB4348.namprd14.prod.outlook.com (2603:10b6:a03:2e2::19)
by SJ0PR14MB4394.namprd14.prod.outlook.com with HTTPS; Mon, 13 Feb 2023
14:42:32 +0000
Received: from DM6PR04CA0003.namprd04.prod.outlook.com (2603:10b6:5:334::8) by
SJ0PR14MB4348.namprd14.prod.outlook.com (2603:10b6:a03:2e2::19) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.24; Mon, 13 Feb
2023 14:42:29 +0000
Received: from DM6NAM11FT073.eop-nam11.prod.protection.outlook.com
(2603:10b6:5:334:cafe::7e) by DM6PR04CA0003.outlook.office365.com
(2603:10b6:5:334::8) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.24 via Frontend
Transport; Mon, 13 Feb 2023 14:42:29 +0000
Authentication-Results: spf=pass (sender IP is 167.89.62.90)
smtp.mailfrom=sendgrid.net; dkim=pass (signature was verified)
header.d=sendgrid.net;dmarc=fail action=quarantine
header.from=contoso.com;compauth=fail reason=000
Received-SPF: Pass (protection.outlook.com: domain of sendgrid.net designates
167.89.62.90 as permitted sender) receiver=protection.outlook.com;
client-ip=167.89.62.90; helo=xtrwpzrx.outbound-mail.sendgrid.net; pr=C
Received: from xtrwpzrx.outbound-mail.sendgrid.net (167.89.62.90) by
DM6NAM11FT073.mail.protection.outlook.com (10.13.173.152) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.6086.24 via Frontend Transport; Mon, 13 Feb 2023 14:42:28 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sendgrid.net;
h=content-type:content-transfer-encoding:from:subject:mime-version:to:
cc:content-type:from:subject:to;
s=smtpapi; bh=38eTXNW+z0gU11XLi5M7k13BdUDusuFR9iCib9OXEFY=;
b=nfOPJ/ht25WgQvgAmmYez3oFxO7ZmtAClk2qMAcKi31SNI17++tFjmZFspQk2xbIWEib
rlQ7jlXLtUTUapIgsN+EIkJQZetp23nG2ysMj1Rr0OL9BqR98Fju426OPYXkxnQ1Wg0Jo/
d+yAPpG4e6ZcWinxNKXgchtU9jeAoJn8w=
Received: by filterdrecv-86b5bc95bc-hv5kd with SMTP id filterdrecv-86b5bc95bc-hv5kd-1-63EA3FDC-9D
2023-02-13 13:49:16.894372792 +0000 UTC m=+240571.649337962
Received: from [127.0.0.1] (unknown)
by geopod-ismtpd-4-2 (SG) with ESMTP
id EGrfJYSTQ4G7jbFKuudZLg
for <user@contoso.com>;
Mon, 13 Feb 2023 13:49:16.626 +0000 (UTC)
Content-Type: text/html; name=eFAX.html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=eFAX.html
X-Ma4-Node: false
From: Monday February 13th Notification <user@contoso.com>
Subject: February 13th Notification
Message-ID: <944d13f2-89ad-889c-ba35-727b768f1c00@contoso.com>
Date: Mon, 13 Feb 2023 13:49:16 +0000 (UTC)
MIME-Version: 1.0
X-SG-EID:
=?us-ascii?Q?4=2FLD4q+md0BH=2FIhrkJ6f9Y5Wj2TClMw1Sa041MlSj7y73=2FLIRWGpLvz7InOqnf?=
=?us-ascii?Q?JfXc0rqib=2FCrWVUEkwsQPywVOVH9BX5d8cWuOPB?=
=?us-ascii?Q?hVy0XldnsylZ3RFIEws6dSzfLKaaG3UJgC3LpH3?=
=?us-ascii?Q?Y0kXEoxId1LvpNYRvaA4AGzjPOqD3VLY5Fq+gh=2F?=
=?us-ascii?Q?ZSAcw4W2Rkb3xRJvobccI9uoNaNu2qnenvqOcJk?=
=?us-ascii?Q?OKhsHnUrpj2UNy5Al6vBeChza5NacP+zPiELd=2FS?=
=?us-ascii?Q?1ANMOyLYzEvrPrHaqriHV2QQ+onx275shwiMyJ9?= =?us-ascii?Q?rm0=3D?=
To: user@contoso.com
X-Entity-ID: WcmXbi2dkeNalXX/pLSqaw==
Return-Path: bounces+9925965-68ec-user=contoso.com@sendgrid.net
X-MS-Exchange-Organization-ExpirationStartTime: 13 Feb 2023 14:42:28.8731
(UTC)
X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit
X-MS-Exchange-Organization-ExpirationInterval: 1:00:00:00.0000000
X-MS-Exchange-Organization-ExpirationIntervalReason: OriginalSubmit
X-MS-Exchange-Organization-Network-Message-Id:
ad44b508-5f1b-456d-1c8a-08db0dd087fa
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 1d9c0769-0601-4538-b2dc-e9946f6ea2e4:0
X-MS-Exchange-Organization-MessageDirectionality: Incoming
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM6NAM11FT073:EE_|SJ0PR14MB4348:EE_
X-MS-Exchange-Organization-AuthSource:
DM6NAM11FT073.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Office365-Filtering-Correlation-Id: ad44b508-5f1b-456d-1c8a-08db0dd087fa
X-MS-Exchange-Organization-SCL: -1
X-Microsoft-Antispam: BCL:0;
X-Forefront-Antispam-Report:
CIP:167.89.62.90;CTRY:US;LANG:en;SCL:-1;SRV:;IPV:NLI;SFV:SKN;H:xtrwpzrx.outbound-mail.sendgrid.net;PTR:xtrwpzrx.outbound-mail.sendgrid.net;CAT:NONE;SFS:;DIR:INB;
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2023 14:42:28.5294
(UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ad44b508-5f1b-456d-1c8a-08db0dd087fa
X-MS-Exchange-CrossTenant-Id: 1d9c0769-0601-4538-b2dc-e9946f6ea2e4
X-MS-Exchange-CrossTenant-AuthSource:
DM6NAM11FT073.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR14MB4348
X-MS-Exchange-Transport-EndToEndLatency: 00:00:04.4268647
X-MS-Exchange-Processed-By-BccFoldering: 15.20.6086.024
X-Microsoft-Antispam-Mailbox-Delivery:
ucf:0;jmr:0;auth:0;dest:I;ENG:(910001)(944506478)(944626604)(920097)(930097);
X-Microsoft-Antispam-Message-Info:
=?us-ascii?Q?wsOtcMILRtuC1L7D8ISxc66OaSrkZO0/mHhqvuC5f1rSvUBEoRCbZnc4BmKg?=
=?us-ascii?Q?BjFxZo0L23fm3ZEeAbWGvV9lh4U0y/oSJfLqeUR+hajL/lzzgZRYySt8BcKT?=
=?us-ascii?Q?+lPT0nwgmWjdBLmMXoda2do5W4605j/EC0carH2FqcZDFXoSVaMKN+gJUtCK?=
=?us-ascii?Q?x9FqlPwodInLUh0AuNc3E6LqzjL1Ft3cSgbZ82MNlXOrrdtrJbnVVEX2ae09?=
=?us-ascii?Q?wP9wmYjmRHG2kbffzjmNBMjlBfjLR2/hULAopoDUCqpHs8AUOMMoysKpSi0D?=
=?us-ascii?Q?P+6VwlfVCJrER1nXlgA2umT0U5+rxubCE5HiQh7DL53cHSUH4sJGelqvsV46?=
=?us-ascii?Q?+EdOPy6jddpLwsS4xVcimB/IGDqrXWCxuNP/FmpmJ5bsV2g3vgHheg+AtiaF?=
=?us-ascii?Q?IpBzocEo/mpid58jrHi/yeQz7nbp/A9pGh2grStbhD+VdcXEV3vQ83bIhLlA?=
=?us-ascii?Q?O2JzPsK/zj4nhg4EkFZfy71sh00aK7Tdzb9KCbxwS6AKMRkZzQkP3bN31QKg?=
=?us-ascii?Q?2s/8cMJCdj79K08UDQ4IF0hzt2nkdDAJGUrddByIOpcGD7SN4DsjU/ZsEN+w?=
=?us-ascii?Q?Jz+5Agf0ldKYFPyz280Hldlk4/s20IBzdupZwCoF8MNBFA3gvlbokUUHDMd8?=
=?us-ascii?Q?qrbBAc2WbO0ddY8pd7Gw82lKeZY4ELjQkvuiaijJmydlweF6vx6mh7Jh+sFr?=
=?us-ascii?Q?vhOZZ9C6cvH16NoN8bduNhm6QX0iTouSNRl1jDhw9gFxqr9J8DMw1MPWfzY+?=
=?us-ascii?Q?FXXxC8mqlEji90C8yhl3cdj+OsN3vLKOfI9pSh3Za88Kz7wdFWx8eOCODC2/?=
=?us-ascii?Q?8NkIObLbVS4EcUCNekUrWAQiDSHA1PhIXQj9EiLfxKtM5nO66awlxRJ8FmAa?=
=?us-ascii?Q?rAFINQ27UPbioPPJBfizycY3PKZEcUEvblRZqddb1Eh1M2VXAdRTM0fDR4NM?=
=?us-ascii?Q?5hT5TZYzEC8Bf6NiLM3CCZWn7hTt8VgR+2sx0EZ8xLYG4Xu7YHJYsw0imdRy?=
=?us-ascii?Q?AVtmAP9JrOVufS5fIuDNnKKYnHzIXZrc/Ohc+V29o3OLmF52TvrRxx+T8VPS?=
=?us-ascii?Q?R6OEJB1ZtBXMDFRQCDi2L06JResGRNw1x6So2wZM4kvv/ymn7RD0Afnwvmc7?=
=?us-ascii?Q?lVLpwsXymYht8eVpGhWGaax5yQfcVVXmY+D7o0FCciD3iWgvvV/la/yy1TaA?=
=?us-ascii?Q?oKmfpZ1CgO9tNZ2bblwtkTC2CCjf2KaLYsgC+Y2pGiACznC+LuyzJYxJY8B/?=
=?us-ascii?Q?mgbQMLgk2q8e1y/NCX1DmiIY4q8vTj1UlaqB563kRHLtYS10MUydcR59RaU7?=
=?us-ascii?Q?z0zhJwWMpR8ZbO8+aCOAu2Pg8Bh360fukVQIasrEcnxMlaDIpd4Vscyzf5dq?=
=?us-ascii?Q?sm9Ma7rix/GE26maGCPQr6nHD3/EAMa2qnbsQoelk228hBa1gglmH6IP/hNK?=
=?us-ascii?Q?1U19PW0awg5DDrzU5RLnEETUXIqUjLPZwDnUSgwXMo24Gp9/7qvjCGks/AmR?=
=?us-ascii?Q?sztlNe11hO2y/jeZlqjPNt4U+ph6E53UvNQdbz0p2Jyfx0jMjMCsOrZkbR4E?=
=?us-ascii?Q?dxyuvCl6HKd5IS2nx6L1P/iCCpg4bdo0s88/p67BfETlxk+B3rL8ehwGifP3?=
=?us-ascii?Q?2MdJh4hYScoFs0nTM6iyTxGbEzMNqqUyPagVNGuNEpcJLhoWSROrRJYCY5Aw?=
=?us-ascii?Q?UVroRMV28IFYfyFt8C7GfNEl46IbRu6hezzj3bo7VeABbw5QzpBGqL4S3+1q?=
=?us-ascii?Q?GQ2liLhDM2uyLfOChIdWc5UgRDGAxfkl2AZXy2LlVfvvg6pHiebSI8o7TqeH?=
=?us-ascii?Q?yLgNqpRDguiZ1SFOGHQoCKXHLIFzGgmNZrhtbcFCJ3X51dZfdEAIdR8hU/YR?=
=?us-ascii?Q?gUdHsgNqeQlP1M8QLzflVyes5ScwsRbkHCXuIXU=3D?=
Click to expand...
 
The sending IP, 167.89.62.90, is sendgrid.net so it'll pass things like SPF. If you run the header the start is at a loopback address which is what is typically seen when sending mass spams. The email doesn't really originate in a email client but rather a script interfacing with the SMTP server.
 
I'm not skilled at reading email headers, I think I might have been OK at it 20 years ago when things may have been a little simpler. I guess you did a search and replace for the actual domain and put in contoso.com ? Good idea. I've always been reluctant to paste email headers online when asking for help.

Anyway, I thought I'd ask ChatGPT. Here's what it said:

"This email was received by the recipient's email server from an email server hosted by Microsoft's Outlook.com service. The email appears to have been sent from an email address at the contoso.com domain, and it has a subject of "February 13th Notification".

The email's path can be traced back through the various servers that handled it, including the sender's email service at sendgrid.net, a spam filter run by Microsoft's Office 365 service, and the recipient's email server. The email includes a base64-encoded attachment named "eFAX.html", but the contents of the attachment are not included in the email header.

The email's SPF record indicates that the sender's IP address at 167.89.62.90 is authorized to send email on behalf of the sendgrid.net domain, which suggests that the email is not a spoofed message. However, the email's DMARC policy indicates that messages failing DMARC validation should be quarantined, and this message appears to have failed DMARC validation. It's possible that the recipient's email server may have marked the message as spam or moved it to a quarantine folder."
 
timeshifter said:
I'm not skilled at reading email headers, I think I might have been OK at it 20 years ago when things may have been a little simpler. I guess you did a search and replace for the actual domain and put in contoso.com ? Good idea. I've always been reluctant to paste email headers online when asking for help.

Anyway, I thought I'd ask ChatGPT. Here's what it said:

"This email was received by the recipient's email server from an email server hosted by Microsoft's Outlook.com service. The email appears to have been sent from an email address at the contoso.com domain, and it has a subject of "February 13th Notification".

The email's path can be traced back through the various servers that handled it, including the sender's email service at sendgrid.net, a spam filter run by Microsoft's Office 365 service, and the recipient's email server. The email includes a base64-encoded attachment named "eFAX.html", but the contents of the attachment are not included in the email header.

The email's SPF record indicates that the sender's IP address at 167.89.62.90 is authorized to send email on behalf of the sendgrid.net domain, which suggests that the email is not a spoofed message. However, the email's DMARC policy indicates that messages failing DMARC validation should be quarantined, and this message appears to have failed DMARC validation. It's possible that the recipient's email server may have marked the message as spam or moved it to a quarantine folder."
Click to expand...
Smart!
 
nlinecomputers said:
It's coming from Sendgrid not you and you can put a fake email address on anything. It gets through because the sendgrid is a validated source. It is why many places put banners on email that comes outside of the organization so that if it passes spam checks a human can still see something is wrong.
Click to expand...

My question is then ... Just so I can better understand how this works, if I wanted to do this, as in actually be the scammer in this scenario how would I go about doing it?

All I know how to do is legitimate way of registering a domain, mx records, etc.

I don't want to actually do this but I'm trying to understand how it can be done to better understand why this is happening.
 
thecomputerguy said:
My question is then ... Just so I can better understand how this works, if I wanted to do this, as in actually be the scammer in this scenario how would I go about doing it?

All I know how to do is legitimate way of registering a domain, mx records, etc.

I don't want to actually do this but I'm trying to understand how it can be done to better understand why this is happening.
Click to expand...
It's impossible to block 100% of spam without blocking legit emails. In this case the spammer somehow was able to leverage sendgrid.net which caused the SPF and DKIM tests to pass. What I don't understand is it appears that it passed SPF and DKIM, failed DMARC. The policy is to quarantine DMARC failures but didn't for some reason. That's assuming that email was not pulled from a spam folder.
 
I gave up trying to fix this tbo. They could make a rule though that anything from themselves goes to deleted but I email myself all the time so I don't forget to do things, it would not work lol.
 
I have a mail flow rule that says if it comes from anyone inside the company, and the mail comes from OUTSIDE the company, and it's not sourced from this list of email addresses that does this crap...

Right into the bit bucket.

Because source spoofing is a HUGE deal, and it causes massive headaches. Then again I also nuke any mail that has an executable attachment, a .zip attachment, and a .htm/.html attachment.
 
HCHTech said:
This type of spam is precisely why I added an Exchange rule to block emails marked as from members of a client's domain, but sent outside of the client's domain. I had a thread about it a few days ago.
Click to expand...
Can you link that post?
 
timeshifter said:
I'm not skilled at reading email headers, I think I might have been OK at it 20 years ago when things may have been a little simpler. I guess you did a search and replace for the actual domain and put in contoso.com ? Good idea. I've always been reluctant to paste email headers online when asking for help.

Anyway, I thought I'd ask ChatGPT. Here's what it said:

"This email was received by the recipient's email server from an email server hosted by Microsoft's Outlook.com service. The email appears to have been sent from an email address at the contoso.com domain, and it has a subject of "February 13th Notification".

The email's path can be traced back through the various servers that handled it, including the sender's email service at sendgrid.net, a spam filter run by Microsoft's Office 365 service, and the recipient's email server. The email includes a base64-encoded attachment named "eFAX.html", but the contents of the attachment are not included in the email header.

The email's SPF record indicates that the sender's IP address at 167.89.62.90 is authorized to send email on behalf of the sendgrid.net domain, which suggests that the email is not a spoofed message. However, the email's DMARC policy indicates that messages failing DMARC validation should be quarantined, and this message appears to have failed DMARC validation. It's possible that the recipient's email server may have marked the message as spam or moved it to a quarantine folder."
Click to expand...
No sure about others here but the very first things I'd do is put the attachment on virustotal.com
 
SPF and DKIM are only for the actual sender, it doesn't help for the FROM header. That's where the DMARC magic comes in and you see that DMARC has failed because it does check the FROM header.

In theory, I believe Exchange Online is supposed to treat a DMARC quarantine and a reject as the same thing and quarantine both, but I don't think that's what actually happens. I do think quarantine is not treated as harshly so I think you should set DMARC to reject, as long are you are certain that the company isn't legitimately sending emails failing DMARC anywhere.

Setting up some custom rules as mentioned by @HCHTech is a good idea too. If you used M365DSC you could define the standard rules you use and apply them to any of the tenants you manage.

The second thing though, is that I'm under the impression that SendGrid doesn't let people just choose whatever FROM header they want for the emails sent through them. The domain should be authorized for their platform and then you're only allowed to send from your authorized domains. So either there is some kind of exploit or there is an old SendGrid account authorized with their domain that has been compromised.
 
@trevm999 That is correct, Sendgrid does require you to jump through some substantial hoops before it'll let you send mail from a given domain. There's further hoops to fully integrate it into your SPF and DKIM records so you're fully DMARC compliant.

That being said, if you DID all that. There are some issues in the platform that can let other Sendgrid clients send as you from time to time... that's when things get hairy.
 
Sky-Knight said:
@trevm999 That is correct, Sendgrid does require you to jump through some substantial hoops before it'll let you send mail from a given domain. There's further hoops to fully integrate it into your SPF and DKIM records so you're fully DMARC compliant.

That being said, if you DID all that. There are some issues in the platform that can let other Sendgrid clients send as you from time to time... that's when things get hairy.
Click to expand...
Well, I'm not surprised. If I had a dollar for every time a developer turned an email functionality into an unintended relay I would be a rich man.

I've seen a phishing email training company allow any from address and it was a low enough priority security issue that it was many months before they fixed it. Email security just isn't taken seriously.
 
trevm999 said:
Well, I'm not surprised. If I had a dollar for every time a developer turned an email functionality into an unintended relay I would be a rich man.

I've seen a phishing email training company allow any from address and it was a low enough priority security issue that it was many months before they fixed it. Email security just isn't taken seriously.
Click to expand...
Even when it is, there's limited effect. The user can just have "the dumb" for a moment and everything is unraveled. The trick is to build a system where you can see and respond to the problem quickly, and get the user back to life as soon as possible.
 
HCHTech said:
Click to expand...

Tried this and it worked for a couple of emails because I had them sent to a internal member of the company for approval. Then we found out that one of their 3rd party services uses their own external mail servers to send mail like PO's to an internal user but coming from outside the organization, essentially ... spoofing our own emails so that the reply to is correct.

So it looks like

FROM: john@contoso.com
TO: john@contoso.com

Subject: Please approve the PO.

So this rule won't work. Now I better understand how this works too.
 
You must log in or register to reply here.
Back
Top