Extracting the refresh token
Tudorica’s 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 employee’s local account.
If GCPW is deployed on the system, the attacker can then set out to extract the refresh token associated with the employee’s Google account. This is a special OAuth token generated by Google’s servers following a successful authentication that preserves the user’s 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 user’s 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 it’s 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’ that’s 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 Google’s OAuth API to request access tokens for various Google services in the user’s 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 user’s 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.
