- What: Use of Visual Studio Code extensions in red team engagements
- Impact: Potential for misuse in security testing
Our best in class red team can deliver a holistic cyber attack simulation to provide a true evaluation of your organisation’s cyber resilience. Leverage the team behind the industry-leading Web Application and Mobile Hacker’s Handbook series. MDSec’s penetration testing team is trusted by companies from the world’s leading technology firms to global financial institutions. Our certified team work with customers at all stages of the Incident Response lifecycle through our range of proactive and reactive services. MDSec’s dedicated research team periodically releases white papers, blog posts, and tooling. MDSec’s training courses are informed by our security consultancy and research functions, ensuring you benefit from the latest and most applicable trends in the field. View insights from MDSec’s consultancy and research teams. 28/05/2026 A few years ago we looked at how Visual Studio Code extensions could be used forinitial access in red team engagements; at the time, the results were quite scary. Fast forward three years and we now have GitHub being hacked by acompromised VS Code extension. In light of the GitHub hack, we felt it might be prudent to take a peak beneath the curtain of Code’s big brother, Visual Studio. Given the rise of extension malware, and three years have passed since our last post, you would have hoped it was enough time for Microsoft to sort this ecosystem out. If you just want the spoiler and don’t want to read on, the TLDR is it’s as much of a dumpster fire as ever. Visual Studio extensions come typically in one of two flavours: We’re going to focus on building aVisualStudio.Extensibilityextension, which Visual Studio kindly provides a template for: The extension template provides relatively straightforward code that targets net8.0 and simply pops a message box on demand: When deployed, the new extension registers a new command that eventually runsExecuteCommandAsyncon-demand (i.e. when the extension is selected from the Extensions menu item): While that in itself is useful to prove our extension works, we may want something more incognito for a red team engagement. To do this, we can register a new listener in our extension. Microsoft’sdocssay there are two types of text view listeners:ITextViewChangedListenerandITextViewOpenClosedListener; together they observe opening, closing, and modification of text editors. Using theITextViewOpenClosedListenerlistener we can create an extension that automatically triggers any time a file is opened in Visual Studio. In this case, we filtered the trigger to apply on opening files with the JSON extension and for bonus points actually implemented a JSON formatter: To add a little spice to the extension, we turned it in to a remote assembly loader by adding the following toTextViewOpenedAsync: And implementing some basic reflection code to fetch, decode and execute the entrypoint of an encoded and remotely hosted assembly: Debugging the extension and having it retrieve a remote assembly which simply did the following: We can see that, at least in our development environment, we’re able to fetch and run remote assemblies to get out of process execution insideServiceHub.Host.Extensibility.arm64.exe: