Phishing From Own Domain

From Roaring Penguin
Revision as of 17:08, 7 June 2018 by JohnMertz (talk | contribs)

Jump to: navigation, search

A common tactic for more advanced phishing techniques is for the spammer to identify key figures within an organization and spoof a conversation among them. The message will generally show up in the inbox of someone in the financial department - for instance, - and will appear to be from a trusted sender, say

Possible Spoofing Methods and Solutions
Envelope Sender Spoofed Envelope Sender Not Spoofed
Header From Address Spoofed SPF Record Recommended Rule
Header From Display Name Spoofed SPF Record Display Name Only
Header From Not Spoofed SPF Record Body Search
This chart shows a way to address each possible spoofing method. If the sender actually sends a message using your domain a proper SPF Record will always work. You can be very strict in our treatment of SPF failures. Otherwise, a custom rule can be used to manage messages that are cosmetically spoofed.

SPF Record

Maintaining a valid SPF Record is critical to ensuring that illegitimate senders are not able to send mail claiming to be from your domain. This is a DNS record that advertises what machines are allowed to deliver mail using your domain name.

As indicated by the table on the right. Simply maintaining a valid SPF Record protects you from any Spoofing attempt where the spammer actually uses your domain as the "Envelope Sender" address. This is the address that is given during the SMTP session and which is considered the actual sender address for routing purposes.

Because this record is consulted by every single recipient, it helps to protect both your own users and any of your contacts who might be fooled by a phony request claiming to be from you.

By default, CanIt provides 5 points for an SPF "Fail", which is provided if the machine is not listed in the SPF record and the record ends with "-all". This will automatically quarantine a message using our default thresholds and will cause us to ignore a whitelist. A lower score is used for a "Softfail" returned by "~all". We will not hold a message by default for hitting an SPF "Softfail" and no other rules, but it will cause us to ignore the whitelist. You may wish to use "Softfail" if you cannot guarantee the source list is complete.

Having discussed those default behaviours, you can also be more strict using CanIt's Rules->SPF Rules. This allows you to apply a different score per-domain for each result. If you are confident in your SPF Record being correct, you could (and probably should) be extremely strict for your own domain. Setting a Rules->SPF Rules entry for your domain that is equal to or greater than the Preferences->Quarantine Settings->S-100 setting will automatically place the message in the Spam quarantine where it can be search, but not released by end-users (but can be released by admins). Greater than or equal to S-200 will result in it being automatically discarded, in which case it will be in the logs, but will not be in any quarantine and will not be releasable by anyone.

Note: If you are confident in the SPF Record you could also provide a negative score for the "Pass" result which will effectively whitelist your domain when it does come from a valid source. We ignore any "Always Allow" actions defined in Rules->Senders or Rules->Domains when the sender has the same domain as the recipient (to prevent these exact types of attacks), so a large negative score for an SPF "Pass" is the simplest and safest way to whitelist your own domain.

Envelope Sender Not Spoofed

Only the "Envelope Sender" address is checked against the SPF Record. Spammers will often subvert SPF by only spoofing the "Header From" address - the one that users actually see in their mail reader. This address can say absolutely anything as it is part of the "Data" portion of the email and Mail Transfer Agents don't look at it as the authoritative source of the email.

There is already a rule in SpamAssassin that detects this behaviour (HEADER_FROM_DIFFERENT_DOMAINS) but we set it to have negligible effect on the score because of its huge potential to create false-positives. This is because it will be triggered by any source that delivers through a relay or that disguises it's true sender for good reasons as well. The score of this rule can be increased using Rules->Score Overrides, but a more specific rule is better. This rule is, however, a good indicator that a message has been spoofed so that better rules can be created.

So that you are aware of some reasons why the more complicated rules are necessary instead of the SpamAssassin rule, consider mailing lists. A mailing list will send using an "Envelope Sender" within it's own domain (because, for SMTP purposes, it is the genuine sender), but it will generally "spoof" the "Header From" so that the recipient sees the address of the mailing list respondent as the sender. This is also true for hosted newsletter providers like MailChimp and Constant Contact.

Header From Email Address is Spoofed

The "Header From" address has 2 parts. The "Display Name" and the actual email address. See this example:

  From: "Display Name" <>

CanIt will only recognize "" as the actual "Header From" address because of the way it indexes this information. For the purposes of our Custom Rules and Log Searching the 'From: "Display Name"' portion is not indexed and so it will not show up when searching the "Header From" fields. The following rules will address the cases where the actual email address is spoofed, but NOT if only the Display Name portion is. In other words, these rules apply if it is spoofed as follows:

 From: "Bob Smith" <>

The only part that is necessary for these rules to hit is that "" must actually be your domain.

General Rule (to cover multiple domains)

CAUTION: Please use caution with this rule, it should only be used if you are confident that none of the domains it applies to will have unexpected exceptions. The Recommended Rule below is much safer, but requires that you create it for every domain. You can add exceptions to this rule exactly as is discussed for the recommended rule, but these exceptions will apply to all domains served by the rule which is not likely to be sensible.

  • From the default stream of the top-level realm, navigate to Rules->Custom Rules (Compound Rules prior to version 10.1.0). Add the following (the percent and curly braces string should be taken literally):
