BSidesLuxembourg 2026

Visual Studio Code is no longer just an editor; the IDE, along with its many AI powered forks, have become the most primary interface for Developers of all kind. Its extension host, a Microsoft-signed Electron process, enjoys the same blind trust from EDRs that we traditionally grant to Outlook or Teams. Meanwhile, the extension ecosystem still treats security as an after-thought: there is no deep dive source scanning, verification mechanisms are sparse, and the blue “verified” badge is cached locally – so a repackaged .vsix keeps the badge even after the payload has been swapped. The talks presents a brief case study about the various examples of malicious extensions used in the wild by threat actors and previously affected supply chains.

The talks presents the one of the first public implementation that weaponises this trust gap with a Rust-compiled, position-independent shellcode runner delivered as a Node native addon by taking a Microsoft published extension: live-server and backdooring it with a malicious extension, as well another extension with over 74M downloads. The talk also demos the following aspects of such an attack:

1. Extension-host OPSEC: delaying require("./index.node") until the user triggers the legitimate command (“Open with Live Server”) so the implant is absent from the initial process snapshot that EDRs collect.
2. Repackaging a blue-tick extension: cloning Microsoft’s own “Live Preview” repository at a signed commit, grafting the Rust addon into its webpack pipeline, and repackaging with vsce package. The resulting .vsix is byte-for-byte identical except for the extra native node – and the GUI still shows the verified badge because VS Code only re-validates signatures when enterprise policy extensions.verifySignature is set to error.
3. Going in blind - Backdooring another popular extension with our shellcode - without any prior knowledge of the source code

   All these topics would also dissect the internal workings, file structure, thread stack and other relevant information associated with the working of the loader/

Finally, the talk concludes by listing the relevant IoCs and TTPs left behind by this attack vector and discusses various detections which organisations and individuals can adopt to protect themselves.

Session Outline

1. Pre-roll (loop, 2 min before start)
   1. Screen cycles side-by-side screenshots: legitimate vs back-doored Live Preview extension.
   2. Blue tick is identical; only the “Installation” tab shows an extra 46 kB native node
   3. Caption: “Spot the implant.” (Sets the visual theme of the talk.)
2. Introductions (1 min)
   1. whoami
   2. Previous work

3. Opening – VS Code and its many forks (5 min)
   1. Rise of VS Code and it’s various forks
   2. Rise of new forks mean the rise of new market places
   3. Why target VSCode?
      • Electron renderer = Microsoft-signed, whitelisted by every EDR.
      • Marketplaces scan JS source only → native code is often a blind spot.
      • Very difficult to tell malicious extensions apart
4. Attacks in the Wild (8 mins)
   1. Previous attacks in the wild: Kaspersky, Malicious Corgi, Material Themes, Glassworm
   2. Dissecting the $500K Kaspersky malware
   3. Powershell scripts are nice - but we can do better
   4. Taking a look into Malicious Corgi
   5. Taking a looking into Glassworm’s source code
   6. Unicode is nice - compiled is nicer
   7. Pivot: “What if we go native?”

5. Node addons and demo extensions (5 mins)
   1. Introduction to node addons
   2. Compiling C++ shellcode runner compiled with node-gyp and running it with gyp
   3. Creating a “Hello world” extension and using ffi to pop a message box

6. Bringing in the crab (8 mins)
   1. Introducing neon-rs and interfacing with Javascript/Typescript
   2. Writing a shellcode runner in rust
   3. Discuss relevant changes to be made in the configs
   4. Compiling and running 

7. Backdooring a legit VS Code extension (10 mins)
   1. Choosing the target: LiveServer
   2. Updating the source to include the add-on
   3. Making webpack happy
   4. Compiling and loading the extension
   5. Visual similarities with legitimate extensions

8. Backdooring a popular VS Code extension without any prior knowledge of it’s source code (5mins):
   1. Extract the VSIX bundle
   2. Add our implant
   3. Repackage the extension
   4. Load it into VSCode
   5. Trigger shellcode execution

9. Improvements and Detections (3 mins)
   1. References to other similar works
   2. Improvements and other closing thoughts
   3. IoCs and TTPs associated with the techniques
   4. Possible detections and prevention mechanisms

      Key Takeaways
10. The audience become more aware of the dangers of blindly trusting extensions from stores
11. Malware developers and red teamers get introduced to a new and powerful vector for initial access method
12. Blue teasers can use the knowledge to prepare new rulesets and detections to avoid any such attacks