To develop a malicious extension in\u00a0VS Code<\/b>\u00a0we need to set up a suitable development environment. It should have the following elements:<\/p>\n
\u2022\u00a0Node.js<\/b>
\n\u2022\u00a0Visual Studio Code<\/b>
\n\u2022\u00a0Git<\/b>
\n\u2022\u00a0Visual Studio Code Extension Generator<\/b><\/p>\n
Once these steps are completed, you will have a development environment set up and ready to start developing the extension.<\/p>\n
Developing the malicious extension<\/span><\/p>\n With the development environment set up, the next step is to develop the malicious extension. All the code for our extension will be in the\u00a0extension.ts<\/b>\u00a0file, which contains the code base generated by the\u00a0VS Code<\/b>\u00a0extension creation wizard. Initially, this file includes a simple example that displays a\u00a0“Hello World from color-picker!”<\/b>\u00a0message when the helloWorld command is invoked.<\/p>\n To transform this extension into a malicious tool, we will make some key modifications. The idea is to execute a reverse shell when the user invokes a specific command within VS Code. This is achieved by modifying two main files:\u00a0package.json<\/b>\u00a0and\u00a0extension.ts<\/b>.<\/p>\n In\u00a0package.json<\/b>, we will configure a command that behaves like a legitimate extension, similar to a tool commonly used by developers and designers, such as a\u00a0“color-picker”<\/b>. This configuration will allow us to execute our malicious code without arousing suspicion.<\/p>\n Then, in extension.ts, we will add the necessary code to execute a reverse shell. This code will be executed when the malicious command is invoked. To test that everything works correctly, we will use the VS Code debugging tools, which allow us to run and test the extension directly from the development environment.<\/p>\n Before implementing the malicious code, it is essential to make sure that the basic configuration of the extension works correctly. To do this, we will first test the extension with the code base provided by the wizard. This verification step is crucial because we make sure that the basics are working, otherwise we might encounter problems later on and incorrectly assume that the failure is due to the added code, when in fact it could be a problem with the initial configuration.<\/p>\n To perform this verification, we must run the extension with the small modifications applied. This is done from the\u00a0VS Code<\/b>\u00a0development environment using the built-in debugging tools. We will go to the “Run” menu option and select\u00a0“Start Debugging”<\/b>. This process will open a new instance of\u00a0VS Code\u00a0<\/b>where we can test the extension.<\/p>\n In this new instance, we will press the keyboard shortcut\u00a0ctrl+shift+p<\/b>\u00a0to open the command palette and select our extension command. If everything works correctly, we should see the message\u00a0“Hello World!”<\/b>\u00a0displayed in the\u00a0VS Code<\/b>. interface. This step confirms that the basic configuration is operational and provides a checkpoint before entering the malicious code.<\/p>\n Once we have verified that the basic configuration works, we can proceed to enter the reverse shell code in\u00a0extension.ts<\/b>\u00a0and modify the default command. This code will take care of establishing a remote connection to our attacking system every time the malicious command is executed.<\/p>\n Finally, to ensure that the remote connection is successful, we will listen to our remote system (in this case, a machine with\u00a0Kali Linux<\/b>) and run the extension from the victim machine (Windows 11<\/b>). The IP of the attacking machine is\u00a0192.168.1.135<\/b>\u00a0and corresponds to our Kali on the local network that will receive the connection:<\/p>\n We listen to our\u00a0Kali\u00a0on port\u00a04444\u00a0and run the extension again from our Windows 11 victim:<\/p>\n <\/b><\/p>\n Press F5 to launch a new debug instance in\u00a0VS Code<\/b>. In this new instance, we use the keyboard\u00a0ctrl+shift+p<\/b>\u00a0to open the command palette and execute the malicious extension command. Upon doing so, the connection is successfully established, allowing us to gain access to the\u00a0Windows 11<\/b>\u00a0system from our\u00a0Kali Linux<\/b>. machine. This is possible thanks to the execution of the reverse shell code we have embedded in the malicious extension, which demonstrates the effectiveness of the technique and underscores the importance of understanding and mitigating these risks in corporate environments.<\/p>\n Post-Exploitation and Persistence<\/span><\/p>\n Once we have gained access to the target system via our malicious extension, the next step is to ensure persistence and perform post-exploitation activities. This will allow us to maintain access even if the machine is rebooted and perform additional actions to further explore and compromise the system.<\/p>\n For post-exploitation, we will use\u00a0powershell-empire<\/b>, a powerful\u00a0post-explotaci\u00f3n\u00a0<\/b>tool that allows attackers to execute commands and scripts on compromised systems remotely. First, we configure the\u00a0powershell-empire server<\/b>\u00a0on our attacking machine, which will allow us to manage and control the agents running on the compromised systems. On another terminal, we run the\u00a0client<\/b>, which we will use to interact with the server and configure our\u00a0listeners and stagers<\/b>.<\/p>\n The next step is to create a new listener in the\u00a0powershell-empire<\/b>. client. This listener is a component that waits for incoming connections from agents. We configure the listener with the necessary parameters, such as host and port, so that it is ready to receive connections. With the listener configured, we proceed to create a\u00a0PowerShell<\/b>. payload. This payload, once executed on the compromised\u00a0Windows 11<\/b>\u00a0system, will establish a connection back to the listener, registering itself as a new agent and allowing remote control of the system.<\/p>\n Now, we will proceed to create the PowerShell payload that we will run on the\u00a0Windows 11<\/b>\u00a0system already compromised by the malicious extension. We generate this payload by following a series of specific commands that will allow us to configure the stager that will communicate with the listener we have previously set up.<\/p>\n First, in the\u00a0powershell-empire<\/b>client interface, we enter the main menu and select the\u00a0multi\/launcher<\/b>\u00a0stager. This stager is a versatile option that allows us to configure several parameters to establish the connection back to the listener. We configure the listener by specifying the type we have previously created, in this case,\u00a0http<\/b>, and set the necessary properties, such as the host and port where our listener is waiting for connections.<\/p>\n UOnce configured, we run the command to generate the payload. This will be a PowerShell script that, when run on the compromised Windows system, will establish a connection back to the listener and register a new agent in\u00a0powershell-empire<\/b>. This agent will provide us with remote control over the compromised system, allowing us to perform a wide range of post-exploitation actions.<\/p>\n After generating the payload, we run it on the compromised\u00a0Windows 11\u00a0<\/b>system, leveraging the reverse shell session we have established with our malicious extension. Upon executing the payload, we verify that the agent is correctly registered in the listener and appears in the\u00a0powershell-empire<\/b>\u00a0client interface. This step is crucial to ensure that our configuration is correct and that the compromised system is now under our remote control.<\/p>\n With the agent registered and active, we can proceed to use the available post-exploitation modules to perform additional activities, ensuring that our access to the compromised system is durable and stable.<\/p>\n As you can see below, on the\u00a0Windows 11, VS Code<\/b>\u00a0is not running. This is possible because, once the agent has been successfully registered through the post-exploitation framework, we no longer need to keep the editor open. Access and control over the compromised system is maintained regardless of the state of the application.<\/p>\n This shows that once the agent has successfully registered, it is not necessary to keep\u00a0VS Code<\/b>\u00a0open to maintain the connection. However, it is important to note that if the machine is restarted, we will lose the connection, as the agent will not persist unless we configure a proper persistence technique.<\/p>\n Next, we proceed to establish persistence on the compromised system. We use the\u00a0powershell_persistence_userland_registry<\/b>\u00a0module that allows us to set persistence in the Windows registry. This module creates an entry in the registry that will execute our payload every time the user logs in. We configure and run the persistence module, making sure that the payload runs automatically on every system restart.<\/p>\n We can confirm that the persistence has been successfully established when we see the message: “Registry persistence established using listener http stored in HKCU\\Microsoft\\Windows\\CurrentVersion\\Debug<\/b>“. This message indicates that the persistence module has been successfully created in a Windows registry entry.<\/p>\n This persistence technique involves storing the payload in a registry key located at\u00a0HKCU:Software\\Microsoft\\Windows\\CurrentVersion\\Debug<\/b>, which ensures that the PowerShell script is automatically executed every time the user logs on to the system. By setting this registration key, we ensure that the agent re-registers with the listener even after the computer is rebooted, thus maintaining remote access to the compromised system persistently.<\/p>\n We will try rebooting the compromised Windows to confirm persistence. Once the system has rebooted, we will check if a new agent is automatically registered in\u00a0powershell-empire<\/b>. This step is crucial to ensure that the implemented persistence technique is working correctly and that our remote access to the compromised system is durable.<\/p>\n Each time we reboot, a new agent will register, indicating that the\u00a0PowerShell<\/b>\u00a0payload stored in the Windows registry is automatically executed at user logon, reconnecting the compromised system with our listener.<\/p>\n With persistence confirmed, we can start playing with some\u00a0powershell-empire<\/b>\u00a0commands to explore and get more information from the compromised system. For example, we can use the\u00a0powershell\/situational_awareness\/host\/computerdetails\u00a0<\/b>module to collect system details. This module will provide us with valuable information about the hardware and software of the compromised system, including the computer name, operating system version and more.<\/p>\n We can perform a port scan on the network using the\u00a0powershell\/situational_awareness\/network\/portscan<\/b>\u00a0module. This module allows us to scan for open ports on specific devices within the compromised system’s network. We configure the module to scan a particular host, for example,\u00a0raspberrypi.local<\/b>, and run the scan command. This type of scan helps us identify other devices and services accessible on the network, which may be potential targets for future attacks or entry points for lateral movement within the infrastructure.<\/p>\n These post-exploitation steps, along with persistence verification, not only allow us to maintain continuous access to the compromised system, but also to expand our knowledge and control over the environment, facilitating broader and more effective exploitation.<\/p>\n Conclusion<\/span><\/p>\n Exploring and demonstrating how to develop a malicious extension for\u00a0VS Code<\/b>\u00a0allows us to better understand the risks associated with installing extensions and underscores the importance of security in development environments. Through environment configuration, extension development, and post-exploitation and persistence techniques, we have evidenced potential vulnerabilities that can be exploited by malicious actors.<\/p>\n The use of tools such as powershell-empire for post-exploitation highlights the ease with which an attacker can maintain continuous and lasting access to a compromised system, even after a reboot. The Windows registry-based persistence technique ensures that the attacker can automatically reconnect to the compromised system, making mitigation of such threats more challenging.<\/p>\n It is essential that developers and security professionals are aware of these attack vectors and take proactive measures to protect their environments. This includes carefully verifying installed extensions, implementing strict security policies, and using monitoring and analysis tools to detect suspicious behavior.<\/p>\n In summary, this exercise not only demonstrates an exploitation technique, but also highlights the need for constant vigilance and a rigorous approach to security in software development. By understanding and anticipating these threats, we can strengthen our defenses and ensure a more secure and resilient development environment.<\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97a.jpeg\")
<\/center> <\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97b.jpeg\")
<\/center> <\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97c.jpeg\")
<\/center> <\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97d.jpeg\")
<\/center> <\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97e.jpeg\")
<\/center> <\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97f.jpeg\")
<\/center> <\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97g.jpeg\")
<\/center>\u00a0<\/b><\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97h.jpeg\")
<\/center>\u00a0<\/b><\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97i.jpeg\")
<\/center>\u00a0<\/b><\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97j.jpeg\")
<\/center>\u00a0<\/b><\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97k.jpeg\")
<\/center>\u00a0<\/b><\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97l.jpeg\")
<\/center>\u00a0<\/b><\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97m.jpeg\")
<\/center>\u00a0<\/b><\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97o.jpeg\")
<\/center>\u00a0<\/b><\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97p.jpeg\")
<\/center>\u00a0<\/b><\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97q.jpeg\")
<\/center>\u00a0<\/b><\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97r.jpeg\")
<\/center>\u00a0<\/b><\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97s.jpeg\")
<\/center>\u00a0<\/b><\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97t.jpeg\")
<\/center>\u00a0<\/b><\/p>\n![](\"http:\/\/localhost\/assets\/images\/blog\/nota_97u.jpeg\")
<\/center>\u00a0<\/b><\/p>\n