“Your desktop gets scanned for trojan back doors. But what about the backdoors in your cloud?”
If your organization’s cloud accounts have been compromised, how would you know? As an administrator, you might look for suspicious logins from distant countries or excessive user activity like a massive download or large email blast. While we still see such behavior, today’s cloud attacks are seldom so obvious.
The security world is familiar with the Remote Access Trojan (RAT), a silent app or other back door designed to gather data or run arbitrary code on a desktop or server. A Cloud Access Trojan (CAT), similar to their desktop counterparts, offers a silent backdoor to the attacker, but take on an entirely different form, unique to the cloud. Instead of wayward code running on a machine, these are cloud apps or configuration changes that live outside your cloud provider’s scope of responsibility.
While you are probably running one of the many software tools right now designed to find and remediate desktop threats, the tools to discover a Cloud Access Trojan are limited, especially if you are managing multiple services.
One of the first things we do when deploying a new customer account is look for signs of a previous breach or ongoing CAT activity. Some are merely security holes created by well-meaning employees, but others are sure signs of an attacker embedded inside the organization’s cloud.
Because the original breach happened long ago, we may not know how the attacker originally gained access, but these are the most common signs of a previous attack. What these have in common is that each can be deployed in an instant, continue unnoticed for months or years, and eliminate the need for the attacker to ever log in again.
Fileshare Cloud Access Trojans
Wayward Share: share a company directory with an external address.
It is quite common for users to share a folder with a client or partner for collaboration and then forget it for months or years. It is just as easy for an attacker to share a single high-level directory with an external address in order to have complete read-write access to every file and folder inside. Once created, these shares can offer continuous access and can be used to exfiltrate data or infect commonly-used files with malware. Whether created by a well-meaning employee or a malicious hacker, they act as a silent back door to your files.
Synchronized App: connect a desktop client to get real time access to your files.
Every file sharing service offers a desktop sync application that will download and update company files with a desktop computer. Few administrators monitor these connections. It could be a hardworking employee that has connected their home-office PC or an attacker maintaining a local copy of every file on their desktop. Because desktop apps don’t log in, per se, but connect via a single OAuth token, an attacker can used stolen credentials to authenticate a desktop app once and never need to use the password again.
Unauthorized Cloud Backup: a copy of your files stored in the wrong hands.
Dozens of third party tools offer cloud-to-cloud backup of your Box, OneDrive, Amazon S3, or other file sharing account. These services take advantage of the high-bandwidth connections between providers to securely duplicate every file to their servers, but under an attacker’s control. While maintaining backups are a great idea, only you should have access to the copies.
Email Cloud Access Trojans
Fast Forwards: every incoming and outgoing email forwarded to an unauthorized account.
While it can be a terrible security violation, we often see users setting an email forwarding rule to send a copy of every email to their personal email account. This is also a common trick for hackers, because unlike hidden mailbox techniques that require the attacker to log in, this rule can be set very quickly, requires no additional login, and can go completely unnoticed by the user or administrator.
Email Server Authentication: granting IMAP, POP or SMTP access to an outside client.
While Gmail and Outlook normally require multi-factor authentication, they offer backward compatibility for the relatively insecure mail protocols IMAP, POP, or SMTP by allowing the user to enable ‘less secure apps.’ A user might enable an IMAP connection to use their favorite phone app, but an attacker might also use it to take invisible control of a user’s email account, bypassing multifactor authentication. It is even possible for an attacker to configure their own mail client to send via your SMTP servers. Because these types of mail connections happen a million times a day, they are almost never logged or analyzed.
Application-specific Passwords: they bypass multi-factor authentication and never change
In order to support older email apps, both Google and Office 365 offer “application-specific passwords.” These are separate and permanent login passwords that bypass multi-factor authentication and grant the same access as the user’s own credentials. These connections are ‘invisible’ to the user and never expire, even if the they change their own password. While designed for legacy email access, they can actually be used for most any type of connection, legitimate or nefarious.
API-based Cloud Access Trojans
Like application-specific passwords, API-based connections are a separate way to connect to a user’s account that do not need secondary authentication and never expire, even if the user changes their password.
The cloud is built upon APIs. Every SaaS provider offers some type of application-level connectivity that can grant another service access to a user’s account to share data or offer greater functionality.
While the previous attacks may seem simpler for an attacker to deploy, getting a user to authenticate a malicious API is deceptively easy. The attacker never needs the user’s credentials and never needs to log in, and therefore has permanent and invisible access to the user’s account.
Malicious SaaS Applications
It is quite common for a user to connect a company account to a third party app to add functionality. It could be something as simple as installing a charting tool from the Office AppSource or granting sharing access to LinkedIn so they can synchronize their contacts. Unfortunately, granting this wide-ranging access to API-based apps has made it easy for attackers to create their own SaaS services and convince users to grant more access than they should.
Malicious Mobile Apps
Similarly, users commonly download apps to their mobile devices and grant them access to their cloud accounts. Thousands of malicious apps, with millions of downloads, have appeared in the Apple and Android App stores. These copy-cat apps that might ask a user for access to their SaaS accounts and even if they offer a few legitimate features, they might request and use more access than they need.
Creating a nefarious SaaS application or mobile app can be difficult, but an API attack can be as simple as a script that runs in the user’s browser. Last year’s Google Docs attack was just such a script—simple yet powerful. API scripts can be used to perform many of the configuration changes described above, making it possible for the attacker to create a backdoor configuration in a single stroke, all without needing to log in to the account.
Cloud Breach Detection
No matter how much security we deploy to prevent an attack, we must assume that somehow, some way, a breach has already happened.
In the same way that we monitor our desktops, we must also monitor our cloud apps for signs of a previous breach:
- Scan every file for malicious code
- Look for insecure configurations or connections that can offer a backdoor to the system
- Monitor user and application activity in real-time to look for attack behavior
Avanan partnered with the industry’s most advanced security companies to provide best-of-breed attack prevention for the cloud, but prevention is never fool-proof.
In addition to our attack prevention, we developed our own suite of cloud-specific tools to identify post-attack behavior that blocks attacks in real time sand identifies embedded Cloud Access Trojans that were deployed months before.