Weekly #5-2025 – By suktech24, Sun 9 March 2025, Estimated reading time : 9 mins
Visual Studio Code (VS Code) is one of the most widely used code editors, boasting a rich ecosystem of extensions that enhance productivity. However, this extensibility also introduces potential security vulnerabilities. Threat actors have been known to exploit VS Code extensions for 💡initial access (T1078 – Valid Accounts), persistence (Event Triggered Execution: Installer Packages), and data exfiltration (T1041 – Exfiltration Over C2 Channel) and compromise development environments. In this week blog post, the followings will be explored:
- Understanding the Threat Landscape of Malicious VS Code Extensions
- Common Attack Vectors for Malicious Extensions
- Detection Strategies for Malicious Extensions
- Sigma Rule for Detection
- Logs configuration for SIEM
- Detection Queries (ClickHouse , Splunk )
I would like to express my gratitude to Cas Van Cooten for his insightful feedback on this blog post and the Sigma rule. His detailed feedback helped me to refine the detection logic, improving accuracy and reducing false positives. Thank you! 😇
1. Understanding the Threat Landscape of Malicious VS Code Extensions
The open nature of the VS Code Marketplace allows developers to publish extensions with relative ease. While this fosters innovation, it also creates opportunities for threat actors to distribute harmful extensions. Researchers have identified malicious extensions designed to :
- Steal credentials,
- Exfiltrate sensitive files/environment variables,
- Load remote shells or execute arbitrary commands, demonstrating the risks associated with unchecked third-party code.
Supply chain compromises, such as typosquatted or hijacked extensions, further amplify risks. Compounding this issue, VS Code lacks a strict permission model—extensions inherit the same privileges as the user, enabling them to perform unauthorized actions without explicit consent.
What makes this even more dangerous is that VS Code extensions run within a trusted process (Code.exe), allowing attackers to blend malicious activity with legitimate operations. Since these extensions can execute arbitrary code, make external network calls, and spawn child processes, distinguishing between benign and malicious behavior becomes a challenge. Exploiting this, attackers craft extensions that masquerade as productivity tools while embedding backdoors, keyloggers, or other stealthy payloads to maintain persistence and evade detection.
2. Common Attack Vectors for Malicious Extensions
Attackers employ several methods to install and execute malicious VS Code extensions. Below are the key attack vectors that facilitate these attacks:
- Abusing VS Code’s Bootstrap Feature
Attack Vector: Attackers can drop.vsixextension files into the./bootstrap/extensionsfolder to have them automatically installed upon the first launch of VS Code. This method allows attackers to maintain persistence on a compromised system by ensuring that their malicious extension is installed as part of the initial setup process. - Credential Harvesting
Attack Vector: Malicious extensions are capable of intercepting sensitive development environment secrets, such as cloud credentials or API keys. These extensions often employ covert methods, like keylogging or file scraping, to access and exfiltrate critical data from developers’ machines. - Impersonation of Popular Extensions
Attack Vector: Threat actors create extensions that mimic popular ones, tricking users into installing them. This tactic exploits the trust developers place in well-known tools. Attackers often use typosquatting or brand impersonation to create fake extensions that appear trustworthy, leading users to install malicious payloads disguised as legitimate ones. - Portable VS Code Installation
Attack Vector: Attackers can exploit portable installations of VS Code by creating a./datadirectory that triggers a fresh setup, allowing them to pre-install malicious extensions. Since portable installations do not rely on traditional installation processes, attackers can bypass security measures and inject malicious extensions that automatically load when the editor is run. - Obfuscated Code
Attack Vector: Malicious extensions can hide their payloads by obfuscating the code using techniques like minification or encryption. These methods make it difficult for developers or security tools to spot the malicious content, allowing attackers to blend the malicious extension with legitimate functionality, avoiding detection. - Post-Install Scripts
Attack Vector: Extensions containing postInstall or prePublish scripts can run arbitrary commands without user interaction. These scripts may be designed to execute in the background, allowing attackers to perform malicious actions such as exfiltrating data, installing additional payloads, or compromising the environment further without requiring user consent. - Social Engineering
Attack Vector: Threat actors use deceptive tactics to trick users into manually installing malicious extensions. This can include phishing emails, fake websites, or misleading instructions. By exploiting human error, attackers bypass automated defenses and directly manipulate users into installing harmful extensions. - Supply Chain Attacks via npm Packages
Attack Vector: Malicious code can proliferate from npm packages to VS Code extensions, compromising local development environments. By targeting npm packages, attackers can inject harmful code that gets bundled with VS Code extensions. This vector can also introduce risks to broader software supply chains as the malicious code spreads across other projects that depend on these packages.
3. Detection Strategies for Malicious Extensions
Detection engineers must focus on anomalous process behavior, unexpected network activity, and suspicious extension installation patterns. Since malicious extensions operate within a legitimate process, detecting them requires behavioral and file-based monitoring:
- File System Monitoring:
- Detect the unusual creation of
.vsixfiles outside of legitimate installation sources. Monitor for the presence of a./bootstrap/extensionsfolder in an existing VS Code installation. Track writes to sensitive directories, such as%USERPROFILE%\.vscode\extensions, or credential storage locations.
- Detect the unusual creation of
- Network Telemetry:
- Identify connections to suspicious domains (e.g., dynamic DNS) initiated by VS Code or its extensions.
- Flag unusual outbound traffic from
Code.exe, especially to unknown external servers.
- Process Analysis:
- Detect suspicious child processes spawned by
Code.exe, such as PowerShell orcmd.exe. - Look for VS Code executing from non-standard installation paths.
- Detect suspicious child processes spawned by
- Integrity Checks:
- Regularly compare installed extensions with known trusted versions from the VS Code marketplace.
- Behavioral Analysis:
- Identify extensions requesting excessive permissions (e.g., wildcard
"*"inpackage.jsoncapabilities).
- Identify extensions requesting excessive permissions (e.g., wildcard
4. Sigma Rule for Detection
Based on the research from referenced source, https://casvancooten.com/posts/2025/02/abusing-vs-codes-bootstrapping-functionality-to-quietly-load-malicious-extensions/, I developed the following detection sigma rule.
Abusing VS Code Bootstrapping Functionality for Malicious Extensions
title: Abusing VS Code Bootstrapping Functionality for Malicious Extensions
id: add-id
status: experimental
description: Detects suspicious activities related to VS Code's bootstrapping functionality being used to load malicious extensions. This includes the creation of extension-related directories or files within VS Code's installation directories, potentially pointing to malicious extension loading.
references:
- https://casvancooten.com/posts/2025/02/abusing-vs-codes-bootstrapping-functionality-to-quietly-load-malicious-extensions/
- https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4688
author: sukTech24
date: 2025/03/10
logsource:
category: process_creation
product: windows
detection:
# Suspicious child processes - ONLY including processes that should never be legitimately spawned by VS Code
suspicious_process:
ProcessCreation|ParentImage|endswith: '\code.exe'
ProcessCreation|Image|endswith:
- '\wscript.exe'
- '\cscript.exe'
- '\mshta.exe'
- '\rundll32.exe'
- '\regsvr32.exe'
- '\certutil.exe'
# File creation in extension bootstap/data paths
suspicious_files:
FileCreation|path|contains:
- '\bootstrap\extensions'
- '\data\extensions'
# Detect VS Code running from non-standard locations
selection_vscode_execution_path:
ProcessCreation|Image|endswith: '\code.exe'
ProcessCreation|Image|not|contains:
- '\AppData\Local\Programs\Microsoft VS Code\' # Default user installation path
- '\Program Files\Microsoft VS Code\' # System-wide installation path via System installer
- '*\Program Files (x86)\Microsoft VS Code\*' # Nondefault installation via the System installer
# VSIX file creation by non-Code processes
vsix_creation:
FileCreation|path|endswith: '*.vsix'
# Filtering out Microsoft publisher extension
filter_microsoft_publisher:
ProcessCommandLine|contains|any:
- '*publisher="microsoft"*'
- '--publisher=microsoft'
condition:
(
suspicious_process
OR suspicious_files
OR selection_vscode_execution_path
)
AND vsix_creation
AND NOT filter_microsoft_publisher
falsepositives:
- Internal private extensions.
mitre:
tactics:
- Initial Access (TA0001)
- Execution (TA0002)
- persistence (TA0003)
- Privilege Escalation (TA0004)
techniques:
- T1195 # Trusted Relationship
- T1195.003 # Supply Chain Compromise : Development Tools
- T1071.001 # Application Layer Protocol: Web Protocols (HTTP/S)
- T1548 # Abuse Elevation Control Mechanism
- T1064 # Scripting
- T1059.001 # Command and Scripting Interpreter: PowerShell
- T1059.003 # Command and Scripting Interpreter: Windows Command Shell
level: high
5. Logs configuration for SIEM
To operationalize the Sigma rules and detect malicious VS Code extension activity, specific logging must be configured to feed relevant fields into SIEM (Splunk, ElasticSearch, OpenSearch, Google SIEM, others, etc). Focus could be on capturing process creation events, command-line arguments, and extension installation patterns. Below are the critical log sources and fields to prioritize:
5.1. SIEM Logging Requirements
| Sigma Rule | Required Logs | Key Fields |
|---|---|---|
| Abusing VS Code Bootstrapping Functionality for Malicious Extensions | – Windows Event ID 4688 (with command-line logging) – Sysmon Event ID 1 – Auditd (Linux) | ProcessCreation ParentImage FileCreation|path |
5.2. Sample Log Sources for SIEM Ingestion
| Log Type | Tool/Service | Critical Fields to Collect |
|---|---|---|
| Process Creation | Sysmon, Auditd | ParentImage, Image, CommandLine, User |
| CLI Execution | Windows Event Log | CommandLine, ProcessName, User |
| Network Connections | Firewall/Proxy | SourceIP, DestinationIP, Domain, UserAgent(These fields are useful for further investigation) |
| File System Changes | File Integrity Monitoring (FIM) | FilePath (e.g., %USER%\.vscode\extensions) |
6. Detection Queries (ClickHouse)
These examples are indicative and assume proper log ingestion/normalization. Field names (e.g., ParentImage vs parent_process_path) may vary depending on your SIEM’s schema.
Abusing VS Code Bootstrapping Functionality for Malicious Extensions
ClickHouse SQL
| WHERE ( — Suspicious child processes – ONLY including processes that should never be legitimately spawned by VS Code ( (ProcessCreation_ParentImage ILIKE ‘%code.exe’) AND multiSearchAnyCaseInsensitive (ProcessCreation_Image, [ ‘wscript.exe’, ‘cscript.exe’, ‘mshta.exe’, ‘rundll32.exe’, ‘regsvr32.exe’, ‘certutil.exe’ ] ) ) — Suspicious file creation in bootstrap/extension paths OR multiSearchAnyCaseInsensitive(FileCreation_path, [ ‘\\bootstrap\\extensions’, ‘\\data\\extensions’ ] ) — Detect VS Code running from non-standard locations OR ( ProcessCreation_Image ILIKE ‘%code.exe’ AND NOT multiSearchAnyCaseInsensitive ( ProcessCreation_Image, [ ‘\\AppData\\Local\\Programs\\Microsoft VS Code\\’, ‘\\Program Files\\Microsoft VS Code\\’, ‘\\Program Files (x86)\\Microsoft VS Code\\’ ] ) ) ) AND FileCreation_path LIKE ‘%.vsix’ AND NOT multiSearchAnyCaseInsensitive(ProcessCreation_CommandLine, [ ‘publisher=”microsoft”‘, ‘–publisher=microsoft’ ] ) NOTE: ==> Could start with a single message detection and then tune it where needed or turn it into aggregation detection. ==> Could try using different ClickHouse functions to ensure optimised search performance. |
Splunk Query
| TBAdded |
Conclusion
While VS Code’s extensibility offers significant benefits, it also introduces security challenges. By understanding the threat landscape and implementing robust detection and prevention strategies, developers and organizations can safeguard their environments against malicious extensions.
Glossaries
- cmd.exe
- Cmd stands for Windows Command Processor
- Starts a new instance of the command interpreter, Cmd.exe. If used without parameters, cmd displays the version and copyright information of the operating system.
- code.exe
- Code.exe is the executable file for Visual Studio Code, a free source-code editor made by Microsoft. This file is typically located in the directory C:\Users\USERNAME\AppData\Local\Programs\Microsoft VS Code. When you run Visual Studio Code, you’re essentially running the Code.exe file.
- cscript
- Starts a script to run in a command-line environment.
- certutil.exe
- Certutil.exe is a command-line program installed as part of Certificate Services. You can use certutil.exe to display certification authority (CA) configuration information, configure Certificate Services, and back up and restore CA components. The program also verifies certificates, key pairs, and certificate chains.
- mshta.exe
- Mshta.exe is a Windows-native binary designed to execute Microsoft HTML Application (HTA) files. As its full name implies, Mshta can execute Windows Script Host code (VBScript and JScript) embedded within HTML in a network proxy-aware fashion. These capabilities make Mshta an appealing vehicle for adversaries to proxy execution of arbitrary script code through a trusted, signed utility, making it a reliable technique during both initial and later stages of an infection.
- powershell.exe
- Windows PowerShell is a task-based command-line shell and scripting language designed especially for system administration. Built on the .NET Framework, Windows PowerShell helps IT professionals and power users control and automate the administration of the Windows operating system and applications that run on Windows.
- regsvr32.exe
- regsvr32 (Register Server) is a command-line utility in Microsoft Windows and ReactOS for registering and unregistering DLLs and ActiveX controls in the operating system Registry. Despite the suffix “32” in the name of the file, there are both 32-bit and 64-bit versions of this utility (with identical names, but in different directories).regsvr32 requires elevated privileges.
- rundll32.exe
- Loads and runs 32-bit dynamic-link libraries (DLLs).
- Rundll32.exe is a Microsoft-signed binary used to load dynamic link libraries (DLLs) in Windows. It is native to Windows and present in both 32 and 64 bit versions, respectively present in these places:
- C:\Windows\System32\rundll32.exe
- C:\Windows\SysWOW64\rundll32.exe
- vsix – vistual studio extension installer
- A VSIX package is a
.vsixfile that contains one or more Visual Studio extensions, together with the metadata Visual Studio uses to classify and install the extensions. That metadata is contained in the VSIX manifest and the [Content_Types].xml file. A VSIX package may also contain one or more Extension.vsixlangpack files to provide localized setup text, and may contain additional VSIX packages to install dependencies.
- A VSIX package is a
- wscript
- Windows Script Host provides an environment in which users can execute scripts in various languages that use various object models to perform tasks.
References
- Abusing VS Code’s Bootstrapping Functionality To Quietly Load Malicious Extensions, https://casvancooten.com/posts/2025/02/abusing-vs-codes-bootstrapping-functionality-to-quietly-load-malicious-extensions/
- VSCode extensions with 9 million installs pulled over security risks, Bill Toulas, February 26, 2025, https://www.bleepingcomputer.com/news/security/vscode-extensions-with-9-million-installs-pulled-over-security-risks/
- Malicious helpers: VS Code Extensions observed stealing sensitive information, https://www.reversinglabs.com/blog/malicious-helpers-vs-code-extensions-observed-stealing-sensitive-information
- Extension runtime security, https://code.visualstudio.com/docs/editor/extension-runtime-security
- Can You Trust Your VSCode Extensions?, https://www.aquasec.com/blog/can-you-trust-your-vscode-extensions/
- Abusing VSCode: From Malicious Extensions to Stolen Credentials (Part 1), https://control-plane.io/posts/abusing-vscode-from-malicious-extensions-to-stolen-credentials-part-1/
- wscript.exe, https://lolbas-project.github.io/lolbas/Binaries/Wscript/
- cscript.ext, https://lolbas-project.github.io/lolbas/Binaries/Cscript/
- mshta, https://redcanary.com/threat-detection-report/techniques/mshta/
- Rundll32: The Infamous Proxy for Executing Malicious Code, written By Cybereason Blue Team, https://www.cybereason.com/blog/rundll32-the-infamous-proxy-for-executing-malicious-code
- Regsvr32.exe, https://lolbas-project.github.io/lolbas/Binaries/Regsvr32/


Leave a comment