Cloud Hosting

Attackers are always looking for new ways to expand their access inside corporate networks once they hack into a machine or a user account. Recent research by security firm Bitdefender shows how attackers can gain access to Google Workspace and Google Cloud services by stealing access tokens and even plaintext passwords from compromised Windows systems that have the Google Credential Provider for Windows (GCPW) tool deployed. These credentials can be used in different attack scenarios to steal cloud-hosted data or to move laterally to other accounts and systems inside a network.

While organizations might monitor their Active Directory (AD) environments for known lateral movement techniques that have become a staple of attacks by both state-sponsored cyberespionage groups and ransomware gangs, they can have a blind spot when it comes to cloud-based services that are increasingly integrated with local networks as part of hybrid environments.

Organizations that use Google Workspace (formerly G Suite) for enterprise productivity can deploy GCPW on their Windows 10 and Windows 11 computers in order to sync Google accounts with their local Active Directory and enable a single sign-on (SSO) experience for their users. When deployed, the tool registers itself as a Credential Provider in the Windows Local Security Authority Subsystem Service (lsass) which handles authentication on Windows systems, allowing users to use their Google account credentials for local authentication instead of having separate accounts for the AD environment and Google Workspace.

Companies with certain Google Workspace subscriptions can also deploy Googles device management solution for Windows which will use GCPW for authentication and device enrolment. In such a setup, the device management component can be used to push custom Windows configurations and policies, to manage Windows updates, enable BitLocker drive encryption, remotely wipe devices and more.

According to Radu Tudorica, a Bitdefender security researcher who presented the GCPW attack scenarios last week at the DefCamp 2023 security conference in Bucharest, an attacker who obtains admin privileges to an organizations Google Workspace with device management enabled can deploy a download and install policy that pushes a malicious payload to all managed systems. This is similar to how attackers typically push ransomware to an organizations systems after compromising the networks domain controller.

Lateral movement could also potentially extend to the organizations Google Cloud Platform (GCP) account which significantly increases the attack surface by providing access to storage buckets and source code repositories.

Tudoricas scenario begins like most malware attacks, with a spear-phishing email sent to an employee from a targeted organization and impersonating a business associate for added credibility. The email carries a malicious attachment which, if executed, deploys a malware implant that provides the attacker with remote access to the Windows machine with the privileges of the employees local account.

If GCPW is deployed on the system, the attacker can then set out to extract the refresh token associated with the employees Google account. This is a special OAuth token generated by Googles servers following a successful authentication that preserves the users active session for a limited time, preventing the need to re-authenticate when accessing a Google Workspace service.

GCPW stores the refresh token in two locations: Temporarily in the system registry and later in the users profile in the Google Chrome browser. The token is stored in encrypted form in both instances, but its decryption is trivial with a tool like Mimikatz or by calling the Windows CryptUnprotectData API from the same user and machine that was used to encrypt it. In other words, this encryption is only meant to protect the token if its copied and transferred to another machine.

Extracting the token from the system registry is stealthier than from inside the browser profile because security products typically flag attempts by external processes to read browser data as suspicious. The downside is that the token is only temporarily available in the registry before being moved to the browser, but this can be overcome by modifying another value called 'the token handle' thats stored by GCPW inside the registry. If this value is modified, GCPW will think the session is invalid and will force the user to re-authenticate, placing a new refresh token temporarily in the registry.

The refresh token can be used through Googles OAuth API to request access tokens for various Google services in the users name, providing the attacker with access to data stored in those services and their various functionalities. This form of API access does not require multi-factor authentication (MFA) even if the account has it enabled because the refresh token is issued after a successful authentication is already completed, which includes the MFA step.

Depending on the users privileges in the Google Workspace environment the attacker can access their Google Calendar, Google Drive, Google Sheets, Google Tasks, some information about their email address and user profile, their Google Cloud Storage and Google Cloud Search, data stored in Google Classroom and more. If the employee happens to be a Workspace administrator, they can also gain access to user provisioning in the Google Directory and the Vault API, an eDiscovery and data retention tool that allows the exporting of all emails and files for all users within an organization. And if device management is enabled, an admin account can also be used to abuse its features.

Its worth noting that tokens can only be used to access services through APIs, but not all Google services or all their features are available through APIs. Some can only be accessed through web-based interfaces in the browser. In that case, an attacker might need the users actual plaintext password instead of just the GCPW refresh token to abuse those services and features. The plaintext password could also potentially enable access outside of Googles ecosystem if its reused.

Tudorica and his team found that GCPW stores the users password locally in encrypted form to allow for password recovery operations, a feature thats enabled by default. Unlike refresh tokens, locally stored passwords are encrypted with keys that are stored on Googles servers. However, the encryption keys can be retrieved through an undocumented API service if the attacker has the necessary local access (SYSTEM privileges) to extract a unique ID from the Windows Local Security Authority (LSA) store and then uses the GCPW refresh token to generate an access token for that undocumented API.

If the compromised account doesnt have administrator privileges in Google Workspace, the attacker can still use it to extract data such as shared files, identify administrators and then target them by using the compromised account. For example, the attacker could attach malicious macros to a document and then share it with an administrator in the hope they will open it on their computer to install a malware implant.

If an administrator account is compromised, the attacker could use it to create a shadow admin account in the Workspace environment for persistence purposes and then give it access to the organizations resources on Google Cloud Platform as well. If for example the organization develops software and hosts its apps and code on Google Cloud, this level of access could enable backdoors being pushed into production code and software supply chain attacks. At the very least it could lead to a compromise of sensitive business data stored in the organizations cloud-hosted apps or to a ransomware-style attack of GCP data through the customer-supplied encryption keys (CSEK) feature.

Bitdefender reported the refresh token and password decryption issues to Google, but since exploiting them requires a local device to be compromised, they fall outside of the threat model for Chrome data storage and are therefore not considered security vulnerabilities.

Dont treat cloud services as being inherently secure, Tudorica said. "Think of them as Active Directory, and while you dont have something to patch, you still need to set up reasonable access permissions for everyone. Also be very careful with integrations that appear to make your life easier but can also make it harder if they are compromised, and set up monitoring and alerts for absolutely everything," he said.

Additional details are available in a Bitdefender technical write-up published ahead of the conference.

See the article here:
Attackers could abuse Google's SSO integration with Windows for lateral movement - CSO Online