How Confident Should You Be About Google Confidential Mode?

Google recently released a variety of security features to enhance, among other things, the user experience within Gmail (note that I use Gmail and not G Suite; this will become an important distinction). While many of these features were good steps for Google, one particular “security” feature has been met with heightened scrutiny from the security community. This feature is the ability to send “confidential” messages. Beyond the limitations and shortcomings of the confidential messaging features being discussed amongst concerned users, the feature has now caught the attention of the Department of Homeland Security.

Conceptually, the confidential messaging feature provides a method to send certain messages more securely within Gmail. End users can set expiration dates on messages, require SMS authentication before messages can be read, and messages are sent with the knowledge that the message cannot be printed or forwarded. Aside from the debate around how novel the methodology is, the means by which these messages are sent raises questions about how secure they truly are. Namely, how ripe are confidential messages for spoofing attempts?

Two scenarios come to mind. When a G Suite user sends a confidential message to another G Suite user, the recipient views the content directly in Gmail without needing to go to a secondary webpage. Under this scenario, the message never truly leaves the Google ecosystem (confidential messages always reside on Google servers). That said, nothing is preventing a confidential message from including malicious content such as a nefarious URL or attachment.

The second scenario deals with non-Gmail recipients, or Gmail users accessing mail in a client other than the Gmail client. Upon receiving a confidential message under one of these scenarios, the user is brought to a webpage where they are prompted to enter their Google credentials. The same condition holds true of the above regarding malicious content, but attackers can also seamlessly impersonate this workflow to steal credentials.

Under both scenarios, an attacker is exploiting user trust: not only is the user receiving a message in his or her inbox, but it is being sent “confidentially.” These types of tactics have been used for years as a way to engender trust between sender and recipient, but now Google has programmatically introduced a heightened level of trust seemingly without the means to prevent the feature from being exploited for nefarious purposes.

And as previously mentioned, the G Suite versus Gmail distinction is key: the confidential messaging feature is available and functions in the same fashion in both the free version as well as the paid G Suite platform. In other words, attackers can register Gmail accounts for free, set their display name to that of a business contact known to the recipient, and send these confidential messages as if they are the stated sender.

So how concerned should you be? From a professional perspective, the answer is, “it depends.” As a natural part of security awareness training, you are likely already emphasizing to your users that clicking on unexpected links is a bad practice. Unfortunately, training and real-world habits are often worlds apart.

If the notification of a confidential message is itself being spoofed, then your email security solution will treat it the same way that it treats other business service impersonation and credential theft attempts. When it comes to legitimate confidential messages being sent for potentially nefarious means, however, we open up a whole other can of worms. We recommend checking with your email security provider about this scenario in particular to understand how it addresses this scenario.

For our customers, they can rest assured knowing that GreatHorn is able to address both of the above scenarios. GreatHorn’s email security platform relies on anomaly detection based on deep relationship analytics and adaptive user / organizational profiling. Regardless of the intent, GreatHorn is still able to, among other things:

  • Gauge the relationship or lack thereof between senders and recipients;
  • Whether or not the specific address being used has been seen before; and
  • Scrutinize other key information about the sender

All of this is possible even when confidential messaging is being used.

In situations where Google’s confidential messaging is being impersonated, GreatHorn will analyze all of the above characteristics to gauge whether or not it is a legitimate confidential message as well as determine if the URL in the message is unusual or malicious.

Are you excited or concerned about Google’s new feature? Give us your view by commenting on the blog below.

The Google Docs Phishing Attack

Google Docs Is Fine, Right?

Earlier today, a major and sophisticated attack was levied against email users.

Unlike many commonplace phishing attempts, this attack cleverly used an imposter application to compromise mailboxes and accounts, by way of Google’s own OAuth framework. It was not an imposter email, user, domain, or the like — it was a real application that happened to be written in such a way as to look like a Google Docs application.

This is perhaps one of the most sophisticated phishing attacks we have seen to date.

Malicious cloud applications are almost impossible for an ordinary user to detect; by clicking on the “Allow” button, users are giving that application permission to operate on their behalf, both reading and sending mail from their inboxes. No credentials are stolen or exchanged; multi-factor authentication is of no help here.

There is a robust write-up on Reddit with additional technical details, as well.

How To Respond

First and foremost, the obvious: don’t click.

If you’re already running GreatHorn Inbound Email Security, you are also fully protected:

  1. GreatHorn automatically created a policy for every GreatHorn account today that detected and quarantined all instances of this attack from the time of detection onwards; no user action or administrative work was required here.
  2. Additionally, GreatHorn automatically detected and either quarantined or deleted every copy of the attack message, post delivery.

