Level 1

Statuses are being made by accounts whose owners are not posting said statuses. Find out how the posts are being made, how the attackers gained the ability to use that method, and identify the service account leveraged in the exploit.

Hint 1

Referring to the system diagram, statuses are stored within a table in the database, and all communication with the database goes through the api-engine. Therefore, we should navigate to the Compute instances page of the console, and investigate the api-engine.

https://console.cloud.google.com/compute/instances?project=[project_id]

Hint 2

The best way to investigate the current state of the api-engine is to SSH into it and view the source code the VM is running. Click on the SSH button for api-engine and wait for the popup to load.

Hint 3

The VM is built from a docker container, to view the available containers, type:

Docker container ls

You should quickly notice the attacker has kindly renamed the image being used, telling us that the image has been replaced and that the VM is running exploitative code. The last field of the container should be its name, which should look something like:

klt-a6-fnld

We can open a shell within the container by entering:

docker exec -it [container_name] "/bin/sh"

Hint 4

Once in the container, simply type

cat main.py

to view the source code the VM is running.

Here you can see a list of endpoints for making requests to the database. The add user, follow user, and delete user endpoints are all expected, but at the bottom there is an endpoint labeled "hacked" which accepts any and all sequel queries, no questions asked.

We now know how the statuses were being posted to the database, but we don't know how the attacker managed to replace the VM container image. Let's close the SSH window and investigate that.

Hint 5

Navigate to the Logs Explorer and query for the VM Instance resource type. The most recent events show that the api-engine was stopped and restarted, and going back a bit, the logs show that the VM’s metadata was altered prior to the restart, likely to change the url of the image the VM boots from on startup. All of these actions were authorized through the compute-admin service account, which tells us that compute-admin is compromised.

Hint 6

We have reached the end of the level. We know that posts were being made from an endpoint added to the api-engine by the attacker, which was made possible by leveraging the compute-admin account to change the boot image for the api-engine in its metadata. In the next level, we will investigate how the attacker got access to the compute-admin account, and how they acquired the source code for the api-engine.