Block spoofing emails

We are using UTM as our mail gateway, lately, a lot of our users have received spoofing emails that appear from themself.

We use emailspooftest dotcom site to test our mail servers, and it detects the problem was 

Internal authentication is not enforced.

Fix: On inbound email gateways, only allow specific IP addresses to send mail from internal domains or force an auth challenge for internal domains. This is typically a relay setting.

Could anyone suggest how to fix this problem in Sophos? 

Parents
  • Hi,

    I recommend setting SPF-records for your domain and enabling "Perfom SPF check" in SMTP->Antispam.

    bye Josef

    BERGMANN engineering & consulting GmbH, Wien/Austria

  • Hi Josef, thank you for your reply. 

    SPF is always enabled and records are update-to-date, this seems to be an open relay problem in UTM.

  • Good morning, Johnny.  You got the answer from both Dirk and Josef.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Apologies for the late reply.

    Unfortunately, the solutions proposed didn't work, we updated SPF to "hard fail" but it still doesn't stop the phishing emails.

    Here is the email header looks like -

    Received: from EX2016-MDB-AN.xxx.hosted (10.2.4.129) by
     EX2016-MDB-AN.xxx.hosted (10.2.4.129) with Microsoft SMTP Server
     (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.8
     via Mailbox Transport; Wed, 20 Jul 2022 14:15:40 +1000
    Received: from EX2016-MDB-AN.xxx.hosted (10.2.4.129) by
     EX2016-MDB-AN.xxx.hosted (10.2.4.129) with Microsoft SMTP Server
     (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
     15.1.2308.8; Wed, 20 Jul 2022 14:15:40 +1000
    Received: from ip-10-2-3-109.ap-xxxx.compute.internal (10.2.5.109) by
     EX2016-MDB-AN.xxx.hosted (10.2.4.129) with Microsoft SMTP Server
     (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.8
     via Frontend Transport; Wed, 20 Jul 2022 14:15:40 +1000
    Received: from [10.2.4.120] (helo=mail.xxx.com)
    	by ip-10-2-3-109.ap-southeast-2.compute.internal with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
    	(Exim 4.90_1)
    	(envelope-from <user@xxx.com>)
    	id 1oE17c-0004qV-OG
    	for user@xxx.com; Wed, 20 Jul 2022 14:15:40 +1000
    Received: from [185.222.58.69] (port=62467 helo=xxx.com)
    	by mail.xxx.com with esmtp (Exim 4.95)
    	(envelope-from <user@xxx.com>)
    	id 1oE17W-0001WW-0x
    	for user@xxx.com;
    	Wed, 20 Jul 2022 14:15:34 +1000
    From: xxx.com Server <user@xxx.com>
    To: <user@xxx.com>
    Subject: Three (4) Incoming mails not delivered
    Date: Wed, 20 Jul 2022 06:15:30 +0200
    Message-ID: <20220720061530.C5379167367D62FD@xxx.com>
    MIME-Version: 1.0
    Content-Type: text/html; charset="iso-8859-1"
    Content-Transfer-Encoding: quoted-printable
    Return-Path: user@xxx.com
    X-MS-Exchange-Organization-Network-Message-Id: e0bd540b-123e-4816-8107-08da6a0681e5
    X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
    X-MS-Exchange-Organization-AuthSource: EX2016-MDB-AN.xxx.hosted
    X-MS-Exchange-Organization-AuthAs: Anonymous
    X-MS-Exchange-Transport-EndToEndLatency: 00:00:00.1880204
    X-MS-Exchange-Processed-By-BccFoldering: 15.01.2308.008

    Received: from [185.222.58.69] (port=62467 helo=xxx.com)
    by mail.xxx.com with esmtp (Exim 4.95)
    (envelope-from <user@xxx.com>)
    id 1oE17W-0001WW-0x
    for user@xxx.com;
    Wed, 20 Jul 2022 14:15:34 +1000

    The first "Received: from [185.222.58.69]" is not in the SPF record, yet it is the IP that the email originated from.

  • Hi,

    send me a PM with the real log.

    bye Josef

    BERGMANN engineering & consulting GmbH, Wien/Austria

  • Josef will help you.  The line we would need to see is the one where the SMTP Proxy receives the email.  That line would be above those you posted.

         Received: from mail-dm6nam10on2109.outbound.protection.outlook.com ([40.107.93.109]:27105 helo=NAM10-DM6-obe.outbound.protection.outlook.com)
             by xxxxx.mediasoftusa.com with esmtps

    The above came from a client at a company that hosts their email with outlook.  40.107.93.109 is included in the SPF record for spf.protection.outlook.com.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Thank you all, I have sent a pm to Josef.

    We received another phishing attack, the attacker managed to pass the SPF check

     Authentication-Results: wps01.wadax.ne.jp;
    spf=pass (sender IP is 18.119.141.193) smtp.mailfrom=abc@xxx.com smtp.helo=[127.0.0.1]
    Received-SPF: pass (wps01.wadax.ne.jp: connection is authenticated)

    I have no idea how they could they do that? the IP is probably in one of these includes

    include:spf.messagelabs.com include:spf.protection.outlook.com include:spf.smtp2go.com

  • Phishing attacks are rarely stopped by SPF.  Most are done with an account that was hijacked or from a new account at an email provider like Gmail - Google seems to be the email of choice for online criminals.  The best defense against phishing is anti-phishing training for your organization, like Sophos Phish Threat.

    Note that that the content of the From field in an email can be spoofed instead of being the same as the Sender.  This is likely what happened to your coworkers as described in your opening post in this thread.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Thanks Bob, appreciate your reply.

    My understanding is that the From field in an email can be spoofed, but that will make it different to the Return-Path field, therefore, SPF comes into play.

    In our case, the  From field and the Return-Path field are the same address, and the SPF check was passed -

    Authentication-Results: wps01.wadax.ne.jp;
    spf=pass (sender IP is 18.119.141.193) smtp.mailfrom=abc@xxx.com smtp.helo=[127.0.0.1]
    Received-SPF: pass (wps01.wadax.ne.jp: connection is authenticated)

    This makes me think about why Sophos could let the email through, and how did the scammer manage to pass the SPF check.

  • The SPF record for wps01.wadax.ne.jp uses ~all instead of -all, Johnny, so SPF is not enforced for that domain.

    I think we all read past the spot where you set your SPF to hard fail several days ago - that only affects how others treat mail from your domain.

    Have you sent Josef the full log?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • UTM does not have tools to prevents such attacks. Only Central Email can deal with such BECs (business email compromise) attacks. 

    Also see: ai.sophos.com/.../

    __________________________________________________________________________________________________________________

  • Hi Johnny,

    I've sent you the result of my investigation befor 2 days. Check the exceptions...

    bye Josef

    BERGMANN engineering & consulting GmbH, Wien/Austria

Reply Children
No Data