A Bug in G Suite Lets Attackers Spread Malware on Your Computer

The second part from our advanced phishing series illustrates a more complex technique that makes detecting a phishing email significantly harder if you are using G Suite with Chrome. If you missed the first part of the series, check out how attackers use Google’s sites.google.com subdomain to steal your password >>

‍If you read our previous blog post and noticed what actually happened in the video, we want to challenge you again. Only this time, the illustrated attack is even harder to recognize. While in the last video, we showed how attackers steal your password, in this one, we will demonstrate how you can get malware by clicking on a link that you’d most likely identify as safe.

An unresolved bug in Google G Suite makes this attack almost impossible to detect

The bug we show you in this attack was reported to Google on December 4, 2019, by the author of this article. Google flagged the bug as “intended behavior.” Sadly, this means that the bug will continue to work. Nevertheless, we will not publish technical details on how to exploit this behavior. Note that it’s not proven that attackers are using this bug, but just like we could demonstrate a potential attack, anyone could utilize this issue to do the same to attack you. We made this video and post as we believe that you should be aware of bugs like the one we will show you in a bit so that you don’t blindly trust only technical aids.

You only have one second to notice this attack

Please watch the video before reading the script. Once you’ve watched the video and read the script, we suggest that you watch the video once again.

‍Just like the previous attack, this one also begins with the victim receiving an email. The email looks like it’d be supposedly from the company’s IT Department.If you look further, you will see that the attacker is strongly insisting that the victim install the latest update for Chrome web browser; otherwise, the browser would be unusable starting tomorrow. (Note that there is a sense of urgency in here that could ring your alarm bells.)

The attacker also provides a link to the update package, claiming that this is the correct version for the victim’s system.Hovering over the URL, we can verify that the link points to the exact same URL as it claims in the email.

Unlike in our previous article, this domain is fully controlled by Google, and nobody can replace any content on this site.Because the URL looks real, most victims would click the link, so we proceed to do that in our video.The link takes us to the same domain that is shown in the email. The browser automatically starts to download ChromeStableWIN64Update.exe.As everything seems to be in order, we click and run the .exe, which installs the latest Chrome. The installer, however, is bundled with a script that executes after the real Chrome installer and opens the default web browser which then navigates to our demo site. In real life, the script would silently run in the background to install additional malware.

Explaining how this attack could exploit a bug in Google G Suite

What really happened here? Were you able to spot the problem while watching the video? How could the attacker replace a legitimate Chrome installer from a domain that is controlled by Google with a malicious one?The attacker didn’t need to compromise Google’s domain, replace any legitimate installers, or compromise the victim’s network. The attacker simply created a special email and exploited a bug in G Suite, thus tricking the browser into showing a different domain than where the link actually leads to.After clicking the link, instead of going to cloud.google.com, the browser goes to an attacker-controlled server at storage.googleapis.com, where the malicious .exe-file is downloaded.After just a second, the browser is redirected to the original URL. The victim has about one second to notice the redirection after clicking the link. This makes the attack immensely difficult to spot and prevent.

The combination of technical bugs and social engineering make for a dangerous attack

This is just an example of a practical attack utilizing a bug that could result in spreading malware to the systems of unsuspecting users. This is a particularly dangerous attack. We are taught to validate the URL by hovering over it and then make sure we end up on a trusted domain. In this case, this is simply not enough. Despite being careful, the URL is misleading, and you could end up with a compromised installation package.

How to mitigate an advanced phishing attack when you think you can trust the URL?

To mitigate attacks like these, you need to think about whether a request like this is valid. Would your IT Department send you an email like this? Is this the normal way of communicating in your organization? What is the tone of voice of the email? Think twice about whether it could be a phishing attack. If you are unsure even for a split second, ask the sender directly as for whether the email really came from them.