Level 3

In the last level, we found that the attacker used the dev-account service account to download files from a bucket. Find out how the developer account became compromised.

Hint 1

To start with, we don’t have any clues to go off of, so let’s begin with the Logs Explorer once more, and query for dev-account to find related logs, if we’re lucky we’ll find a clue as to what happened in the logs.

Hint 2

One of the recent logs looks different from the others, and appears to be a custom log from a cloud function call to remove a user. One of the fields logged is authentication and it appears the developer passed his private key in the request rather than an id token. The call failed and thus the event was logged. Anyone who can view this log would be able to utilize the developer account leveraging this key.

Hint 3

Knowing that the developer account’s private key was leaked in the logs tells us that we should further examine who accessed the log to find the perpetrator. The log-viewer service account exists specifically to view logs and is our most likely perpetrator, but we can’t be sure so write a query for log-viewer.

Hint 4

The Google Cloud Platform automatically collects logging logs, logs that contain information on accesses to other logs. The most recent entry from the log-viewer is a logging log associated with the “ListLogEntries” method call. We can view the documentation for the method here:

https://cloud.google.com/logging/docs/samples/logging-list-log-entries#logging_list_log_entries-python

The documentation tells us that the method is used to list log entries for a specified logger.

Hint 5

If we go back to our query for “dev-account” and view the log containing the private key, notice that one of the fields in the log specifies the logger that made the entry: rmUser

Hint 6

If we write a final query for rmUser in the Logs Explorer, we find not only the log entry containing the private key, but also a logging log for an access to that entry, authorized using the log-viewer service account, confirming our suspicions that the attacker used the log viewer to search through the logs until he found an entry that contained a private key.

At this point, we’ve followed the trail left by the attacker reasonably far, and since logging accounts are often-times handed out frequently, further investigating how the attacker got their hands on the log viewer is not likely going to bear any fruit, and instead we should advise the company to rotate their keys regularly and sanitize sensitive information from their logs to better avoid this kind of attack(and other attacks) in the future.

As an aside, it would be good to delete the leaked dev-account private key, as well as the compromised log-viewer key in the same way we deleted the compute-admin key in level 1.