Anatomy of a Phishing Attack: Rising Tide of Service Impersonation Spoofs

Nov 12, 2018 | credential theft, email security, phishing

As a member of GreatHorn’s Customer Success team, I have daily insight into threat patterns as they emerge across our customer base. While we always see a variety of threats (and some more than others), occasionally we see volumetric phishing patterns that result in temporary spikes in one particular type of threat.

Over the past several weeks, we’ve seen a huge spike in service impersonation attacks. In this blog, I’ll explain what these are, how they work, what to look for, and what you can do to prevent them.

(more…)

Breaking: New phishing campaign targets Office 365 customers, masquerades as missed voicemail

Oct 17, 2018 | credential theft, email security, O365, phishing

This morning, on October 17th, GreatHorn’s threat response team identified an active, widespread phishing campaign using a range of impersonation techniques to deliver a “voicemail” alert to customers, linking to what appears to be a Verizon-branded PDF, hosted in either SharePoint or on free PDF hosting sites, containing links to credential theft attacks. Currently, the attack appears to be primarily hitting Office 365 customers, targeting multiple users within an organization, and has been found present across multiple industries and organization sizes, using different combinations of sender and subject lines.

Although we currently have only identified it in O365 environments, there is nothing to prevent this scheme from propagating to G Suite and other environments.

The GreatHorn security team is currently monitoring this attack and providing automated support to clients.

Currently, here is what we know about this attack:

The initial point of infection is via a phishing email from senders “[email protected]” and “[email protected]”. The email takes a number of different forms, including the example on the right, and includes a link to a PDF that is currently being hosted on multiple compromised Sharepoint file hosting sites, as well as on free PDF hosting websites such as freepdfhosting.com.
The destination of the supposed voicemail link is a PDF, branded as a Verizon document, containing a second step URL that leads to a credential theft site designed to look like an Office 365 login:

PDF with Verizon-branded message linked to credential theft website

Credential Theft: Fake Office 365 login page

Our specific recommendations:

All customers of GreatHorn Email Security will find new policies in place in their GreatHorn Dashboard that will stop this attack by moving mail matching these patterns to Danger-phishing.

We are continuing to monitor for evidence of this attack, and will provide additional information and remediation support as our investigation continues.

As of October 17 at 11:51am EDT, neither the documents, the URLs where they’re hosted, nor the credential theft links themselves are being flagged by threat intelligence blacklists. While threat intelligence is an important part of any email security strategy, they are often ineffective at protecting against zero-day threats and phishing attacks.

If you have any questions or concerns, please feel free to contact the GreatHorn team at [email protected].

LIVE WEBINAR | NOV 1 | 2 PM ET / 11 AM PT

The Evolution of Phishing & How We Fight Against It

Join our November 1st webinar at 2pm ET, where dmarcian CEO Tim Draegen, the primary author and advocate of the DMARC standard, and GreatHorn CEO Kevin O’Brien will discuss how phishing tactics have evolved over the years and how email security approaches have had to change to keep up.

Register now!

PRODUCTS

GreatHorn Email Security

GreatHorn Link Protection

GreatHorn Mailbox Protection

GH Threat Platform

RESOURCES

B log

Help Center / Documentation

By the Numbers: Understanding the Phishing Threat

Aug 17, 2018 | business email compromise, credential theft, email security, phishing

Today, after 4 decades in existence, and more than 25 years’ worth of consistent, daily use, email remains the most reliable, ubiquitous, and constant communication platform for both personal and professional interaction. As users, we may grumble about its ubiquity or its misuse, but we have an inherent trust in email bred from familiarity and functionality.

So it’s of little surprise that email has also become the single largest platform for Internet Crime, at least as reported by the FBI in its annual Internet Crime Report. Business email compromise alone represents 48% of the reported $1.4B financial losses from Internet crime in 2017. That’s 10x more than the reported losses from identity theft, and 3x more than the second most lucrative Internet crime technique (confidence fraud / romance).

Defined by the FBI as “sophisticated scams [that] are carried out by fraudsters compromising email accounts through social engineering or computer intrusion techniques to conduct unauthorized transfer of funds,” business email compromise is just one of many email-based threats facing organizations today.

So why are such scams so successful? In June, GreatHorn conducted a survey of 300 business professionals – most of whom were involved in email security in some way – to understand the current email security involvement. We benchmarked threat frequency, prevalence, types, defenses, and remediation requirements to see what kind of patterns we could find.

As you see in this infographic, we found a number of clues that pointed to the root cause behind the success of social engineering scams such as business email compromise and other spear phishing techniques.

For example, we learned that the “average” user either doesn’t recognize email threats for what they are or they dismiss it under the rather innocuous heading of “spam.” We know this because two-thirds (66%) of average users could not recall seeing any of the following email threats in their inboxes:

Executive or internal impersonations
External impersonations (e.g. customers, vendors, partners)
Wire transfer requests
W2 requests
Payload / malware attacks
Business services spoofing (e.g. ADP, Docusign, UPS)
Credential theft

And yet when asked the same question (explicitly about what reaches inboxes, not a quarantine folder), 85% of respondents that had some involvement in email security indicated that one or more of those threats was hitting inboxes.

