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.
Service impersonation attacks
One of the largest trends in email impersonation attacks that GreatHorn has seen in the second half of 2018 is an upswing in the number of service notifications for:
- Microsoft services
- Electronically delivered voicemail
- Electronically delivered faxes
We covered the uptick in electronically delivered voicemail in detail a few weeks ago, but are calling it out again here as indicative of the larger trend we’ve seen.
The messages are most frequently credential theft attempts, normally via URLs that purportedly link to login pages for the service in question. Calls to action vary widely, and can include:
- Storage full – log in to avoid losing emails / files
- Re-authenticate your account
- Your account has been locked
- Click here to retrieve your voice message / fax
- Log in to protect the security of your account
- Your account has been compromised, click here to resolve
These emails may impersonate any of dozens of Microsoft services or online message delivery systems.
Detection of these threats is complicated by:
- The large number of legitimate sending addresses and domains used by Microsoft and other services
- Highly variable display names associated with these attacks
- The attackers’ use of homographs in the display names and content to create visually identical keywords using different characters
- The attackers’ use of 0-point spaces to add hidden characters to display names and content keywords
A single organization may commonly receive legitimate service notifications from more than a dozen different email addresses. Large, highly technological service providers may send automated emails from any number of dynamic addresses, and each business unit may have its own domain or subdomain. Vigilance is required to maintain an accurate whitelist of legitimate senders of service notifications, and those lists will show considerable variation among different organizations.
Attackers further confuse the issue by modifying display names and keywords to evade detection. To date, GreatHorn has identified more than 250 variants of the display names used in these service-impersonation attacks. Due to this extreme variation, any sort of literal matching, either exact or partial, is at best a game of catch-up. For small infosec teams, the maintenance can be overwhelming.
Identifying the general case
Regular expressions (“regex”), for those not familiar with them, are pattern-matching expressions that can be used (among other things) to account for unknown variation in a character string. GreatHorn has recently added regex support for display names in our Policy Engine. Regex allow a policy to look for variants of strings that have not yet occurred in the wild, without knowing exactly how the attacker might implement the variation.
Using wildcards, alternation (“match any one of these characters”), and quantifiers (“there are between 0 and 3 spaces between these characters”), we can define a pattern to match a wide range of variants.
- Enable regex-based policies that look for common terms in display names or email content. Please reach out to GreatHorn Customer Success for any help you would like on this.
- Monitor legitimate service emails and record the sending addresses. They can be added as exceptions in your policies to prevent flagging or actions on legitimate service notifications.
- Educate staff about the specific attack type, and encourage them to attempt to confirm the legitimacy of each notification before they interact with it.
- Share with GreatHorn Customer Success any examples that are not flagged by current policies, so that we can refine policies and share improvements across our customer community.
GreatHorn customers interested in implementing a regex policy specifically for this attack type should reach out to their customer success manager.