Attackers can exfiltrate company data stored in Google Cloud Platform (GCP) storage buckets without leaving obvious forensic traces of the malicious activity in GCP’s storage access logs, Mitiga researchers have discovered.
GCP data exfiltration attack (Source: Mitiga)
Covert data exfiltration from GCP buckets
In short, the main problem is that GCP’s basic storage logs – which are, by the way, not enabled by default – use the same description/event (objects.get) for different types of access, for example: reading a file, downloading a file, copying a file to an external bucket/servers, and reading the file/object metadata.
“In normal usage, files (or objects) inside storage objects are read multiple times a day as part of day-to-day activity of the organization,” Mitiga cloud incident responder Veronica Marinov noted.
“This could easily lead to thousands or millions of read events. Not being able to identify specific attack patterns such as download or copy to external bucket, makes it exceedingly difficult for the organizations to determine if and which information has been stolen.”
She also detailed an example of a possible attack, which hinges on the threat actor gaining control over an employee’s GCP user account belonging to the targeted organization, then granting that account permission to copy data to the threat actor’s GCP organization by entering a simple command into Google’s command line.
Issue mitigation and threat hunting steps
Both Mitiga and Google’s security team don’t consider this to be a vulnerability, but a “security deficiency.”
“After contacting Google’s security team and working with them on this issue we have compiled together a list of steps that can be done to mitigate and detect this attack,” Marinov added.
Those steps include defining (via VPC Service Controls) a service perimeter around resources of Google-managed services to control communication to and between those services and using organization restriction headers to restrict cloud resource requests made from their environments.
“In case neither VPC Service Controls nor Organization restriction headers are enabled we suggest searching for the following anomalies: anomalies in the times of the Get/List events, anomalies in the IAM entity performing the Get/List events, anomalies in the IP address the Get/List requests originate from, and anomalies in the volume of Get/List events within brief time periods originating from a single entity.”
Finally, admins can also restrict access to storage resources and consider removing read/transfer permissions.
It’s unclear why Google choses not to differentiate between the different types of access in the logs when (for example) AWS does.