Envelope Recipient Ends with %{domain_of_header_from} AND Envelope Recipient Does not end with %{domain_of_envelope_sender} 
  • Apply a small score, not more than your reject threshold (S-100), to future-proof against false-positives being completely rejected.

This is different from the HEADER_FROM_DIFFERENT_DOMAINS SpamAssassin rule mentioned at the top because it only applies to the recipient's own domain; it will not trigger if the sender is spoofing any domain except the exact one they are sending to, including aliases domains. It will, however, match sub-domains given that it uses the "Ends with" condition. This is mandatory, as there is no "Domain of Envelope Recipient" clause and so the rule must query the full recipient address.

Recommended Rule

  • From the default stream, navigate to Rules->Custom Rules (Compound Rules prior to version 10.1.0). Add a new Advanced Rule as follows (where is your own domain):
Domain of Header From is AND Domain of Envelope Sender is not
  • Apply enough points to get trapped.

These two conditions will cause the rule to hit all of the same messages as the the General Rule above for that specific domain. The reason that this is the recommended rule is that there may be some valid sources do actually spoof your domain for legitimate reasons. This is also why the HEADER_FROM_DIFFERENT_DOMAINS rule scores so low by default.

Possible cases where this rule could be a false-positive include:

  • Using a mass mailing service like Mailchimp or Constant Contact to send messages on behalf of your company to internal users.
  • External mailing lists that two or more internal users are members of when the one of the other internal users sends to the list.
  • Cloud services including Monitoring, Helpdesk/Ticketing, Invoicing, Website Contact forms, etc.

You can will need to add an additional clause for each of these sources that apply to the domain from the first two clauses. The exception clauses follows the same format as the second clause above, but should instead use the name of the sending domain that you would like to make the exception for. If that domain were '' it would look like this:

AND Domain of Envelope Sender is not

You can add as many exceptions as you like so long as you use that logic and replace '' with the actual sending domain.

Display Name Only

Note: The rules suggested below use the "Header" field, NOT the "Header From" field. They will not hit if you use "Header From" because that only searches the actual address claimed inside the < and > symbols.

As discussed in the Header From Email Address is Spoofed section. The above rules will only hit if the domain name used in the address string is from your domain. If you have an example like:

  From: "Bob Smith" <>

where "Bob Smith" is the name of someone within your company, the above rules will not hit. They will also not hit if they put your domain name in the "Display Name" portion, but a different address in the actual address field that is indexed:

  From: "" <>

Of all off the methods discussed yet, this is the least likely to trick users because if they read the whole line or if they tried to reply to the message, it will clearly state that it's not actually Bob. However, some mail readers will only show the Display Name. This is presumably in an effort to simplify the user interface, but it means that they have no way of knowing that the message is spoofed. Other mail readers will do something even worse which is to take something like these:

  From: "Bob Smith"[mailto:]

And display them as just:

  From: Your Friend

where the remaining detail is a hyperlink which will automatically open up a new email to "". Others will hide "", not provide a hyperlink, but will reply to that address if the recipient tries to do so.

With Email Address

While less common it is fairly easy to catch messages where the spammer is using your domain in the "Display Name" section, like so:

  From: "" <>

The following rule is almost exactly the same as the Recommended Rule above except that it searches the whole header "From:" line, rather than just the indexed email address:

  Header Matches RegExp From:[^@]* AND Domain of Envelope Sender is not

As with the recommended rule, you can add exceptions, but no legitimate sender should spoof messages in this way.

With Person's Name

The harder of the two "Display Name" spoofing methods to detect is where it is the person's name only that is being used. The only way to target this would be to write a rule to look for every internal user who might be spoofed. This may also include the need to match multiple variations of those names given that it could be spoofed as:

  • First Last
  • Last, First
  • F. Last
  • etc.

The more cases and the more vague you get, the more likely this rule is to hit false-positives, especially with common names. For example, trying to make this rule for "B. Smith" is risky as there are a lot of real people with that initial and surname. So, you will need to use caution with this rule depending on how likely you think those false positives will be. You can create these as individual rules like:

   Header Matches RegExp ^From:.*Bob Smith AND Domain of Envelope Sender is not

or you can address a whole bunch of names with one rule using the Regular Expression format of a pipe-separated list inside of brackets:

   Header Matches RegExp ^From:.*(Bob Smith|B. Smith|Smith, Bob|Jane Doe|J. Doe|Doe, Jane) AND Domain of Envelope Sender is not

This will hit if any one of the names listed in one of those blocks is found.

The most common false-positive with this will generally hit your own user's personal email addresses. For instance:

  From: "Bob Smith" <>

This rule will hit for the above, so if that address belongs to Bob and he emails something to his CanIt address, it get how ever many points you assign. You could write exemptions for this, but do not use the same format that was discussed above. Exempting all of "", for example would allow:

  From: "Bob Smith" <>

This is a real risk as all free email providers are common sources for phishing attacks.

Instead, the exemption would need to be address specific, such as adding the clause:

  AND Header From Is not

Body Search

The final way a message can be "Spoofed" is to simply use the person's name in the body of the message. This is almost impossible to catch safely, but it is also very unlikely to trick many users. The only defense against this would be to make a "Body" rule, but then no external sender would be allowed to mention that recipient either. Give that most user's don't trim their replies and most users include their names in their signatures, any user with such a rule would have pretty much every return message hit.

Spoofing From Other Domains

See Spoofed Addresses