Jump to content

How to deal with display name spoofing, when contains right mailadress also in reply, but "name@abc.com" is different


Recommended Posts

How can this be handled? or maked as spam? 
Such mails currently occur more frequently and the attachments are packed. Inside are Office Docs with nasty macros, which are mostly not recognized.... SPF Checks and DKIM is all OK 

From: "known.customer@trusteddomain.com" <evil@nasty.com>
Date: Wed, dd Sep 2020 hh:mm:ss +0000
To: mymailbox@mydomain.com
Subject: knownsubject
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Content-Type: multipart/mixed; boundary=067204a8992001fcc2d3323ef782a184
Message-ID: <xyz@mail01.mydomain.local>
Return-Path: evil@nasty.com
X-MS-Exchange-Organization-Network-Message-Id: 788513ff-5f7a-4da7-0e08-08d85faede96
X-ESET-AS: R=OK;S=0;OP=CALC;TIME=1600858394;VERSION=7861;MC=3420289152;TRN=2002;CRV=0;IPC=xxx.xxx.xxx.xxx;SP=0;SIPS=3;PI=3;F=0
X-ESET-Antispam: OK
X-EsetResult: clean, is OK
X-EsetId: 37303A29237BEC6B6D7C62
X-MS-Exchange-Organization-AuthSource: mail01.mydomain.local
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Transport-EndToEndLatency: 00:00:01.4010310
X-MS-Exchange-Processed-By-BccFoldering: 15.01.1847.009
 

Edited by raimund
Link to post
Share on other sites
  • ESET Staff

Hi,

have you tried using custom rules with the combinations of conditions

From header - address

From header - display name?

You can also have all macro-enabled office documents quarantined, using the Attachment type condition.

Link to post
Share on other sites

Hi!

I tried to use custom rules, but I was not able to combine the two From Headers, or to compare/differentiate (params), or I failed in the implementation.

Quarantining Macro enabled Docs is clear to me, but does not solve the special problem of spoofing...
also having a rule which checks for macros, but this macro was in office doc which was zipped...

How can I build such a rule? The conditions are AND conditions... and how params should used?

Edited by raimund
Link to post
Share on other sites

Unless you use Office macros internally, they should be permanently disabled or restricted via Group Policy: https://4sysops.com/archives/restricting-or-blocking-office-2016-2019-macros-with-group-policy/ . Optionally, Internet-based based only macros can be disabled:

Quote

Do not run macros from the internet ^

A new addition to Office 2016 is the ability to block only code in documents that originate from the internet. You can configure it separately for each application and can also find it under Security > Trust Center ("Block macros from running in Office files from the Internet").

 

Edited by itman
Link to post
Share on other sites
11 minutes ago, itman said:

perfekt article.... thank you

but what in case of this... SPF+DKIM Checks are OK

From: "known.customer@customersdomain.com" <evil@nasty.com>
Return-Path: evil@nasty.com

?

both sender are outside my network, but the one under the "" is my customer, the <> is the problem.
you know outlook, the problem is the user, which believe this mail is will not be harmful, because it was sent by the customer, but at this time it's too late... blocking the nasty.com after receiving is too late.

maybe next time mails came from: "antoher.customer@theirdomain.com" <bad@sender.com>

Link to post
Share on other sites
  • ESET Staff

Hi raimund,

Attachment type rules are evaluated on all files in archives - zipped document with macro will be caught by the rule (unless it's password protected).

Rules support only comparing of static strings so it is not possible to compare From: and Return-Path: headers. Not a perfect solution, but something like this should do the job:

From Header - display name contains one of [@customer1.com, @customer2.com]
Message headers do not match regular expression "\nReply-To: .*(@customer1.com|customer2.com)"

Link to post
Share on other sites
  • 3 weeks later...

 

On 9/25/2020 at 10:14 AM, filips said:

Hi raimund,

Attachment type rules are evaluated on all files in archives - zipped document with macro will be caught by the rule (unless it's password protected).

Rules support only comparing of static strings so it is not possible to compare From: and Return-Path: headers. Not a perfect solution, but something like this should do the job:

From Header - display name contains one of [@customer1.com, @customer2.com]
Message headers do not match regular expression "\nReply-To: .*(@customer1.com|customer2.com)"

Excuse me, but that's not very useful. What if the spammer/spoofer uses a different email every day? We can't simply add manually rules everyday, or add all the domains we interact with to different rules.

I've exactly the same problem as raimund. Malicious attachments undetected by ESET and many other vendors (they get detected after few days), with the from address spoofed (reply-to is another address, similar to the spoofed one).

Isn't there anything else that can be done? I've already configured rules to quarantine all emails with macros-enabled attachments, but I got one today that contains a malicious Excel in xls format, not xlsm. It's not possible to simply quarantine all emails that include a xls file

Link to post
Share on other sites
  • Administrators
1 hour ago, mlltech said:

I've exactly the same problem as raimund. Malicious attachments undetected by ESET and many other vendors (they get detected after few days), with the from address spoofed (reply-to is another address, similar to the spoofed one).

Please provide us with more information about the malware that goes undetected through ESET. Is it executables? Office documents? HTML files or some other kind of files? Have you considered trying out ESET Dynamic Threat Defense for automated replication of received files in ESET's cloud sandbox?

As for the other queries, I'll leave them to @filipsor @M.K. to respond.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...