10-16-2017 04:36 AM - edited 03-08-2019 07:26 PM
Hi together,
a few days ago, one of our board members got a message from an attacker, where the name (not sender adress) in FROM field was forged. It looks like the mail was from our CEO. The attacker requested a bank transfer.
Sender (SBRS: 2,7; popular mail provider) and mail was on the technical view fine. SPF and sender mail addresses were correct/pass, so the attack was not possible to detect by SPF rules or other features like antispam or reputation.
From: [NAME-OF-CEO] <something@popular-hoster.com>
To: [BOARD-MEMBER]
ASyncOS >10: Cisco Email Security appliance can detect fraudulent messages with forged sender address (From: header) and perform actions on such messages.
ASyncOS >10.0.3: Prior to this release, the name of the user and the user ID in the From: header of the message was used to detect forged messages. After you upgrade to this release, only the name of the user in the From: header of the message is used to detect forged messages. In the following example, only the name of the user (Jim Ross) is used to detect forged messages: Jim Ross <jimr@example.com>. If the message contains only the email address (jimr@example.com) in the From: header, the user ID (jimr) is used to detect forged messages.
If we setup CEO fraud detection by content filter (and setup the dictionary with our CEO), is this ESA feature capable to detect this? (>10.0.3 seems to be...)
What about lawful mails by other senders with this name, i.e. the person himself with his private mailaccount? (I think marking them as SUSPICOUS is better than dropping...)
Are both implementations (>10.0 and >10.0.3) are able to handle my described issue?
Are there any other techniques to detect this type of mails?
Thanks!
Solved! Go to Solution.
11-10-2017 12:54 AM
As no reply was possible to answer my questions (except Ken Stieers') and we have implemented the feature with ASyncOS 10.0.3, I will answer them if possible.
If we setup CEO fraud detection by content filter (and setup the dictionary with our CEO), is this ESA feature capable to detect this? (>10.0.3 seems to be...)
- Yes, of course, it will. If no name is provided, ESA will take the user ID portion (everything before the “@”; as described in release notes).
What about lawful mails by other senders with this name, i.e. the person himself with his private mailaccount? (I think marking them as SUSPICOUS is better than dropping...)
- They will detected to. Also similarity looking senders are able to detect. The default value 70 was to low and generated lots of false-positives. We will setup a value greater than 90.
Are both implementations (>10.0 and >10.0.3) are able to handle my described issue?
- We implemented FED when update to 10.0.3 was proceeded.
Are there any other techniques to detect this type of mails?
- Ok, it looks like only FED is able to catch the name partition in FROM. The others described implementations in this thread are looking for the domain in the mail portition - this we handle with SPF.
Thanks together!
10-16-2017 05:10 AM
Hello,
we have the folowing MessageFilter implemented:
if (recv-listener == "INCOMING-LIS") {
if header("from" =="InternalDomain"{
log-entry("Mail with internal Domain at 'from'");
edit-header-text("Subject", "(.*)", "[FORGED EMAIL] \\1");
insert-header("X-IronPort-Quarantine", "Yes");
}
}
this Filter moves all "FORGED EMAIL" to the User Quarantine
10-16-2017 05:23 AM
Hello tfrenz,
thanks for your answer.
This setup will remove or quarantine all mails from other providers and services, which sends mails in your (domain-)name from other hosts than your ESA. Is this correct? We have a lot of legitimate mails like this.
Also, this setup will catch your domain names, but not the names of executives in your company. In our case, forging our domain is not the problem (this we are handling by SPF), but the sender name (not mail) is forged.
11-09-2017 10:14 AM
You need control of your own domain - if you don't have that, then if any [genitalia] can send as your organisation, they will. You already have SPF set up - a good tough HARDFAIL terminating clause, I trust?
These steps aren't easy to do; they involve a lot of initial failures as your recipients learn what they can and cannot do, and the concept may be impossible for some organisations.
That then makes the following possible:
Spoof-From:
if ((sendergroup != 'RELAYLIST') AND (sendergroup != 'EXTERNALLIST')) {
if header('From') {
if header('From') == '@({domain1.tld}|{domain2.tld})' {
strip-header('Subject');
insert-header('Subject', '[NOT {company} SENDER] $Subject');
insert-header('X-TAG-Query-Sender', 'Impersonates {company} equipment');
skip-filters();
}
}
else {
strip-header('Subject');
insert-header('Subject', '[NO FROM] $Subject');
insert-header('X-TAG-Query-Sender', 'No From header');
skip-filters();
}
}
.
Here {domain1.tld} and {domain.tld} are your domains you are protecting, {company} is the name of your organisation and TAG is whatever you put in your own headers to make them unique. RELAYLIST is your sender group of your own servers and EXTERNALLIST is a new sender group for the very few outside machines that are allowed to use your domain. Yes, this will break some things but see my opening sentence.
This filter tags the mail and changes the subject line, but doesn't take any other action. The message is still in your pipeline and a subsequent content rule can take action, possibly in conjunction with other conditions.
I haven't used FED, but I believe it can be used to protect specific recipients in your domain so if you have a shortlist of recipients authorised to do silly things with your organisation's bank account, you can set it up just for them and not for your other recipients with an urgent need to receive mail from any [improvised sanitation] start-up who think they have a deity-granted right to impersonate them. We can only hope that your two groups of recipients don't overlap. Personally I prefer my solution, but it's only fair to point out that it does struggle with calendar responses that run around with the wrong From lines. However, I think that's a general problem - anyone know was it ever cleared up for bounce verification?
10-16-2017 06:42 AM
10-26-2017 09:15 AM
We have implemented our custom filters to assist end users with this challenge.
In short we do the following :
If
not Whitelisted application or host
not OwnGroupDomains as sender
not any of 3500 public mailers
if SPF, SBRS, DKIM fail or reputation low
duplicate mail to quarantine for savekeeping for 14 days
keep original from in x-header
keep original reply-to in x-header
strip headers from and reply to
insert notification to end user that header was stripped
This saved our life so many times....in the last weeks/months. Initially users did complain about all those emails from bounces but have accepted it now ( > 40000 users)
We are currently working on regex based VIP detection filter in addition to the above to check for any VIP combination or fake domains.
11-10-2017 12:54 AM
As no reply was possible to answer my questions (except Ken Stieers') and we have implemented the feature with ASyncOS 10.0.3, I will answer them if possible.
If we setup CEO fraud detection by content filter (and setup the dictionary with our CEO), is this ESA feature capable to detect this? (>10.0.3 seems to be...)
- Yes, of course, it will. If no name is provided, ESA will take the user ID portion (everything before the “@”; as described in release notes).
What about lawful mails by other senders with this name, i.e. the person himself with his private mailaccount? (I think marking them as SUSPICOUS is better than dropping...)
- They will detected to. Also similarity looking senders are able to detect. The default value 70 was to low and generated lots of false-positives. We will setup a value greater than 90.
Are both implementations (>10.0 and >10.0.3) are able to handle my described issue?
- We implemented FED when update to 10.0.3 was proceeded.
Are there any other techniques to detect this type of mails?
- Ok, it looks like only FED is able to catch the name partition in FROM. The others described implementations in this thread are looking for the domain in the mail portition - this we handle with SPF.
Thanks together!
05-30-2018 04:50 AM
For a few weeks, we receive mails with malware links and spoofed addresses that look like sent from an internal employee (but the domain is not ours of course).
In order to use FED with Ironport, we implemented this:
1: create 2 directories of all mail users (one First Name Last Name, the second one vice versa, i.e. Last Name First Name)
2: create rule with FED, set threshold to 90 (default 70 is too low). Send those mails to quarantine only when reputation score is also below 1.5. This is necessary because many internal users send mails from home addresses to their business mail (Gmail, Hotmail etc.). Unfortunately we have no company policy forbidding this behavior, so we need this workaround.
Works quite well so far, of course not perfect.
09-23-2020 07:27 AM
The FED in ESA running 13.5.2-033 AsyncOS version, checks the display name portion only and doesn't consider the email portion of the From: header.
I created an enhancement request, that the ESA must consider/check the Display name portion as well as the email address part in the From: header and then provide a final matching score.
Here is the EHN: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvv80043
But this will not reduce the false positives, when the users send e-mail from their private e-mail address to their business e-mail addresses.
Hope this helps.
Cheers,
Prab
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide