“In this Sherlock, you must analyze the tools used by a developer and understand how they may have been the victim of a security breach.”
We have discovered a serious security breach involving the unauthorized exposure of our source code. An employee has been identified as a potential suspect in this incident. However, the employee strongly denies any involvement or downloading of external programs. We seek your expertise in digital forensic investigation to perform a comprehensive analysis, determine the root cause of the leak, and help us resolve the situation effectively.
Medium - DFIR
Before starting, I installed a few tools to aid my investigation:
- FTK Imager
- Volatility 3
The available artifacts are memdump.dmp and Users.adi.
- What is the application that starts the suspicious chain of processes?
Let's look at the list of processes running inside the memory dump with Volatility. Using the windows.pstree module, we can observe an executable creating a high amount of processes with the same name:
After saving the output of windows.pstree and looking for the Code.exe process with PID 8108, we can see that it contains many more interesting children processes, such as cmd.exe and conhost.exe.
Digging deeper into these processes, I found that RunTimeBroker.exe with PID 1224 started a network connection with a foreign address:
This is a confirmed malicious IP address according to VirusTotal, which confirms that the Code.exe process is responsible for the malicious behavior in the machine:
- Provide the full path of the malicious file used to gain initial access.
Based on the processes shown in pstree, we can assume that the malicious file is located inside Visual Studio internal folders. Many of the processes are related with VSCode extensions due to the fact that the arguments related to that process mention this directory: c:\Users\User2\.vscode\extensions. Let's look for files inside that folder with windows.filescan:
PS C:\Users\hiramf0\Downloads> python ..\Tools\Volatility\vol.py -f .\ReliableThreat\memdump.dmp windows.filescan | findstr ".vscode" | findstr "extensions"This specific extension looks suspicious. All the other extensions look normal for a software developer. Let's filter for all files mentioning this chatgpt-b0t extension:
Let's check that extension.js file to see if we find anything interesting inside of it. Using windows.dumpfiles, we can extract this file from the memory dump.
Great! This file must be the file responsible for initial access.
- What user input, when executed, will run the malicious code?
Looking deeper into the file, we can see that when a specific string is entered, the JavaScript program executes an obfuscated piece of code, which is likely malicious:
- What are the hostname and port used to establish a reverse shell?
After deobfuscating the JavaScript code, we can see a domain name and a port number that were used to create a reverse shell through a Socket:
- What is the display name of the developer who created this malicious file?
Going back to the name of the malicious JavaScript file itself, we can see an interesting string: 0xs1rx58d3v. Let's do some OSINT against that string to find more information about the developer.
(Un)fortunately, it seems that this extension has been removed from the VSCode Marketplace. Let's try finding some metadata about the extension in the other files inside the 0xs1rx58d3v.chatgpt-b0t-0.0.1 directory. The package.json file looks interesting, since it is a configuration file and it may contain interesting metadata:
- What time was the malicious file released? (UTC).
The VSCode Marketplace should contain the exact timestamp when the extension was released. However, it was deleted previously; therefore, we will use the Wayback Machine to navigate to the extension page. Looking into how URLs for extensions are built, we can see that the Unique Identifier field goes after the itemName parameter. As an example, here's the URL for the Jupyter extension:
https://marketplace.visualstudio.com/items?itemName=ms-toolsai.jupyterThe Unique Identifier of our malicious extension appears in the name of all related files: 0xs1rx58d3v.chatgpt-b0t.
Our URL becomes: hxxps[://]marketplace[.]visualstudio[.]com/items?itemName=0xS1rx58D3V[.]ChatGPT-B0T
However, this timestamp is not correct. It might be possible that these timestamps are being rendered in my local timezone (GMT-6). After converting the timestamp back to UTC, we will find our answer.
- Provide the SID for the user who has been compromised.
Returning to the memory dump, we can use the windows.getsids module and filter for the User2 username to find the SID of the compromised user:
- Provide the full path of the suspicious executable being run during the infection chain.
One of the executables ran inside the tree of processes started by Code.exe was RuntimeBroker.exe, which is suspicious when paired with cmd and conhost. We can find further evidence of suspicious RuntimeBroker activity by checking windows.cmdline and observing that it was started by a cmd.exe process:
- The threat actor has modified the Windows registry to include a new entry. This change ensures that whenever a legitimate component runs, it triggers the malicious process, allowing the threat actor to maintain control of the system. Specify the name of the legitimate component.
Let's look at the .ad1 file now to find any interesting files. Inside the same directory as the RunTimeBroker.exe executable, we can find a suspicious executable:
Let's get the hash of this suspicious executable by right clicking it > Export File Hash List. The MD5 hash of the suspicious executable is 7de5460b6de2845475f3d96dcaaf805a, let's use VirusTotal to check if its a malicious executable:
Great, let's navigate to the Behavior > Crowdsourced Sigma Rules to find summarized information about what this executable does. Inside, we can find the Windows component used for persistence.
- Which MITRE technique corresponds to the previous action?
Looking deeper into the Sigma rule, we can see a few reference to find our answer:
After reading these papers, we can confirm that this executable is capable of doing COM hijacking for Evasion purposes:
This behavior corresponds to T1546.015:
- The threat actor has identified the location for all projects and manipulated one of the project files. Could you provide details about the malicious code that was added by the threat actor?
Inside the .ad1 image, we can find a Project folder containing many projects possibly belonging to the developer. Inside each directory, we can find a .git directory, which could give us more information for each project about any changes the threat actor might have implemented in these projects. To extract all files, right click the Project folder on the left pane > Export Files.
Let's look into the laravel-11.1.4 directory since it was the most recently edited repository. I used git diff to find which the latest changes to the repository, and I was met with some suspicious PHP code: