Malicious URLs: How Protected Are You?

Malicious URLs: How Protected Are You?

Few angles make for a better email-borne attack than the impersonation of a trusted service. Organizations such as Microsoft, Google, Bank of America, Citigroup, DocuSign, Dropbox, FedEx, UPS, and countless others are brands recognized throughout the world that host or access trusted financial data, personally identifiable information, confidential data, and other exploitable content desired by criminals.

Better yet for attackers, these organizations frequently send a variety of notifications: updated terms of service, account changes and alerts, new documents being shared, etc. Recipients don’t just trust these brands, they’ve been conditioned to expect email notifications from these companies. As a result, they often interact with emails from trusted brands without giving as much thought to it as they might take with an email from a stranger. This provides a ripe environment for attackers to exploit.

These types of emails are often attempting to gain any number of different pieces of information: names, addresses, social security numbers, account numbers, routing numbers, but what is commonplace at nearly every organization are credential theft attempts by way of a fake notification email like one of the aforementioned. Attackers have realized the value of these credentials; with password reuse as rampant as it is, one password could be the key to everything from a corporate account to a personal email account to a bank account, and even without widespread reuse of the password, email addresses are the most common means of resetting passwords for every other account a person utilizes.

There are a number of ways to detect and prevent these types of attacks, but detection and prevention specifically based upon analysis of URLs (and to a lesser extent attachments) has been viewed as a central component to email security technologies for some time now. This is not nearly as infallible as many would be led to believe and when the system gets it right, everyone sleeps soundly, but there are a number of these payloads still reaching end users precisely because of the shortcomings of the specific analytical approach taken and end users are then left to their own devices to figure out which URLs are safe and which are not.

Over time, attackers have become craftier and craftier in their approach to these emails meaning the payloads getting through are more and more pernicious. Regardless of who or what business service might be spoofed by an attacker, destination URLs are often “hidden” behind hyperlinked text (e.g. “Click here”), made to look like a common file share URL, or are even legitimate file sharing URLs. Because of this, they can be difficult to spot and identify as unsafe. Coupled with users’ inherent level of trust with these respected brands (or members of their organization) and the sense of urgency an attacker creates (Data will be deleted in the next 24 hours if you do not take action!), users often feel compelled to do exactly as the URL advises: they click.

Many existing email security solutions are heavily reliant on threat intelligence feeds to identify these URLs as malicious at the time of delivery. While undeniably useful, threat intelligence has its shortcomings. It goes without saying, but someone need be the first (or possibly second, third, fourth, fifth…) victim before the URL can be classified as malicious and that intelligence can be disseminated. Other solutions stop short in performing their analysis on the full URL but instead focus only on the root domain. The idea is that, given their available dataset coupled with their threat intelligence and other data feeds, malicious URLs are bound to be spotted based solely on being anomalous. This, of course, ignores the fact that web certificates do expire or that attackers can hijack otherwise innocuous websites through other means, they can utilize URL shorteners, redirects, and a host of other means that ultimately obfuscate the true intent of the destination page of the attacker’s URL.

GreatHorn recently identified a fairly compelling example of a business services impersonation email in one of our client environments that would have almost certainly bypassed many of these existing methods of detection. The message appeared to be from business service provider LogMeIn, which makes a suite of popular access and communications products, including GoToMeeting and LastPass among others. As anyone familiar with LogMeIn can see here – save for the font – the notification was exceptionally close in appearance to a real LogMeIn notification email. There was a link in the message purportedly leading the user to a LogMeIn account login page where “6 months of free subscription” awaited him.