That discrepancy demonstrates a dangerous perception gap within organizations – the exact perception gap that criminals exploit. We’ve moved beyond the easy-to-spot Nigerian prince schemes of yesteryear. Sure, there are still mass phishing attacks that are easy-to-spot, but such attacks in some ways increase the danger precisely because they are so easy to see. The user quickly identifies them as a danger, dismisses them as obvious, and pats themselves on the back for being perceptive enough to see them.

That self-congratulatory complacency may lead to an inability to recognize the real threats – the highly targeted, sophisticated, and well planned attacks that uses social engineering and research to replicate, impersonate, and redirect “real” communication. Our research indicates that most existing email security solutions are failing to catch impersonations (nearly half of our respondents – 46% – report impersonations; including 64% of email security professionals). Such emails often come without obvious triggers such as an attachment or even a link – they use urgency (5pm on a Friday), conciseness (typically just a couple of sentences), seniority (often impersonating a superior), and fear to drive the desired outcome. That’s why it makes sense that impersonations are the email threat that email security pros worry most about.

More concerningly, our study indicates that 1 in 5 organizations have to take some kind of significant remediation action (e.g. suspending compromised accounts, PowerShell scripts, resetting compromised third-party accounts, etc.) on a weekly basis as a result of email threats that bypassed their security defenses. And on average, our panel deployed approximately three separate security tools to protect their environment from email threats.

Given the remediation requirements, it’s no wonder, however, that 56% reported major technical issues with their email security solution today, including:

“Doesn’t stop internal threats (e.g. if a user account is compromised)” – 35%
“Missing payload attacks” – 16%
“Missing payload-free attacks (e.g. impersonations, social engineering)” – 20%
“Weak or no remediation capabilities” – 19%
“Negative impact on business operations (e.g. too many false positives)” – 21%

We’ll dive more into the challenges with today’s common email security platforms and our results in upcoming blogs. In the meantime, however, we’d love to hear what you think. What do these numbers mean to you?

Want to download the full report? You can do so here.

The Google Docs Phishing Attack

May 3, 2017 | credential theft, G Suite, Gmail, Google

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:

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.
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.

5-minute Guide to DomainKeys Identified Mail (DKIM)

May 24, 2016 | business email compromise, credential theft, email authentication, email security, G Suite, Gmail, spear phishing

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.org, 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:

google._domainkey.your_domain.com, where your_domain.com 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 “.mail.protection.outlook.com.”.

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, yourcompany.com vs yourcornpany.com
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.

Learn More About Inbound Email Security

The Human Factor In Targeted Emails Attacks

Apr 19, 2016 | CEO, CFO, CISO, credential theft, email security, spear phishing

Harrowing is the word for the FBI’s recently published findings on CEO impersonation and related email fraud; according to the latest research from the FBI, there have been more than $2 billion in losses since 2013.

That maps to a 270% increase in victims and loss since 2015 (and those are merely the fraction of losses actually detected and reported.)
A Reuters story that ran this morning reports that an (undisclosed) US firm lost over $100m to an email spoofing impersonation attack
Only slightly less harrowing than the raw numbers is the standard advice on how to respond: stronger authentication protocols and yet more security awareness training.

While both are good InfoSec practices, neither stops breaches or losses because these sophisticated email scams ultimately depend upon one thing: honest human error.

The Role of the Individual

Human error often plays a role in successful breaches, and no amount of security awareness training or authentication improvements will eliminate that. Impersonators take a methodical approach to their prospective victims. They map out an organization, identify targets with access to information or funds, research executive travel schedules, create nearly identical imposter domains, and spoof legitimate email addresses to circumvent SPF, DKIM, etc. When they do make contact, scammers create a sense of urgency and secrecy, and exploit socially-engineered trust so that the target employee voluntarily transfers money or personally identifiable information. Here, the ineffectiveness of better authentication and security training begins to show.

Authentication plays a built-in role in the impersonation scam. Rather than compromise an account, impersonators simply gain the confidence of victims, whomust themselves be properly authenticated to send the desired funds or information.

An Impossible Challenge: Security Awareness Training’s Failure

This leaves only training. On top of high implementation costs, these programs are outright ineffective. According to Forrester, employees with extensive security training have a pitiful 4% higher chance of catching such attacks over their untrained colleagues.

Moreover, 46% of employees state that “security restrictions and policies make me less effective,” and 32% admit they “sometimes ignore or go around our security policies.” This all to show how even companies with strong security protocols have fallen victim. Ultimately, if the advice to improve authentication and training just leads back to the same opportunity for honest human error, then the logical answer is automation.

Expecting employees to catch scams themselves is precisely what attackers want.

Instead, it’s better to add a layer of automated protection. GreatHorn’s platform applies heuristic risk scores based on metadata from fraudulent email attacks to automatically detect threats as they reach the inbox and take sub-minute, policy-based action against them. (GreatHorn works with existing network topology to natively integrate with today’s most popular email platforms (Google, O365, etc) and deploys in under 15 minutes.)

Sadly, CEO impersonation is but one of many sophisticated attacks. In the last four months alone, over 60 companies have fallen for the similar W2 email scam. As security training catches up, attackers will simply continue to dream up new scams and inventive ways of tricking people.

Automated protection learns along with them and applies that knowledge in real time, so rather than reactively alerting and training employees, organizations can identify and remediate threats pro-actively, stopping the breach before it happens.