Google Doc CloudPhishing Worm Attack Technical Analysis

Introduction

The Internet was buzzing yesterday over a rapidly spreading attack involving malicious apps masquerading as Google Docs which gained permission to victims’ Google Gmail accounts and extracted confidential information. Netskope considers these type of attacks as CloudPhishing, as they are significantly more sophisticated than a traditional phishing attack, and exploit the implicit trust users have in well-known cloud services. With the enterprise adoption of cloud services and user trust in them becoming more ubiquitous, using cloud services for an attack has become irresistible to hackers. Netskope Threat Research Labs has observed and published analysis of many attacks in the last year that have used cloud services.

Yesterday, Google acted very quickly and mitigated the attack, but some users had already been compromised.  Netskope Introspection customers can identify if any of their enterprise users had granted access to the malicious apps (yes, there were multiple apps) prior to Google mitigating the attack.

Additional details of previous CloudPhishing fan-out attacks detected by Netskope can be found in our original blog

How the attack worked

This attack involved only Google Gmail. A GIF animation detailing the attack was posted by a twitter user.
To start, the victim receives an email from one of their contacts who are also using Google Gmail. The subject as well as the body of the email references the sender with name and indicate that a Google document is available for viewing as shown in Figure 1.

Figure 1: Targeted nature of CloudPhishing attack.

The email arrives from legitimate Google SMTP mail servers and also from a legitimate sender, therefore it is not detected by Gmail as a phishing email as shown in Figure 2. The use of the legitimate sender name along with the content of the email make it difficult for victims to identify that it is a phishing attempt.

Figure 2: CloudPhishing message header showing use of legitimate servers

Once the user clicks on the “Open in Docs” button (link), they are taken through various HTTP redirects in the browser that eventually attempt to install a Google Gmail app developed using the Google Gmail API. Prior to asking the permission levels for the app during the installation, if the user is logged into multiple Gmail accounts or Gmail-hosted email accounts in the same browser, it would ask the user to select the Google account which they would like to grant the permission level as shown in Figure 3. As shown in the red box in Figure 3, the name of the app displayed is “Google Docs” which give the false sense of trust to the user that they are indeed installing a Google-built app.

Figure 3: Crossing the trust barrier in a CloudPhishing attack.

Upon selecting one of the accounts, the app installation process now requests several different permission levels as shown in Figure 4. As we can notice in the red box within Figure 4, the app installation is requesting access to read, send, delete, and manage the user’s email.

Figure 4: Tricking the user into granting open permissions

Once the victim has clicked “Allow” they have granted full permissions to their email account to the attackers. This complete process is typically referred to OAuth-based app installation which —  in simple terms — means granting a token to the app author without giving them the actual password. This token can then access various resources within the email account based on the granted permission levels.

Upon clicking the “Allow” button, the victim is redirected to the attacker’s website along with the respective OAuth tokens. All of the final redirects are to a php page called “g.php” on the domains listed below in Table 1.

Table 1: Domains associated with this CloudPhishing attack

The source code to the redirect page “g.php” seems to have been leaked on pastebin. The review of the code identifies the logic where the attacker is subsequently using the OAuth token to access the victim’s email account to read all the “gmail.com” contacts. Subsequently, the script sends each of the victims’ “gmail.com” contacts the phishing email again using the OAuth token. The use of legitimate OAuth token make the emails received appear legitimate and are not identified as Phishing emails by Google Gmail itself.

What makes this attack so unique?

Though the motive behind the attack cannot be ascertained at this time, it is very evident that the use of cloud technologies and also the adoption of cloud services has created a completely new vector in the ever-changing threat landscape. In this scenario, there has been no use of any malicious file for infecting, propagating, or data exfiltration. In this particular attack, all these phases have now transformed into using Google Gmail application and all the network traffic looks legitimate proving traditional network security devices incapable of protection. There is absolutely no role of endpoint security products to detect and protect against such an attack.

Another important aspect is the rise of a new class of threats leveraging OAuth protocol implementations called “Cross App Instance Grant”. As seen in the attack flow Figure 3 above, the phishing attempt that was happening on a particular Google account can transform into a user granting permissions to the app on a completely different Google App Instance. This could be the very reason that we were able to identify a number of enterprise users that used Google G Suite with their custom domains (not gmail.com) have granted permissions to this app (though as per pastebin source code mentioned above the attack was targeting only Google “gmail.com” domain email accounts).

The implicit trust that users place on the SaaS app vendor names used in various contexts such as app names, email subjects, icons, etc.  make these users so much more gullible for phishing attacks. In this particular attack, the ease with which such trust was exploited is of big concern to individual users as well as enterprises. For example using few clicks and code we were able to create and demonstrate a fake Google Drive API-based app with the name “Google Sheet” as shown in Figure 5 and 6.