## 4 Testbed and Test Scenarios  
Our testbed consisted of a clean virtual machine (VM) running MS Windows 10 Enterprise (build 19045.5371), last updated in February 2025. The VM was allocated 8 GB of RAM and a quad-core CPU. MSEdge (version 132.0.2957.140) and Chrome (version 132.0.6834.160) were installed on the VM. The native application and DLLs were implemented in C++, while the browser extension was developed using JavaScript. The C2 server, hosted on an Ubuntu Server 22.04 LTS Gen2 VM (kernel 6.8.0-1020-azure) within Azure cloud infrastructure, utilized PHP and Caddy v2.9.1. A free _azurewebsites_ domain was used for C3 communication, with Caddy configured to enable HTTP/3 for secure communication with the target workstation. The installation required several key files: _native_app.json_ (for configuring communication between the native application, _native_messaging.exe_, and the extension), _manifest.json_ (specifying extension permissions), _background.js_ (containing the extension's code), and _libcurl.dll_ (providing HTTP/3 support for the native application). The installation procedure then proceeded as follows:  
1. Native application and library placement: Copy _native_messaging.exe_, _native_app.json_, and _libcurl.dll_ to a user-accessible directory. The path to this directory must be specified in _native_app.json_. 2. Registry entry creation: Create a new registry entry named _com.example.native_messaging_ under _HKETY_CURRENT_USER\ SOFTWARE\Google\Chrome\ NativeMessagingHosts\Com.example.native_messaging_. Set the data of this entry to the path of _native_app.json_. 3. Extension installation (Chrome): Replace a pre-installed Chrome extension (e.g., ID _nmmhkkegccagdldgimetpiccmgnieda_) with the files of the malicious extension (_background.js_ and _manifest.json_). This step is necessary in Chrome to prevent the browser from deleting the extension files. Note that this step is not required for MSEdge, as it does not delete extension files. 4. Extension ID retrieval: Obtain the extension ID from the Secure Preferences file of either MSEdge or Chrome and add it to _native_app.json_. 5. Browser shortcut modification: Modify or create new shortcuts for Chrome or MSEdge to include the -_load-extension_ flag, pointing to the malicious extension's directory. This allows the extension to be loaded when the browser is launched and ensures that Chrome will keep this extension, i.e., there is a small possibility for Chrome to delete the replaced extension if the -_load-extension_ flag is not used. Basically, the optimal way to ensure the survival of the malicious extension is to use both the -_load-extension_ flag and the replacement of an already installed extension. For enhanced persistence, this can be combined with the -_headless_ and -_user-data-dir_ flags and scheduled via Task Scheduler. Note that Chrome requires two initial executions with -_user-data-dir_ for connection stability in the headless mode. MSEdge displays a \"Turn off extensions in  
Figure 1: Attacker–victim communication flow. developer mode\" popup. Therefore, the headless mode is recommended for MSEdge, unless the extension is installed from the Microsoft Edge Add-ons store. * Browser launch and C2 communication: Launch the browser (either normally or in the headless mode using the modified shortcut) to establish communication with the C2 server. To validate the effectiveness of the proposed C2 communication method, six test cases were executed on the target host via the C2. These scenarios demonstrated both command execution and lateral movement [9]. 1. Basic command execution: The whoami command was executed via CMD. 2. Network connectivity test: The _ping 8.8.8.8_ command was executed via CMD. 3. Data exfiltration: A file in the _Downloads_ folder was converted to Base64 and uploaded to the C2 server. 4. Scheduled task execution as another user: The _schtasks_ command was used to schedule and execute a task as a different user.