In previous blogs, Supercharge Your Security Visibility with Chrome Enterprise and Google SecOps - Part 1 and Part 2 we explored how integrating Chrome Enterprise with Google SecOps can significantly enhance your security posture. We showed how Chrome event data provides valuable insights for analysis, incident response, and threat detection. But we're not done yet! Today, we are embarking on a new adventure to handle third-party API integrations in Google SecOps playbooks so we can further strengthen our security defenses. By leveraging these APIs, we can enrich Chrome Enterprise events, providing even deeper visibility into your environment and helping in critical decision-making.
Now, let's talk about Chrome extensions. We all love them, right? They make our lives easier, add fun features to our browsers, and generally just make things better. But here's the thing: extensions aren't always what they seem. Sometimes, they're up to no good.
Let's look at some real-world examples so you can see what I'm talking about:
SearchBlox: This extension pretended to be a helpful tool for Roblox players, but it actually stole their accounts and stuff they earned in the game.
Fake ChatGPT Extensions: Extension promised to make ChatGPT better. But these were just traps designed to steal Facebook login info and take over accounts.
ChromeLoader: This piece of malware hid in pirated downloads, then bombarded users with annoying ads and messed with their search results to send them to sketchy websites.
Kimsuky Spy Extension: This one was like a secret agent, reading Gmail messages without anyone knowing – even if you had two-factor authentication turned on.
Rilide: Targeting cryptocurrency users, stealing their passwords and even redirecting their money to the attacker's own wallet.
In this post, I will take the first steps through the process of integrating two powerful tools, CRXcavator and Spin.AI, into the Google Security Operations platform. These tools offer invaluable risk assessments for browser extensions, providing critical insights into potential vulnerabilities. Although there are no official integrations for either platform, We will develop our own custom integrations. This approach will enable us to utilize their APIs effectively and seamlessly retrieve risk scores for installed extensions.
First of all, we need to capture Chrome extension installation events from the Chrome Enterprise we set up in our previous blog post. To do that, we'll create a simple rule:
LinkedIn
Twitter
rule chrome_management_browser_extension_install_event {
meta:
author = "GCP Security"
description = "Chrome Management browserExtensionInstallEvent event"
type = "Alert"
data_source = "Chrome Enterprise"
platform = "GCP"
severity = "Low"
priority = "Low"
events:
$e.metadata.product_name = "Chrome Management"
$e.metadata.product_event_type = "browserExtensionInstallEvent"
outcome:
$event_type = $e.metadata.event_type
$log_type = $e.metadata.log_type
$user = $e.principal.user.email_addresses[0]
$hostname = $e.principal.hostname
$extension_id = $e.target.resource.product_object_id
$extension_name = $e.target.resource.name
condition:
$e
}
This rule focuses on Chrome Management logs, specifically looking for events where metadata.product_event_type = "browserExtensionInstallEvent" When it spots one, it grabs key details like the user, hostname, extension id, and extension name. We'll use this information later in our playbook.
Once we enable this rule, we'll get an alert every time a new Chrome extension is installed on one of our managed browsers.
As I mentioned, above there are not readily available integrations for CRXcavator or Spin.AI in the Google SecOps marketplace, however, we have the power to build our own custom integration. This allows us to directly leverage their APIs and seamlessly incorporate their risk assessment capabilities into our security playbooks. To achieve this, we will use the IDE (Integrated Development Environment) within Google SecOps.
Currently, the "Test" button isn't functional. So, to check our integration, we'll need to create a "Ping" action to see if our API endpoints are reachable. We'll do this by making direct calls to both the CRXCavator and Spin.AI endpoints and verify that we get the expected responses. This simple test will confirm that our integration is working as intended.
Use the code below:
from SiemplifyAction import SiemplifyAction
from SiemplifyUtils import output_handler
from ScriptResult import EXECUTION_STATE_COMPLETED, EXECUTION_STATE_FAILED
import requests
import json
INTEGRATION_NAME = "Browser-Extension-Check"
SCRIPT_NAME = "Ping"
@output_handler
def main():
siemplify = SiemplifyAction()
siemplify.script_name = SCRIPT_NAME # Updated to use a consistent naming convention
# Hard-coded extension ID
extension_id = "aapbdbdomjkkjkaonfhkkikfgjllcleb"
# Spin API URL
spin_url = f"https://apg-1.spin.ai/api/v1/assessment/platform/chrome/{extension_id}"
crxcavator_url = f"https://api.crxcavator.io/v1/report/{extension_id}"
# Function to perform API requests
def check_api(url):
try:
response = requests.get(url)
if response.status_code == 200:
data = response.json()
return True, data
else:
return False, f"Failed to connect, status code: {response.status_code}"
except requests.RequestException as e:
return False, f"HTTP request failed: {str(e)}"
# Check Spin API
spin_success, spin_result = check_api(spin_url)
if spin_success:
# Log response from Spin.
siemplify.result.add_result_json(json.dumps(spin_result))
# Check Crxcavator API.
crx_success, crx_result = check_api(crxcavator_url)
if crx_success:
# Log response from Crxcavator
siemplify.result.add_result_json(json.dumps(crx_result))
# Finalize results
if spin_success and crx_success:
siemplify.end("Both API checks succeeded", True)
else:
failed_message = "API Check Failed: " + "; ".join([spin_result, crx_result])
siemplify.end(failed_message, False)
if __name__ == "__main__":
main()
Let's break down this action code, which we will use to test our integration. Think of it like sending a quick "Hello!" to see if they're listening.
SiemplifyAction object named siemplify. This acts as our primary interface to interact with the SOAR platform, allowing us to log information, return results, and signal success or failure of the action.script_name attribute of the siemplify object to the constant SCRIPT_NAME defined earlier.extension_id into the URLs so that the API knows which extension to analyze.We define a reusable function check_api that takes a URL as input and performs an HTTP GET request. It then checks the response status code:
check_api Function: We define a reusable function that takes a URL as input and performs an HTTP GET request. It then checks the response status code.requests library to send a GET request to the provided URL. If the response status code is 200 (success), it parses the JSON data from the response and returns True along with the data.False along with an error message explaining the issue.check_api function for each API URL, storing the outcome (success or failure) and any data/error messages.add_result_json method from Siemplify object, making detailed information available within the SecOps platform for analysis or future actions (as we'll leverage in our next action development).end method from the siemplify object to signal that the action completed successfully. We also provide a message confirming success.By successfully executing this "Ping" action, we can confirm that our integration with the Spin.AI and CRXcavator APIs is working as expected.
In this blog, we focussed on creating the initial custom integration with Google SecOps and built our first test action. In our next blog, we'll take the foundation we've built today and expand upon it. We'll create another action script that pulls risk scores for browser extension. We'll then integrate this script into our playbook, allowing us to automatically assess the risk of newly installed extensions and take appropriate action.