Bypassing employee name spoofing protection in Gmail

Brian Kim
3 min readOct 10, 2021

Google’s Advanced Phishing and Malware protection settings, introduced in 2019, allows administrators to display warning banner in Gmail, mark the messages as spam, or put messages in admin quarantine when users receive messages with potentially malicious attachments, unsafe links, or messages that are spoofed.

One setting in particular, Protect against spoofing of employee names, is useful against emails coming from external senders that are pretending to be one of your users. A common scenario is a gift card scam involving spoofing of CEO’s name. While enabling the protection setting with a warning banner could have prevented this from happening, it is only shown in Gmail which is one of the reasons why use of IMAP should be discouraged.

Warning Banner in Gmail
Warning Banner in Gmail

For organizations that continue to allow use of IMAP, a commonly selected action against display name spoofing is Quarantine, which requires an administrator to monitor the quarantine for any false positives.

An often asked question is whether an admin can create an allowlist to bypass this setting especially for messages sent from User Name <noreply@vendor.com>. While there is no way to do it in Admin Console, there is a workaround that has been tested, which is why I highlighted users in the opening paragraph.

Although Google Support will neither confirm nor deny this, below is an oversimplified diagram of how display name spoofing protection works.

Flowchart — Display Name Spoofing Protection in Gmail
Display Name Spoofing Protection

All the advanced phishing and malware protection settings are specific to individual users. When an email is sent to the user, Google will check if the name exists in the directory (excluding external contacts) and whether the email address exists in the user’s contacts (saved by the user and automatically saved by Gmail).

EDIT: Seems like Google now also looks at external email addresses in Global Address List, which you can update using Domain Shared Contacts API.

https://www.youtube.com/watch?v=ICCwDiEuzjU

Untrusted senders are senders with no prior history with the recipient, or that have a low sender reputation.

Therefore, in order to bypass this protection setting, all you need to do is to create a contact using the sender’s email address that is triggering the action for the specific user that received the message, regardless of what the action may be (i.e. you are marking the sender as trusted by creating a contact). I have also confirmed that deleting the contact does not cause the warning banner to come back, but it may eventually if the sender’s reputation changes due to Gmail’s Machine Learning model.

A couple of other tools that may be useful to handle this is with more granular control (e.g. set this up for only for names of CxO that are commonly spoofed excluding any emails sent from known safe personal email addresses) are Investigation Tool (Enterprise Plus required) or Content Compliance rule using a regular expression.

Cautionary Tale

Google automatically saves contacts when you send an email. As an attacker, you can compromise a user’s account (which is why 2-step verification is paramount) and insert an external email address into a thread with multiple recipients who would then reply all. I have seen this exploit where a fake invoice was processed. Google has since then introduced a label to visually indicate if there is an external recipient, which would make this more difficult today with some user education.

Google has also recently deprecated Contacts API and replaced it with People API. Other contacts that are saved to https://contacts.google.com/other are read-only by the new API, and it is likely to stay that way. Furthermore, People API cannot yet be restricted by an admin in https://admin.google.com/ac/owl, which may leave some room for sophisticated phishing/spoofing through OAuth.

Update: looks like restricting access to Contacts service restricts access to both Contacts and People API.

API Access Request Denied
API Access Restricted

--

--

Brian Kim

Brian is a Google-certified Collaboration and Security Engineer. You can find him hanging out in SaaSOps or MacAdmins Slack