Google Colab Automator, without Selenium!

What is this

This program creates a botnet to execute arbitrary code using multiple Google Colab VMs.

Google Colab and Qwiklabs

Google Colab is a Google service which gives free, temporary, use of virtual machines with powerful NVIDIA Tesla GPUs. Normally this is used to train ML and other AI models, but nothing impedes the use of the service for other purposes, such has password cracking with hashcat or crypto mining (at least in the free version - in Google Colab Pro crypto mining is forbidden). The downside is that the account gets temporary blocked when a too andlong intense use is detected. 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. Combining the two services, infinite temporary and disposable Google Accounts can be obtained from qwiklabs and used for mining on colab, until the qwiklabs session expires or the miner gets blocked by Colab. At such point, a new session can be started. That's basically free money. Obviously this can also be used to automated non-malicious tasks, as long as the Colab notebook is publicly available (e.g. as a github gist). After a certain time 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. I'll will look into a way of automating account creation in the future. For now, use temp mails from temp-mail.org when creating accounts

The whole exploit

1. Prepare a list of multiple Qwiklabs accounts.

2. Get temp Google account from Qwiklabs (The MAC address has to be spoofed). However, when starting a lab on qwiklabs, sometimes the website presents a captcha and prevents the user from resolving it via audio (common bypass) for the following reasons:

   • Account accessed too many times in a too little timeframe
   • Tor, common VPN providers and most free proxies are recognized and presented a captcha
   • Selenium is recognized as an automated browser session

   This problems can easily be bypassed by starting a chrome session with an empty profile, spoofing the MAC but not the IP and automating the browser session by programmatically moving mouse and keyboard. (This is done in get_account_from_qwiklabs.py)

3. Access Google Colab with the newly obtained account, start a Proxy. Google Colab doesn't get recognized as a proxy

4. Start another script, which is proxed on GColab. This will create and destroy qwiklabs accounts on the need to replace accounts that have been blocked. Restart the colab-proxy session each time to get a new ip, and spoof the mac accordingly

5. Again, get a new ip from the proxy-colab session. Now head over again to qwiklabs.com, get a new google account and use this to start any notebook. The code will be automatically executed, the needed backend (None, GPU, TPU) can be choosen

6. Every 45 minutes, get new accounts from qwiklabs to replace the ones currently is use. Always get new accounts while proxed
   
   

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)

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