Unlike a traditional email gateway, GreatHorn’s cloud-native capabilities provide unique remediation capabilities, and can reduce incident response from hours to seconds — and as with the policy, this required no user action or administrative effort.

What’s Next?

One of our core beliefs is that advanced threats will not be limited to the phishing techniques seen today. Attackers are capable of building sophisticated, multi-step, and nearly impossible-to-spot threats that traditional email-only security tools and gateways cannot block.

Not only can we expect to see threats over email that defy legacy security tools, but we also expect to see an increasing number of attacks over secondary messaging platforms. Deploying this type of attack over a chat platform (like Slack) would be as effective as doing so over email — and no email-only security tool could detect or stop it.

GreatHorn is designed to uniquely provide detection capabilities for these additional platforms, with response capabilities tailored to deal with the threats of third party applications that leverage OAuth-based permission attacks.

As today’s attack demonstrates, protecting against social engineering and phishing attacks requires automated, comprehensive, and post-delivery response capabilities. Built on a foundation of over half a billion analyzed messages and leveraging the first and only cloud-native response platform, both Inbound Email Security and Messaging Security are available today, and both offer free 7-day trials.

GreatHorn automatically detects and removes phishing attacks from your inbox. 

Begin a trial or to request more information about Inbound Email Security for G Suite.

Unpacking the “Undetectable Hack”

How GreatHorn Can Stop the Latest Gmail Phishing Attack

Over the past week, a significant amount of digital ink has been spilled about a new form of phishing attack: an embedded GMail image that leads to a fake login page. 

Media coverage has skewed heavily breathless, and articles on the subject are peppered with scary terms like “frightening,” “really devious,” and “almost impossible to stop.”  Admittedly, this is quite a convincing attack.

It begins with an email sent from an already-compromised Google account to another Google Apps / G Suite / GMail user. The email contains a (fake) attachment that’s been made to look like a common document type (Word, PDF, etc.). The “attachment” is actually an embedded image link.

email image.png

The link looks like, but is actually a unique type of link, a data:text/html link — in other words, a Data URI, rather than an HTTP URI.

url field.png

When the user clicks the image link, instead of opening an in-browser preview of the document, it directs them to a spoofed page that prompts them to log in. 

faux google login page.png
If the user then inputs their email address and password, their credentials are passed to the attacker, who then has full access to the account – unless the user has MFA (multi-factor authentication) enabled on their account.

While Google has stated that they are working on improving defenses around this kind of attack, GreatHorn’s native spear phishing protection functionality is designed to catch most of the common attack techniques:

  • Display Name Spoofs. Many phishing attacks come from an email address with a Display Name that matches someone you know (“Your Boss”, for example), but an unusual email address (“[email protected]”). These emails can be automatically highlighted to a user, warning them of a risk present in the message, and admins can preset a customizable combination of notifications and actions in order to minimize the risk they pose.
  • Domain Lookalikes. More advanced attacks will come from look-alike domains, often only a single character away from a domain you recognize and/or regularly exchange email with (“” vs “”). GreatHorn’s automated social graph analytics catches and flags these types of emails, and admins can also chose notify users, quarantine the message, or delete it outright.

warning banner.png

Additionally, we are excited to announce that next week, we will be releasing two new features that will strengthen security postures against this type of attack and expand the capabilities of the GreatHorn platform significantly: Link Analysis and Attachment Analysis. 

Link Analysis will automatically flag embedded Data URIs, and Attachment analysis will similarly flag risky email attachments. In-message alerts to recipients as well as automated remediation actions can be applied to flagged messages, and the option to send event-triggered reports to the intended recipients of dangerous messages gives security awareness training efforts more teeth. By educating employees in the moment rather than through simulations of attacks that are inevitably happening in the wild anyways, we are able to move more definitively towards a frictionless, integrated SecBizOps environment

warning page.png


Next week is a big week for us: along with releasing the new Link Analysis and Attachment Analysis features in the GreatHorn cloud communication security platform, we’re also publishing our second 2017 Spear Phishing Report. Sign up to recieve updates or get in touch to discuss how GreatHorn can help your organization protect against advanced targeted threats here.

5-minute Guide to DomainKeys Identified Mail (DKIM)

According to Neil Wynne and Andrew Walls of Gartner Research, “email will remain the primary targeting method of advanced targeted attacks” through the end of the decade.

Email spoofing – the impersonation of someone inside of your company through the use of a rewritten “From:” mail header – is one of the most common ways that cybercriminals attack companies today. Relying on Secure Email Gateway technology alone is insufficient to protect your company, as impersonation attacks are specifically designed to not trigger the perimeter defenses these systems provide, despite marketing language to the contrary.

