Top 3 Reasons Gaps in Microsoft and Proofpoint Email Security Are Leaving Organizations Vulnerable

Email Account Takeover (ATO) attacks occur when a threat actor gains unauthorized access to an email account belonging to someone else. Cybercriminals obtain stolen user credentials through trade or purchase on the dark web. Typically, the credentials are obtained through spear-phishing attacks that serve the victim a URL to a web page impersonating legitimate services like MS Office365 (Figure 1). Office365 is one of the top impersonated brands for email hosting services, according to SlashNext’s Phishing Research Lab. Other top impersonated brands include GSuite, Roundcube, Zimbra, and YandexMail.

Figure 1: Phishing webpage impersonating MS Office365 log-in screen

Once the threat actor gains unauthorized access, the results can be devastating to a company. It can be used as a launchpad to carry out Business Email Compromise (BEC) attacks against its customers and partners. BEC scams had caused businesses over $26 billion in losses over the last 3 years, according to FBI’s Internet Crime Complaint Center (IC3). With stakes this high, why do Secure Email Gateway (SEG) vendors miss the mark? Because the anti-phishing technologies to prevent spear phishing attacks, used by Microsoft and Proofpoint, have not kept pace with the innovations made by cybercriminals. SEG vendors still rely heavily on URL reputation and domain token matching to combat ATO attacks. These technologies can block emails containing URLs that are recently registered and URLs impersonating popular domains, but they often fail to stop more sophisticated attacks. Cybercriminals take advantage of the weaknesses in these technologies. They purposely host their phishing webpages on well-known shared hosting providers such as SharePoint and other file-sharing services, to evade detection.

Microsoft and Proofpoint responded by introducing their advanced threat protection solutions. These offerings rewrite the original URL in emails, allowing them to reinspect the URL a second time, during the time-of-click by users. This approach helps with detection but still falls short for many reasons, including:

  1. Using the same inspection technologies that missed detecting the phishing emails during the initial scan
  2. An inability to analyze the webpage content due to inspection blocking because the phishing webpage detects the request is coming from a datacenter IP associated with SEG vendors. It purposely denies the request to prevent the webpage from being scanned.
  3. Cannot rewrite the URL in the email, leaving users exposed. Here are some of the common conditions that result in the URL not being rewritten by SEG vendors:
    • URL without www and <a href> such as
    • URL without http:// and <a href> such as
    • URLs in attachments (support is typically limited to MS Word and PDFs attachment types)
    • URLs in emails received using “on-the-fly” encryption services like Echoworx or Zix Corp.
    • URLs in emails that are SMIME/PGP/DKIM signed. This is configurable by the customer, but rewriting URLs in SMIME/PGP/DKIM signed emails can cause the email to be incorrectly rejected or quarantined.
    • URLs in the SEG vendor’s global whitelist, (i.e.,…)

SlashNext’s end-to-end phishing protection is fundamentally different. We leverage dynamic run-time analysis using virtual browsers and deep learning. The same stringent method is applied to all webpages, allowing SlashNext to detect phishing web pages hosted on shared hosting providers, hours, and sometimes days ahead of the competition. SlashNext solutions help close the gaps found in SEG solutions and extend protection to less well-defended attack vectors such as personal email, social media, and collaboration platforms.

To see how SlashNext, the number one authority in phishing, can protect your workforce from the growing number of sophisticated phishing threats contact us to request a demo today.

*** This is a Security Bloggers Network syndicated blog from SlashNext authored by Jimmy Lin | SlashNext Phishing Research Lab. Read the original post at: