no, this is not a typo.
We just received multiple CEO Fraud attempts with our main xyz.de domain spoofed as xyz.dee!
Xyz.dee ist not even a real tld: https://data.iana.org/TLD/tlds-alpha-by-domain.txt
How (tf) can this mail pass the UTM mail protection? The .dee is in the envelope-from!
I shorted the mailheaders from the infos about our internal mailsystems and replaced domains and mailaddresses.
Received: from gateway10.unifiedlayer.com ([188.8.131.52]:57082)
by mail.xyz.de with esmtps (TLS1.2) tls TLS_ECDH_anon_WITH_AES_256_CBC_SHA
for email@example.com; Thu, 21 Apr 2022 16:17:26 +0200
Received: from cm1.websitewelcome.com (unknown [184.108.40.206])
by gateway10.unifiedlayer.com (Postfix) with ESMTP id B38AB2009A907
for <firstname.lastname@example.org>; Thu, 21 Apr 2022 09:17:19 -0500 (CDT)
Received: from shared99.accountservergroup.com ([220.127.116.11])
by cmsmtp with ESMTP
id hXcVnJVd2KPTUhXcVnFkBS; Thu, 21 Apr 2022 09:17:19 -0500
X-SASI-Hits: BODYTEXTP_SIZE_3000_LESS 0.000000,
BODYTEXTP_SIZE_400_LESS 0.000000, BODY_SIZE_1000_LESS 0.000000,
BODY_SIZE_2000_LESS 0.000000, BODY_SIZE_200_299 0.000000,
BODY_SIZE_5000_LESS 0.000000, BODY_SIZE_7000_LESS 0.000000,
DATE_TZ_NA 0.000000, FRAUD_LITTLE_BODY 2.000000,
FRAUD_WEBMAIL_R_NOT_F 0.100000, FROM_NAME_PHRASE 0.000000,
HTML_00_01 0.050000, HTML_00_10 0.050000, KNOWN_MTA_TFX 0.000000,
NO_CTA_URI_FOUND 0.000000, NO_URI_FOUND 0.000000, NO_URI_HTTPS 0.000000,
REPLYTO_FROM_DIFF_ADDY 0.100000, SENDER_NO_AUTH 0.000000,
SMALL_BODY 0.000000, SXL_IP_TFX_WM 0.000000,
TO_DOMAIN_IN_FROM_NOT_SAME 0.000000, WEBMAIL_REPLYTO_NOT_FROM 0.500000,
WEBMAIL_SOURCE 0.000000, WEBMAIL_XMAILER 0.000000, __BODY_NO_MAILTO 0.000000,
__CT 0.000000, __CTE 0.000000, __CT_TEXT_PLAIN 0.000000,
__FRAUD_ANTIABUSE 0.000000, __FRAUD_WEBMAIL 0.000000,
__FRAUD_WEBMAIL_REPLYTO 0.000000, __FROM_DOMAIN_NOT_IN_BODY 0.000000,
__FUR_HEADER 0.000000, __HAS_FROM 0.000000, __HAS_MSGID 0.000000,
__HAS_REPLYTO 0.000000, __HAS_X_MAILER 0.000000, __HAS_X_PRIORITY 0.000000,
__HEADER_ORDER_FROM 0.000000, __MIME_TEXT_ONLY 0.000000,
__MIME_TEXT_P 0.000000, __MIME_TEXT_P1 0.000000, __MIME_VERSION 0.000000,
__MSGID_32HEX 0.000000, __NO_HTML_TAG_RAW 0.000000,
__PHISH_SPEAR_STRUCTURE_1 0.000000, __PHISH_SPEAR_STRUCTURE_2 0.000000,
__RCPT_HOST_IN_FROM 0.000000, __REPLYTO_GMAIL 0.000000,
__REPLYTO_SAMEAS_FROM_NAME 0.000000, __SANE_MSGID 0.000000,
__TO_HOST_IN_FROM 0.000000, __TO_MALFORMED_2 0.000000, __TO_NO_NAME 0.000000,
X-SASI-Version: Antispam-Engine: 4.1.4, AntispamData: 2022.4.21.134824
Received: from [18.104.22.168] (port=38411 helo=cmdesignsolutions.ca)
by shared99.accountservergroup.com with esmtpa (Exim 4.93)
for email@example.com; Thu, 21 Apr 2022 09:17:19 -0500
Date: Thu, 21 Apr 2022 10:17:18 -0400
From: "CEO Name" <firstname.lastname@example.org>
Reply-To: CEO Name <email@example.com>
Subject: Dringende Anfrage_
X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version ]
Content-Type: text/plain; charset="iso-8859-1"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - shared99.accountservergroup.com
X-AntiAbuse: Original Domain - xyz.de
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xyz.dee
X-Source-Sender: (cmdesignsolutions.ca) [22.214.171.124]:38411
The UTM has no security method to detect this attack. Only Central Email can detect such spoofing attacks.
This is a joke, right?
I thought UTM mail protection switched to SASI with is used in Central Email?
Also, you do need to querie the domain to check for SPF records and stuff.So basically it should be possible to differentiate between a valid existing domain (no need for an SPF record thou..) and a response like "domain not found" for such an invalid domain / tld.
This is madness!
This feature was never implemented. If the Domain is non existing, the domain will have no valid features. SASI is a Antispam technology, not a protection feature. Like Cyren / commtouch is this feature never a part of such features.
The Email Server who delivered this email had a valid or non existing helo. Which is basically fine for the UTM. This was the technology for a long time in UTM.
You can activate the EHLO checks in UTM:
Reject invalid HELO/missing RDNS: Select this option if you want to reject hosts that send invalid HELO entries or lack RDNS entries. If you want to exempt hosts from this check, please refer to the Exceptions tab.
Do strict RDNS checks: Select this option if you want to additionally reject mail from hosts with invalid RDNS records. An RDNS record is invalid if the found hostname does not resolve back to the original IP address.
LuCar Toni said:If the Domain is non existing, the domain will have no valid features
I don't understand what you are trying to say.
RDNS has nothing to do with invalid sender domain, it just checks the dns / hostname of the given ip of the mta server resolves back. Besides it is of course enabled and set to strict.
LuCar Toni said:This feature was never implemented
Well...then you definetly should!An easy fix for "domain not found" when querying DNS for sender domain during SPF checks, which the UTM does.
Do you use Strict RDNS checks for HELO?
Sure?!? But RDNS and HELO has NOTHING to do with sender domain.
If this fraud Email was send by a legit Email Server, UTM has no detection system to notice, the domain is not existing.
Your best solution with UTM is Block TLD Email Senders.
Cheers - Bob
thank you for pointing me to this 7 year old thread!Unfortunately the proposed "solution" will both, void the warranty and not work, because basically you would need to block all "made up" tld's, which is infinite and therefore not applicable.
Obviously here was no improvement since then.It is also quite interesting, that protection for this kind of thread is not part of the XG Firewall, only Central Email as LuCar Toni pointed out.
Again, it should be possible to implement this in SASI, as SASI does check headers and therefore could also check the sender domain...
We will migrate to another solution for mailsecurity / antispam, already commissioned!Furthermore no need for a Sandstorm license anymore.
You also could use the trick proposed in https://community.sophos.com/utm-firewall/f/network-protection-firewall-nat-qos-ips/82589/block-top-level-domain-via-firewall/310945#310945