However, it is possible to fight back. Robust defense in depth works; combining strong authentication systems with effective data-driven email analytics can catch and automatically remediate even highly targeted spear phishing, whaling, and business email compromise.

In this free guide, we look at the second fundamental component of email authentication: DomainKeys Identified Mail, or DKIM. (If you missed our guide on SPF, we suggest starting there, as DKIM builds on SPF!)

What Is DKIM?

According to, DKIM “provides a method for validating a domain name identity that is associated with a message through cryptographic authentication”. In other words, using DKIM, an organization can prove that a particular message both came from their domain, and was not changed in transit to the recipient.

It was born out of the combination of two earlier standards: Yahoo!’s DomainKeys, and Cisco’s Identified Internet Mail. Formally outlined in RFC 5585, DKIM comes down to a fairly straightforward set of technical steps:

  • An organization sending mail creates a special kind of DNS entry to store a DKIM record, which contains both their identity as well as a public crytographic key
  • Upon sending mail, messages (or parts of them, such as those messages’ Subject and Body) from that organization are signed by the corresponding private key, with the result stored in a message header
  • Upon receipt, mail servers that respect DKIM verify that the incoming message (a) actually came from the purported sender, and (b) was not changed while in transit, using the public key stored by the domain used to validate the DKIM header

In other words, DKIM helps organizations prove that their outgoing mail is actually from them, at least in part. (It isn’t a complete solution, for reasons we outline below.)

The Strong Authentication Chain

DKIM works best when it is implemented alongside SPF, which we’ve covered previously. Together, SPF and DKIM form the first two links in what we call the Strong Authentication Chain — and they help organizations prove that their outbound mail is sent from a server which they authorize to send on their behalf, and that the message is both from their domain and has not been changed.

Both Google Apps and Office 365 will enable DKIM for you by default, but these default rules won’t be sufficient when you reach the final link in the Strong Authentication Chain, DMARC.

In a future post, we’ll look more closely at this third protocol, which extends the foundational protections of SPF and DKIM by checking for alignment between SPF+DKIM and the “From: ” line in your email, but for the purposes of this post, it is sufficient to state that both SPF and DKIM should be manually enabled by everyone using Google Apps or O365.

The good news is that this is easy. Below, we’ll walk through how to set up DKIM for both Google Apps and Office 365, step by step. Let’s get started!


DKIM for Google Apps

If you’re running Google Apps, DKIM is fairly easy to implement, and can materially improve your email security. You need to do only a few things to get up and running:

  • Create your DKIM key
  • Add the key to your DNS record
  • Enable DKIM signing in the Google Apps admin console

1a. Creating a DKIM Key

To create a Google Apps DKIM key, first open GMail, and then click the Gear Icon -> Manage this Domain:


Once you’re inside of the Admin page, navigate to  Apps > Google Apps > Gmail > Authenticate email:


In this screenshot, we’ve obfuscated our key; you likely won’t have a key enabled yet, so click “Generate New Record” to create one. For most organizations, the defaults are fine here – simply click “Generate” on the dialog box that pops up:


1b. Creating DKIM DNS Record

With the key created, you’ll next need to add it to your DNS record.

DKIM records are created as TXT records, and should mirror what you see in the Google Admin console above. The name of the record — different registrars refer to this slightly differently, but it’s the field that is NOT the value — should be:, where is the name of your domain.

The value here should be the TXT record value from the Google Admin panel, exactly as written. Breaking down what’s in that:

  • v=DKIM1 says that you’re using version 1 of DKIM. That’s all that there is so far, so just leave this as is. 
  • k=rsa denotes the type of key you’re using. rsa-sha256 is the default; leave this as is, too.
  • p=[your key] is the public key value that will be used by recipients to validate signed messages they receive from your domain.

1c. Enable Signing

With the key created and the DNS record in place — remembering that DNS has a propagation time, so this may require a delay of a few hours to take effect — you can turn on signing. To do so, go to Apps > Google Apps > Gmail from the Admin panel, and navigate back to the Authenticate email screen.

Once there, click “Start Authentication”, on the bottom right:


That’s it! You’re now using DKIM to sign your messages, a great step forward in protecting your organization from outbound impersonation.



DKIM for Office 365

DKIM setup in Office 365 is slightly different from Google Apps, but don’t worry – we’ve got you covered. We’re going to take just two steps here:

  • Create two CNAME records
  • Enable DKIM signing in the Office 365 Exchange Admin console

1a. Creating your CNAME Records

