Google Cloud Shell Console Automator!

What is this

This program creates a botnet to execute arbitrary code using multiple Google Shell Docker containers.

Dependencies

This program needs some dependencies to work. All of python dependencies are already installed in the venv folder. Note that for now this makes use of xephyr to create virtual desktops and for now this only works on Linux with X11 as a display manager. The packages' names will vary from distro to distro, here are the most important ones which you will need to take care by yourself

• Xephyr (xorg-xephyr)
• TKinter (tk)

Execution

First start the Account Server, from the root of the folder, open a terminal session and run

python src/qwiklabs/account_server/account_server.py

Now start the bot. From the root rolder of the project, execute

src/colab_automator.sh

it will take care of starting all the needed services in the correct order

Explanation of services and exploit

Google Colab and Qwiklabs

Qwiklabs (qwiklabs.com) is a third-party service which gives temporary Google Accounts for training in Google Cloud Shell use. Their first course (https://www.qwiklabs.com/focuses/2794?parent=catalog) is completely free, others require some in-site credits to be purchased. Google Cloud Shell is the well-know cloud computing platform by Google, just like Amazon AWS or Microsoft Azure. Unline those other two, Google Cloud Shell offers a free Console to every user, running 1vCPU of a Intel Xeon and 2GB of RAM, with some storage space. All for free, no credit card or other crap required. Also to be noted, that a reboot of the cloud shell console (especially in ephimeral mode) offers a complete new machine, with different ip and mac addresses. Combining the two services, infinite temporary and disposable Google Accounts can be obtained from qwiklabs and used to execute arbitrary code on google cloud shell console, until the qwiklabs session expires. At such point, a new session can be started and the process be repeated. After a specific number of times repeating the course, the qwiklabs account might reach it's quota for that course and a new one needs to be created. This process has already been automated but has not been implemented into the AccountServer Yet

The whole exploit

1. Prepare a list of multiple Qwiklabs accounts. The Account Server will manage those.
2. Get temp Google account from Qwiklabs (spoof mac addr? Not needed if running in docker containers). Most free proxies (tor included) are flagged as such. In order not have problems with the website presenting captchas, proxies and mac spoofing need to be left aside. Manually automating google chrome with pyautogui instead of selenium also helps
3. Access Google Cloud Shell with the newly obtained account.
4. Execute arbitrary code. The machine can also be rebooted multiple times across the same session to simulate having new machine.
5. When the session expires, start again from 2.
   

What to do when some website prevent the use of Selenium

Selenium carries some javascript and other stuff which can easily be detected by most websites - GColab and Qwiklabs included - and get the session blocked, especially if captchas are involved (There are workarounds to captchas for selenium - https://github.com/ohyicong/recaptcha_v2_solver - but often the audio captcha doesn't even get presented to the user if an automated browser session is detected). However in the current setup this is not needed, has pyautogui works wonders

The workaround: Mouse and Keyboard control

Use a plain chrome/firefox session, and automate by programmatically controlling mouse and keyboard. Basic anonimizing of the web session is still needed (spoof ip/mac, change useragent/geolocation/timezone). Actions need to be done at a human speed, or the bot could be recognized as an actual one. This type of use seems to be detected as legit enough to not even display a captcha when starting a Lab.
Mouse and keyboard are controlled using https://pyautogui.readthedocs.io/en/latest/
For simpicity, and to avoid messing up the OS by clicking on the wrong stuff, both chrome and pyautogui can be started in a separate Xephyr (https://wiki.archlinux.org/title/Xephyr) window, where they can harm no one. This also gives consistent screen coordinates to the elements on the screen: Google chrome will always be fullscreen inside Xephyr. Mouse coordinates are relative to the X server the script is started in. Using a nested X server with Xephyr requires copyq to share the clipboard with the main X server

Account Server

The idea here is to start multiple sessions from different docker containers running on the same machine. To do this, the management of Qwiklabs accounts needs to be centralized, in order to avoid having different instances of the bot crashing and stopping each other randomly. The AccountServer does just this. It's a bare metal TCP Server which dispenses accounts to the different instances of the bot when they ask.

Qwiklabs monthly subscription

There is a workaround to obtain a qwiklabs monthly subscription that actually works: https://www.youtube.com/watch?v=gF6agG9kyBs (actually works).
Tested on account i3z8qtab@xojxe.com, now it has monthly sub This is too convoluted to automated and has no use for now