Google-workspace – How to Set Up Specific Anti-Phishing Rules in G Suite

emailgoogle-workspacephishing

G Suite admins have the ability to make G Suite go harder on phishing attacks in an organization by ticking some checkboxes here and there, but there doesn't seem to be an ability to check incoming phishing emails and set specific rules for them based on content.

The issue is that phishers are targeting my client's organization by getting some random Gmail or AOL address and setting their "From:" name as the CEO's, or main administrator's name, or other high-ranking people in the business. I've set G Suite's rules to be as hard on phishing as possible, but these emails keep coming through the filters using the same predictable tactics.

Each time one of these emails gets through, we add the email to a block list for the organization, but the attackers just open a new account and try again.

What would take care of would be if I could set up rules that say something along the lines of:

If ( email.from_name == "Jim Smith" && email.address !== jim@example.com ) {
  email.reject
}

In non-pseudo-code, if the email header says that they are a name in the organization, but the email is coming from outside the organization, reject it.

I followed this article's steps to prevent this, though it doesn't seem to be working.

According to the article, this can be done by going through the following steps:

  1. Go to admin.google.com
  2. Go to Apps > G Suite > Gmail > Advanced
  3. Scroll to Content Compliance and add a new rule
  4. Check "Inbound" for "Email messages to affect"
  5. Under "Add expressions that describe…", select "If ALL of the following match the message"
  6. Add expression rule "Advanced Content Match", Location = "Sender Header", Match Type = "Not contains text", content = "jim@example.com"
  7. Add expression rule "Advanced Content Match", Location = "Sender Header", Match Type = "Contains text", content = "Jim Smith"
  8. Click "Save"
  9. For "If the above expressions match…", select "Reject Message"
  10. Under "Show Options", select all options for "Account types to affect", being "Users", "Groups", and "Unrecognized / Catch-all"
  11. Hit "Save" in the bottom-right

That's what I put for this organization, though these emails are still getting through, so I'm either doing something wrong in this implementation or this doesn't work for some reason.

I'm almost surprised this anti-impersonation measure isn't a default, but I guess they don't want to screen too many false positives where people try to contact an organization and they happen to have the same name as the CEO. In this case though, the CEO doesn't have a very common name and way too many of these phishing attacks are happening, so it would definitely be worth implementing this if possible.

Best Answer

The issue with your Content Compliance rule is you were picking the wrong locations. I also needed to accomplish this, and tried exactly what you did and got the same results - it didn't work. So I checked out Google's Content Compliance doc, and noticed this under "Advanced content match location":

Sender header: The sender header consists of the email address, located within the angle brackets, and does not include the account name

That's why it wasn't working! The sender header was never going to contain "Jim Smith"

The correct formulation for doing this is:

  1. Check "Inbound" for "Messages to affect"
  2. Under "Add expressions that describe...", select "If ALL of the following match the message"
  3. Add expression rule "Advanced Content Match", Location = "Envelope sender", Match Type = "Not contains text", content = "jim@example.com"
  4. Add expression rule "Advanced Content Match", Location = "Full headers", Match Type = "Contains text", content = "Jim Smith"

I also changed the first rule to check "Envelope Sender" because, according to Google, this is "The original sender that was reported during the SMTP communication request. It can be different from the sender reported in the Sender header. It often, but not always, matches the address found in the “Return-path” header." That location seemed more likely to never be the address we're looking for.

I tested this by creating a ProtonMail account using our CEO's name as the display name, and it was immediately quarantined by this rule.

I hope this helps!

Related Topic