CNAME records are a type of DNS record, used to tell the DNS system that the “canonical name” of some domain is actually just an alias to some other domain. While understanding CNAME and DNS records isn’t required to implement DKIM on O365, it’s helpful to understand that Office 365 goes through the hassle of rotating your keys on your behalf — thus the need for TWO CNAME records for every O365 domain you own.

Both records take the same form:

Host name:			selector1._domainkey
Points to address or value:	selector1-<domainGUID>._domainkey.<initialDomain> 
TTL:				3600

Host name:			selector2._domainkey
Points to address or value:	selector2-<domainGUID>._domainkey.<initialDomain> 
TTL:				3600


What you need to customize here is the bold text – the domainGUID and the initialDomain values.

Your domainGUID is easy to look up: it’s right in your MX record. If you’re on a Mac or a UNIX machine, you can look this up via a terminal, using the dig command — in the example below, the GUID is “flyingdeliveries-com” — note that this has a hyphen in it, and it’s the first part of the record on the right-hand side of the result line:


If you’re daunted by the use of the terminal, you can also look this up online via the website MX Toolbox. Just type your domain name in, and you’ll see the same GUID as the text before “”.

initialDomain is the name of the domain you used when you signed up for Office 365; you likely already know this, as it should be the “primary” domain of your company. This isn’t always true, of course; some organizations have aliased domains that they use, but these tend to be circumstances that are well known, not the norm.

Once you have the format for these two CNAMEs (or additional sets of two, for any additional domains you’re using with Office 365), you’re ready to publish them via your DNS registrar.

1b. Enable DKIM Signing for Office 365

With the CNAMEs in place, it’s time to start signing your outbound mail. The easiest way to do this is via the Office 365 Admin Center.

In the Admin Center, navigate to protection, then find your domain and click “Enable”:


That’s it! You’re all set, and signing your outbound email properly with your own DKIM key.

Is DKIM Enough?

DKIM (and especially SPF and DKIM together) are a great combination. However, it’s important to note that these two technologies are insufficient to prevent many kind of inbound mail attacks.

The challenge is that DKIM cannot verify anything other than the data integrity between the time of signing and the time of verifying. Attacks from valid domains that pass DKIM will not be marked as “suspicious”; look-alike domains, imposter DKIM verification headers, and display name spoofing are just a few of the common and highly effective attacks that bypass DKIM and land in inboxes.

Effective email security requires “defense in depth”, and while SPF and DKIM are an important component of that strategy, they are insufficient on their own.

GreatHorn is the world’s first and ONLY comprehensive and fully automated inbound email protection platform. Requiring no setup steps, no change to mail routing, and no reliance upon email gateways or insecure blind copies of mail to third parties, it co-exists with SPF, DKIM, and DMARC to provide the only comprehensive spear phishing protection on the market.

With GreatHorn Inbound Email Security for Google Apps and Office 365, you can take control (via the GreatHorn Policy Engine) of how to handle messages that don’t get caught by SPF and DKIM. For example, GreatHorn allows you to:

  • Extend mail authentication analysis to include content analytics, quickly identifying wire transfer frauds, CEO impersonation attempts to steal employee W2s, and other forms of PCI, PII, and PHI theft
  • Detect and remove messages that come from domains that are look-alikes of your domain – for example, vs
  • Quarantine messages that violate GreatHorn policy, removing them from the inbox and placing them into a folder, similar to a Spam folder
  • Automatically flag suspicious or anomalous messages to your users, providing truly effective realtime end-user awareness, rather than often ignored training

Setting up SPF and DKIM are important, but if you’re running Google Apps or Office 365, and want to truly protect your organization against inbound email threat, GreatHorn stands alone in its ability to defend your users.

5-minute Guide to Sender Policy Framework (SPF)

One of the major vectors for spear phishing attacks that we often see is email spoofing – the impersonation of someone inside of your company through the use of a rewritten “From:” mail header.

This is a particularly easy type of attack to execute, if you’re of the mind to do so. In fact, in our recent State of Spear Phishing report, we reported on how we identified and defended our customers from more than 33,000 spoofing attacks in a single calendar quarter!

Even if you aren’t a GreatHorn customer today, you can take some basic steps to protect your organization’s email against this kind of attack for free, using email authentication systems such as SPF, DKIM, and DMARC.

Sender Protection Framework, or SPF, is the most logical starting point. In this quick guide, we’ll cover how to set it up and use it, as well as where its limitations are.

Background of SPF

SPF was born back in 2006, as an experimental approach to stopping forged (or, as we’ll refer to them from here on out, spoofed) emails from being delivered to ordinary users. It often comes as a surprise, but email — as a protocol — places few limits on what someone sending a message can do with their email headers, which are something akin to an envelope.

As with the real world, it’s easy to put more or less anything you like in as the return address. The problem is that unlike a physical letter, email is often rife with links to malicious websites, malware-infected files, and even requests to authorize fraudulent financial transactions and wires.

Logo of the Internet Society While it’s undergone some revisions since being introduced, the basic idea of SPF is to make this kind of spoofing more difficult by allowing an organization to define a set of IP addresses which are authorized to use its domain in the “From:” header. While this has some limitations, which we will cover below, it’s both relatively easy and highly worth setting up.

Step 1: Getting Started

First, in order to implement SPF, you’ll need access to the DNS records for your domain. Specifically, we’re going to be creating a TXT record — the details of how exactly to do that vary by who hosts your domain, but make sure you can edit the zone file for your domain before proceeding.

If you’re not sure, check out the support page for your registrar — some of the more common ones are below:

Step 2: Just What Is SPF, Anyways?

SPF is, essentially, a specification that covers two things:

  • A list of authorized senders who may use your domain name
  • A declaration of how you want to mark emails based on whether they are on that list

We’ll take this in two parts. The first is defining who can send as you. While you can get somewhat sophisticated with how you define that list, the basic process is straightforward.

If you’re running Google Apps for your business, you’ll want your SPF record to look something like this:

v=spf1 ~all

If you’re running Office 365, the suggested SPF rule is:

v=spf1 -all

Let’s break it down:

v=spf1 says that you’re using version 1 of SPF. That’s all that there is so far, so just leave this as is. or says that your mail should only be sent as you when it’s routed through Google or Microsoft’s servers. By defining this here, you’re explicitly deferring to these vendors’ lists of IP addresses for valid senders. While Google and Microsoft might change that list, these lookup addresses will always (in theory) be up to date, ensuring that anyone trying to impersonate you can only do so via the platforms own mail servers, reducing the number of potential spoofing sources that you’ll receive.

The second part of SPF is how you mark messages that you send. What happens when someone tries to impersonate you? There are two reasonable options, and the two cloud email providers have slightly different suggestions for which to use:

~all says, “mark messages that come from an sender not on my list as a “softfail
-all (not used in the example above, but an option) says, “mark messages that come from a sender not on my list as “fail

Now we come to one incredibly important point about SPF: you can’t control what recipients of your email will do with messages when they are unauthorized. Some services block any “fail“, others simply deliver them, and almost everyone will receive a “softfail.”

Step 3: How SPF Helps

You might be asking yourself, and reasonably, “if anyone will receive a softfail, what good is SPF?”

The answer is that it’s complicated. Being able to mark messages (in their headers) as softfail is great, but there are a LOT of reasons why a message might fail SPF. Maybe your mail servers change. Maybe your Marketing team sets up email to be sent from an automation platform, and forgets to tell IT, so new IP addresses never get written to your DNS SPF record. It happens.

Step 4: Next Steps

The tricky part of SPF is that, with most cloud email providers, you simply can’t control what happens on the receiving side. In fact, you’re probably receiving quite a few softfail-marked email today — most of it benign, but maybe not all.

Effective email security required more control than SPF alone provides.

This means two things: implementing complementary authentication systems such as DKIM and DMARC, as well as additional security systems that address the threats that are not mitigated through authentication alone.

As with any cyberthreat, spoofing is often part of a more sophisticated attack chain, one that not only uses receiver-side SPF decisions that allow fail and softfail messages to reach user inboxes, but also carefully crafted and highly targeted language that can trick users into clicking on links, giving up their credentials, or even authorizing wire transfers that send significant amount of money to hackers.

It may sound complex, but GreatHorn makes this kind of email security simple.

With GreatHorn Inbound Email Security for Google Apps and Office 365, you can take control (via the GreatHorn Policy Engine) of how to handle those softfail messages. For example, GreatHorn allows you to:

  • Extend SPF analysis to include content analytics, quickly identifying known threats, regulated data, and other mail-based attack indicators
  • Detect and remove messages that come from domains that are homographs of your domain – for example, vs
  • Quarantine messages that violate GreatHorn policy, removing them from the inbox and placing them into a folder, similar to a Spam folder
  • Automatically flag failed and softfailed messages to your users, warning them to be more cautious when responding to them, and automatically “white list” messages that are routinely failing SPF checks to reduce false positives

Setting up SPF is a necessary first start, but it needs to be part of a true defense-in-depth strategy. If you’re running Google Apps or Office 365, and want to truly protect your organization against spoofing attacks, let us know – we’d be delighted to offer you a free trial of the GreatHorn platform.