Loophole allows threat actors to claim VS Code extension names

Loophole allows threat actors to claim VS Code extension names

ReversingLabs discovered a loophole in the VS Code Marketplace that allows removed extension names to be reused by different publishers, enabling malicious actors to impersonate previously removed legitimate or malicious extensions. The researchers observed a campaign delivering a downloader extension (ahbanC.shiba) that fetched a second-stage PowerShell payload to encrypt files and demand a Shiba Inu token ransom. #ahbanC.shiba #ahban.shiba

Keypoints

  • ReversingLabs found that names of VS Code extensions that have been removed (not unpublished) can be reused by other publishers, contrary to Marketplace documentation that names must be unique.
  • A March campaign used extensions ahban.shiba and ahban.cychelloworld to deliver a downloader and test-stage ransomware; a later extension ahbanC.shiba reused the name “shiba” with a different publisher.
  • The malicious extension registered a single command (shiba.aowoo) which downloaded a second-stage PowerShell script from hxxp://54[.]85[.]145[.]93/payload.ps1 or payload_linux.ps1 and encrypted files in a test folder demanding one Shiba Inu token.
  • Experimentation by RL showed unpublished extensions keep their names reserved, while removed extensions free up names for reuse, enabling name squatting or impersonation by attackers.
  • RL reproduced name reuse (e.g., Solidity-Ethereum) and noted similar behavior has been seen on other repositories like PyPI where deleted package names were re-published by different accounts.
  • Timeline analysis indicates the original ahban.* extensions were published in October and updated in March 2025; ahbanC.shiba was published March 24 and later unpublished in mid-June, meaning it could be re-published.
  • ReversingLabs recommends developers use tools like Spectra Assure Community to assess and monitor public packages and VS Code extensions to mitigate supply-chain and impersonation risks.

MITRE Techniques

  • [T1204] User Execution – The malicious extension required the user or IDE environment to execute the registered command “shiba.aowoo” which triggered the download and execution of a second-stage payload (“…Once the extension was added to VS Code IDE and this single command was called, a second malicious payload would be downloaded and run…”).
  • [T1105] Ingress Tool Transfer – The extension downloaded a second-stage PowerShell script from remote hosts to the victim environment (“…downloaded and run from hxxp[:]//54[.]85[.]145[.]93/payload[.]ps1 or hxxp[:]//54[.]85[.]145[.]93/payload_linux[.]ps1…”).
  • [T1486] Data Encrypted for Impact – The second-stage ransomware encrypted files in a test folder and demanded ransom payment in cryptocurrency (“…the script would encrypt files in test folder C:Users$env:USERNAMEDesktoptestShiba and as a ransom, demand one Shiba Inu token…”).
  • [T1609] Container and Resource Hijacking (Impersonation via Package Name Reuse) – Adversaries reused removed extension names to impersonate previously published packages, enabling distribution of malicious extensions under familiar names (“…the name of any extension that is removed from the Marketplace is in danger of being reused…”).

Indicators of Compromise

  • [URL ] second-stage payload – hxxp://54[.]85[.]145[.]93/payload.ps1 (PowerShell payload), hxxp://54[.]85[.]145[.]93/payload_linux.ps1 (Linux PowerShell payload)
  • [Extension Name ] malicious VS Code extensions observed – ahban.shiba, ahbanC.shiba (same extension name “shiba” used by different publishers)
  • [Command ] extension-trigger command – shiba.aowoo (registered command that triggers payload download)
  • [Filepath ] test encryption target – C:Users$env:USERNAMEDesktoptestShiba (folder targeted by the ransomware test-stage)


Read more: https://www.reversinglabs.com/blog/malware-vs-code-extension-names