In this instance, the attacker utilized a domain for the URL ( similar enough to LogMeIn’s actual domain ( that it would likely pass as legitimate to an end user’s eye test. At the time of attack, the URL in this email was not showing up on dozens of threat intelligence feeds and the root domain of the URL redirected to a Google search page showing results for a LogMeIn-related search. With threat intelligence coming up blank, if a solution were to check the root domain, it would ultimately find a legitimate Google webpage.

As is shown in this example, the term “detecting malicious URLs” can be misleading. This particular email, at least in regard to the URL, could easily have bypassed any number of security solutions if they used one of the above approaches. With attackers getting more savvy, it’s important for security teams to ensure that their link protection options are robust enough to protect them from attacks.

We recently announced GreatHorn Link Protection – a new turnkey module that’s available as a core component of our email security platform. In addition to all the proprietary threat detection techniques we use that would flag a message such as this as a concern, GreatHorn Link Protection provides multiple levels of protection regardless of the URL’s presence on our threat intelligence feeds.

Stay tuned for more blogs on GreatHorn Link Protection, but in the meantime, you can learn more about GreatHorn’s Malicious URL capabilities here. Also consider checking out our recent blog on the recent rise in business service impersonations to learn more about real-world credential theft attempts.

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.

Spear Phishing with Gödel

Spear Phishing with Gödel

Earlier this week, one of our customers emailed us to ask why a spear phishing simulation tool they were using was able to send email to their users, despite them having set up SPF (sender policy framework) properly. It’s a great question, and while we’ve described what SPF is before, many of the organizations we speak with do not understand why it fails to provide adequate protection for stopping spear phishing attacks.

In this post, we’ll take a look at some of the more insidious problems around email authentication, and why stopping spear phishing attacks requires more comprehensive security than existing specs can provide — and we’ll even step back to the 1930s and look at why, through the lens of a certain European logician and mathematician.

HELO, Who’s There?

Email fraud is a major problem, in part because email is an incredibly complex set of systems that span the entire internet. It’s fairly impressive that any computer can, essentially in realtime, send a human-readable message to anyone in the world; unfortunately, the technological stack that enables this kind of communication to function was not built upon a foundation of trust.

In other words, it’s easy to manipulate email, and use it for nefarious purposes: credential theft, financial fraud, and even real-world crime. Last year, in fact, a study by a major antivirus company found that the odds that a major terrorist attack on the United States had a 9 in 10 chance of starting with an email-based deception — a spear phishing attack.

I Thought We Were Covered?

A common misconception we encounter when working with our clients is that they can implement certain technologies — SPF, DKIM, DMARC, and so on — to prevent these kinds of attacks from succeeding.

In theory, this should be how it works. The idea behind the SPF framework, for example, is that, “a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization.” (Via the official SPF RFC, here.)

Sadly, in practice, it’s possible to send a spoofed email to a user in such a way as cause SPF to pass, but still be entirely spoofed from the perspective of the end-user. And DKIM, DMARC, and even newer technologies like ARC are either so poorly adopted as to be essentially useless today, or are entirely untested.

Take this (slightly redacted) example, sent to a user inside of our domain:


Notice, in the red box, how this email has been authenticated via SPF. Every email provider in the world would accept this message, and display it by default. The only problem?

This is a completely spoofed message. It was sent to our user from a script that rewrote the email to look as though it was from someone they could trust (the address, which we’ve redacted for privacy purposes).

This underscores one of the fundamental issues with email security and authentication.

Problem 1: Authentication Is Usually Mis-Configured

One of the primary problems with email authentication technologies like SPF (which is the =pass line in the example above) are that they require work to implement properly, and then need to be maintained whenever an organization’s mail servers are updated or changed.

We see so many broken implementations of SPF in the wild when working with our customers. In a perfect world, every domain would have SPF, DKIM, and DMARC set up and running well, and it would be nearly impossible to execute a spoofing attack. In our reality, however, this is an impossible hurdle.

For example, one of the companies we work closely with had a good SPF implementation – but it was a few years out of date. They were early adopters of the spec, but whomever set up their original DNS entries for SPF either forgot to update them when they switched from a hosted Exchange server to a Google Apps environment, or was no longer employed there.

The net effect? Every message they sent was marked as a softfail — meaning that there was no technical way to differentiate a spoofed message from a legitimate one when sent from their domain.

Problem 2: The Burden Is On The Wrong People

On the receiving side of the exchange, this kind of inconsistent deployment means that it’s nearly impossible to use SPF for its intended purpose of determining whether to deliver a message or not. As a result, the default for every email provider is to allow these kinds of softfail results through – doing otherwise would likely mean that a significant number of otherwise reasonable emails would be “lost”, with the obvious cost being to their end users.

Of course, most people who receive email simply read it, respond to it, and file it away. The assumption – especially if they are using a major provider like Google or Microsoft – is that their mail is generally safe. Foundational controls for malware and spam are nearly ubiquitous today, and default protections (for example, Google’s in-email warning banners) are highly visible:

Google's warning banner

The major problem here is that these protections are, at best, imprecise. Not to pick on Google, as they do a very good job at providing baseline security against these kinds of attacks, but banners and spam filters typically work based on keyword detection. Savvy attackers know this, and know how to bypass these filters.

Recently, Google and Yahoo both announced that they would be transitioning to a more strict DMARC policy (p=reject). We celebrate the improved authentication that this will provide — and are excited to see ARC gaining traction, as well —  but even with these policies in effect, when strong authentication goes up against deliverability, deliverability will win.

Problem 3: Technology Is Not The Same As Intelligence

Imagine a world where, miraculously, all spoofing attacks become impossible. Perhaps we’re wrong — although it’s a hard argument to make — and every domain in the world will implement some form of DNS-level validation within the next decade.

The complexity of the global email network means that there remain significant and highly successful attacks — remailing attacks, homograph attacks, and direct account compromises — where, even if we had a perfect authentication system, it would be possible for attackers to trick people into taking action based on mail that was inherently untrustworthy.

So, if email authentication can’t help, what can?

Abusing Gödel: The Trust Incompleteness Theorem

The answer here is one of first principles. What is missing in email exchanges – and, while not the topic of this article,other forms of cloud-based communication – is trust.

Trust must be derived from outside of the systems used to exchange email if it is to be believable.

Allow us to step, if briefly, away from email security to explain why. In the early part of the 20th century, Kurt Gödel, an Austrian mathematician, noted that (simplifying somewhat) within the realm of mathematics, no system can be both consistent (that is, free from contradictions) and complete (that is, if in respect to any given property, every formula having that property can be derived using that system).


While Gödel was writing about mathematical systems, his so-called incompleteness theorem has wide-ranging implications. Among them is the concept that for any given system — even something as comparatively trivial as sending validated messages over the Internet — there will be certain truths which cannot be proven within that system.

Trust is an example of this.

The ability to manipulate the content and headers of a message, or to impersonate a trusted individual by an attackers are the primary reasons why email security is in such a sorry state today. While increasing the complexity of these systems may deter more basic attacks – and this is very much what we expect to see as Google, Microsoft, and other email providers improve the default security they offer – trust about these communication systems must come from an external source.

Trust at the Moment of Interaction

And so, we come to what we’re building with GreatHorn.

While natively integrated with the major email providers, our ability to analyze messages, identify indicators of deception, and take automated action without requiring a decision from a recipient is based on the belief that this kind of trust must come from outside of the email exchange itself.

Take as one example our example from the start of this post:


Where an email system would rely on SPF (and the other headers) to determine if this was a spoofing attempt, and would likely get it wrong, GreatHorn has an external data set it can use to determine if this is a trustworthy message. In this case, that analysis can extend far beyond what is evident in this single message, or even across the total set of messages available to the recipient domain (, in this example).

Moreover, GreatHorn can look at more data than is even available to the platform provider, Google — because with over 50,000,000 new emails every quarter to analyze, across every major email vendor, the data set available in full realtime is entirely unparalleled.

And, in this case, we can immediately identify that this is a spoofing attempt despite the supposedly valid SPF record!

Given the massive financial cost for a data breach or financial fraud attack, this kind of external security is essential. Want to see if you’re at risk? We’re happy to help, and can deploy GreatHorn in under 20 minutes.

SEC Guidance on Cybersecurity Compliance

SEC Guidance on Cybersecurity Compliance

Cybersecurity compliance is an increasingly important topic. Last week, the SEC brought charges against 32 individuals accused of insider trading; as Kristin Bartlett, M. Todd Scott, and Daniel Dunne of Orrick noted, the Commission “alleges that the hackers and traders made more than $100 million in illicit profits by hacking into embargoed non-public company information on the newswire services’ systems and trading on that information before it was publicly release.”

This is a continuation of the SEC’s increased emphasis this year on preventing cybercrime, and underscores the importance of both strong assessment and strategic response capabilities for organizations subject to SEC oversight. Today, we look at three specific areas for implementing those recommendations, even with modest infosec resources at your disposal.

Implement Early Assessment Capabilities

According to the Centre for Strategic and International Studies, cyberattacks are on track to cost 20% of the total economic value created by the Internet, primarily via fraud and espionage.

The cost of a data breach is a well-known statistic in the industry, and many security vendors cite the annual Ponemon Institute’s report for information as to what the potential damages for not securing against a compromise are. (For 2015, the average breach costs an organization $3.79 million.)

Accordingly, it’s important to prevent breaches as early as possible. The primary vector for 93% of all attacks is spear phishing; organizations who are bound by SOX, HIPAA, FedRamp, PCI-DSS, or any other of a number of regulatory requirements cannot afford to not have a robust, automated, and accurate spear phishing detection and prevention program in place.

Harden Against Privilege Escalation Attacks

The “prize” for most hackers who are engaged in spear phishing is a set of credentials — typically stolen via either malware embedded in a document file or through the use of a malicious link. Once stolen, those credentials are then used to move laterally within a network, and gain illicit access to sensitive data.

As with the pending SEC case from last week, Forbes notes that “key assets for organizations…usually include financial assets held in digital form (e.g., money or stocks), customer data, trading data and business strategy information (e.g., trading algorithms or strategic business plans).”

Security executives can defend against this kind of attack by extending their assessment tools beyond simple spear phishing detection. Credential theft is indicated by abnormal access patterns, either through suspicious login times, locations, or patterns of repeated access attempts, failures, and so on.

The sheer volume of authentication data makes this incredibly difficult to parse manually, but new technologies do exist which can identify these abnormalities automatically, and either alert security teams to their presence, or take automatic action to remediate them in realtime.

Ensure Robust Audit Tools are In Place

Finally, any security strategy implemented which can detect spear phishing and credential theft must be supplemented by strong, realtime, and comprehensive audit tools. Being able to demonstrate that your organization is meeting the specific requirements of the regulations which you are subject to both reduces the amount of manual work that is required to remain compliant, and also makes it significantly easier to show that appropriate measures are in place to avoid charges of negligence should a breach ever occur.

If you’re responsible for protecting your organization from highly targeted and motivated hackers, we’ve got you covered. Check out our free eBook, The CISO’s Guide to Spear Phishing Prevention, for insight, guidance, and a framework for ensuring that your company isn’t the next high profile data breach on the evening news.