In this article, OWN-CERT presents a study at App Script, a development platform for creating add-ons to Google services used by the enterprise or automating certain actions. Through an example of persistence techniques using App Script, will illustrate the compromise chain by an attacker and the analyst's investigation possibilities. We will also explore methods for collecting and analyzing logs, along with ways to identify these malicious actions, either manually or through custom detection rules, to enhance detection and response capabilities.
Executive Summary
Google Workspace is a cloud platform designed to facilitate collaboration and communication among individuals, offering a variety of services including App Script, a development platform for creating add-ons to Google services used by the enterprise or automating certain actions.
• App Script becomes a critical service to investigate for identifying malicious activities on the platform following an account compromise.
• Real-time detection is feasible, and numerous events can serve as indicators of suspicious behaviors that analysts should verify.
• Understanding the threat, potential techniques, and investigation methods is crucial for quickly responding to an attacker: collecting logs, parsing them, and knowing what to look for.
In this article, an example of persistence techniques using App Script will illustrate the compromise chain by an attacker and the analyst's investigation possibilities. We will also explore methods for collecting and analyzing logs, along with ways to identify these malicious actions, either manually or through custom detection rules, to enhance detection and response capabilities
Introduction to Google Workspace
Google Workspace is a comprehensive suite of online tools developed by Google to promote collaboration and communication within businesses, universities, associations, and even for individuals. The suite includes various applications for communicating via email or instant messaging, managing calendars and organizing video conferences, storing and sharing files...
Google Workspace attracts businesses by offering various subscription plans with different levels of functionality depending on the chosen model, catering to startups, SMEs, or large corporations.
Many security measures are available within the environment and can be activated by administrators to secure accounts and services. These include enhancements in:
• User account security: 2FA (Two-Factor Authentication), password policy management, login session control, use of contextual access rules.
• Email security with options to activate restrictive measures on senders, creation of filtering rules, management of quarantine zones.
• File management including automatic content analysis and application of appropriate policies based on criticality level, protection against data leaks.
And what interests us most in the context of our blog post: the logs.
Many events performed on the platform generate logs which are stored online without the ability for a user, whether he is an administrator or not, to alter them by modifying or deleting them.
As a result, security teams can establish monitoring based on these sources to detect malicious behaviors within the cloud environment and respond to alerts in real-time, whether they are automatically generated by Google via the alert center (such as reclassification of emails as spam, device compromise detection...) or by security tools installed by the company like SIEM (Security Information and Event Management).
Related risks
The objective of the article is to focus on an internal lab scenario involving the compromise of a Cloud account by an attacker using a legitimate Google service in a malicious manner: App Script, a development platform for automating Google services actions.
A compromised Cloud account can have serious repercussions on the company's information system and can, in specific cases, serve as an entry point into internal systems. Key impacts include:
• Access to data: email exchange history, chat message history, access to personal Drive data, and folders shared by other teams or the company.
• Identity impersonation: posing as the victim to pivot towards other accounts, especially administrator accounts.
• Access to Cloud infrastructure: if the company uses Google Cloud Platform and a developer or admin user account is compromised, it is possible to pivot to Cloud services such as virtual machines, databases, and other implemented services.
Fortunately, most actions generate logs that can be collected to identify the actions and stop them as quickly as possible.
Compromise scenario
In the case of a compromise of a Cloud account, an attacker may recover the password using several methods, including the reuse of stolen credentials obtained through infostealers, a method that has been widely employed for some time.
In our scenario, we will play both the role of the attacker, by compromising an account and carrying out malicious actions, as well as the role of the security analyst, who will analyze the compromised account to identify malicious actions through the generated events.
We can hypothesize a compromise of a personal computer from which the employee logged into their professional account to check emails and documents. Once compromised by an infostealer, the credentials were exfiltrated via a log collection platform and then resold to other parties.
Following the detection of a suspicious login from outside, log collection and analysis were performed on the suspicious account to understand what happened and implement remediation measures. We used the "GW Forensic", an internal tool published on our GitHub to collect and analyze Google Workspace logs. The tool is available at this link: https://github.com/ownsecurity/GWForensic/.
We save time through the automatic collection and indexing of logs within the OpenSearch tool. The analyst can focus on searching for malicious traces guided by the initial automated review of events by GW Forensic.
Configuration used in this scenario:
- Suspicious login
By filtering on the "login" service, we found 3 related events during the incident timeframe:
A connection was made to the account john.doe@gwforensic.cloud at 17:29:55+02:00 from 173.44.36[.]176, located in Miami (USA) and owned by a free VPN company, while the user is located and working in France. A reauthentication occurred 22 minutes later at 17:51:37+02:00, followed by a disconnection at 18:23:11+02:00.
- File download
Shortly after the malicious login, we observed several accesses to documents located on the Drive as well as the download of numerous files:
GW Forensic automatically tagged these events as a potential exfiltration technique "Exfiltration Over Web Services".
Upon analyzing the documents on the collaborator's Drive, we found that the majority came from a folder named "pki-master":
Downloading a folder on Google Drive (right-click > Download) creates a ZIP file containing all the files and folders for the user. However, in the Workspace logs, this action generates a download event for each file, hence the significant volume observed on the graph.
- Set up of a malicious script
We notice the creation, through the "change_user_access" modification event, of a file named "Projet sans Titre" referring to a Google App Script:
It is renamed within the following minute to "curriculum_vitae.txt" to blend in with other files.
Several edits are made to the file until 18:13:49+02:00. Alongside these actions, the logs from the "token" service in Google Workspace indicate an "authorize" event related to the script name "curriculum_vitae.txt":
The event, annotated here as the "Credential Access" tactic, corresponds to granting permission to an application/script via an OAuth token to access user data: profile information, email action rights, calendar access rights, etc.
Here, the requested accesses correspond to those needed by the script within the code.
During the initial execution, the attacker manually authorized it to access certain services as shown in the pop-up:
The advantage for the attacker is that the access request only needs to be done once: the token is generated and can then be reused by the application if it is not revoked.
Nine minutes after the last execution of the “curriculum_vitae.txt “ script, a "create_script_trigger" event is generated and classified as a persistence method in the form of a scheduled task.
Through this task, the script will be able to run without notifying the user at a frequency defined by the trigger configured in the script project: every minute, every hour, daily, weekly, etc.
If the token generated for the application is revoked, the script execution will fail.
Script analysis
After gaining access rights to the script (via an administrator account), it is possible to open and access the script content:
We notice the presence of several functions within the script file:
• GetInstructions: function that retrieves instructions from a PasteBin file using the UrlFetchApp function of App Script (More information about UrlFetchApp on the Google official documentation)
• SearchDrivePattern: function that searches for a pattern inside the names of files stored on the Drive
• GetPath: function that returns the full path of a file
• SearchGmailPattern: function that searches for a pattern inside the subject or body of emails
• Main: function that calls the other mentioned functions.
The script contacts the URL configured within its “GetInstructions” function to retrieve the keywords for searching the drive and the exfiltration method. Below is the content of the retrieved Pastebin file which corresponds to the instructions that the script will follow:
We observe the following instructions:
• Search for the string patterns "project" on the Drive service, and "pass:" for the Gmail service.
• Exfiltration of the stolen data via email to a temporary email address.
Upon analyzing the script content, the following process resembles the operation of a SaaS infostealer:
The information regarding files and emails is then sent to the attacker's temporary address:
Yes, the output isn't very pretty, but it's just a proof of concept! 😀
In the triggers page of the IDE, we find the scheduled task that generated the "create_script_trigger" event:
Recommendations
To protect against the abuse of the App Script functionality, there are various methods detailed below:
Enable "Advanced Program Protection"
Google Workspace offers the "Advanced Program Protection" feature (Documentation), which can be activated on domain accounts to enhance security and prevent access to sensitive data. Enabling this feature has several consequences, such as:
• Mandatory use of 2FA (Two-Factor Authentication)
• Additional security for browsing in the Google Chrome browser, especially regarding downloads.
• Restricted access to data and services by third-party applications (via OAuth tokens)
Enable third-party app filtering
By default, each user can use their Google account on third-party applications that work via Google authentication. This allows them to grant access to their profile (name, email address) to an application for login purposes, avoiding traditional manual registration. Some applications may also access documents in Drive, such as file conversion SaaS applications like DOCX to PDF, JPEG to PDF, etc.
It is possible to enable a filtering feature or a list of authorized applications to manually approve which applications are allowed to access domain user data. This helps reduce the use of accounts on external sites and thus the risk of illegitimate access via third-party applications. App Script scripts will be blocked by default.
Monitor Google Workspace events in real time
It is possible to collect Google Workspace logs and analyze them in real time to identify suspicious events for investigation as early as possible. There are several Workspace sources: login, token, drive, calendar, users... where a significant number of events could correspond to compromise risks or malicious actions.
The GW Forensic project contains documentation with use cases to monitor and suggestions for detection based on existing events.
More information: https://github.com/ownsecurity/GWForensic/
It is possible to define SIGMA detection rules to integrate into log analysis tools like the Sekoia XDR solution. Once the Google Workspace connectors are integrated into the platform, it is possible to create SIGMA rules dedicated to Google Workspace events. In our lab, several rules have been created, including a detection rule related to the use of App Script:
Approximately 20 SIGMA rules are currently available and free to use in the GW Forensic project documentation to assist analysts in detecting malicious behaviors in real time on Google Workspace platforms.
More information: https://github.com/ownsecurity/GWForensic/
