The Howler Cell Threat Research Team identified an active malware campaign targeting Indian users. The attack starts with fake websites impersonating the Indian Income Tax Department. Victims see urgent tax compliance notices, get routed through a fake Microsoft security page, and download a ZIP file that looks like an official tax tool.
Inside the archive is a legitimate, signed executable paired with a malicious DLL. When the executable runs, it loads the malicious DLL through Windows DLL search-order hijacking. This is a known technique where an attacker places a malicious library in a path the trusted binary will check first, giving the malware a clean entry point.
From there, a six-stage chain runs. Early stages handle privilege escalation via a UAC prompt, install a persistence service named "Windows Mixed Reality Service," and retrieve a polyglot file from attacker infrastructure. That file is a JPEG with multiple encrypted payloads hidden at various offsets. Later stages shift entirely to memory, with reflective loading used to avoid writing additional files to disk.
The chain ends with two implants injected into svchost.exe processes across all active user sessions.
The design is built to slip past platform-only defense. The unpacked payloads never touch disk, and they travel inside a valid JPEG that passes casual inspection as an image. The endpoint alert that should fire may not. Surfacing activity like this is the work of proactive threat hunting, and the service name, host artifacts, and named kernel objects documented below are the pivots a hunt team uses to find it before an alert exists. The same indicators give a DFIR team a fast path to scope and contain a confirmed compromise.
The two final implants give the operator full control over compromised systems:
The first is a Gh0st RAT derivative connecting to kkxqbh[.]top on port 6666. It includes screen capture with a self-contained JPEG encoding pipeline, a reverse shell, file operations, and desktop interaction. All modules are reflectively loaded.
The second is a Quasar/AsyncRAT-family .NET implant connecting to ouewop[.]com on port 6351. It loads entirely in memory after patching AMSI, with the .NET CLR hosted from native code to sidestep standard managed-code detection paths.
Running both implants over separate C2 channels gives the attacker redundant access with different detection profiles. If one implant is identified and blocked, the other remains active. Injecting across all user sessions means the malware survives user switches and reaches both the service context and interactive sessions at once.
The campaign infrastructure uses multiple domains for initial delivery, a dedicated IP for polyglot hosting, and two independent C2 endpoints. This separation makes full infrastructure takedown harder and reduces the chance a single block disrupts the operation.
The overall threat profile is high. The social engineering lure is well-targeted for Indian users, the infection chain is technically sophisticated, and the dual-implant design reflects deliberate operational security planning by the threat actor.
Figure 1: Attack Overview
The infection chain begins with a series of fraudulent websites impersonating the Indian Income Tax Department. During the investigation, multiple domains hosting identical content were identified, each using the /incometax path and presenting visitors with a fabricated tax compliance notice (Figure 2). The pages abuse official Government of India branding, including references to the Ministry of Finance, Income Tax Department, and Enforcement Division, to appear legitimate and gain the victim's trust.
Figure 2: Income Tax notice: Lure
The lure claims that the recipient's organization has violated provisions of the Income Tax Act and must submit supporting documents within 72 hours to avoid penalties and legal action. The notice prominently features a "Download Documents" button, creating a sense of urgency and encouraging immediate interaction.
Upon clicking the download button, victims are redirected to a second-stage page masquerading as a Microsoft security verification portal (Figure 3).
Figure 3: Fake Microsoft verification page
Branded as "Microsoft Edge Secure Gateway," the page displays a series of purported security checks, including SSL/TLS verification, certificate validation, malware scanning, and file integrity verification. All checks are shown as successfully completed before the user is prompted to open Microsoft Edge. This additional step serves purely as a social engineering mechanism designed to trade on Microsoft's reputation and reduce suspicion before the payload is delivered.
Once the user approves the request, Microsoft Edge automatically downloads a ZIP archive named Common_Offline_Utility_ITR-1_to_4_AY2026-27.zip.
The archive contains two files: COU_ITR-1_to_4_AY2026-27.exe and nvdaHelperRemote.dll. These components form the first stage of a multi-layered malware delivery chain that ultimately deploys a remote access trojan on the victim system.
During the investigation, the following infrastructure was observed hosting the lure content and facilitating payload delivery:
The consistent use of government-themed content, Microsoft-themed trust indicators, and tax-related filenames suggests a coordinated social engineering campaign specifically designed to target Indian users and increase the likelihood of successful malware execution.
The infection begins with COU_ITR-1_to_4_AY2026-27.exe, a legitimate and digitally signed binary that the attacker repurposes as a launcher. By placing a malicious dependency, nvdaHelperRemote.dll, alongside the executable in the same directory (Figure 4), the attacker abuses Windows' default DLL search order so that the trusted process loads the attacker-supplied module instead of a legitimate one.
Figure 4: Overview of Archive: Common_Offline_Utility_ITR-1_to_4_AY2026-27.zip
Once the executable resolves and loads this dependency, the DLL initiates a multi-stage unpacking and payload delivery chain. It first decodes a block of shellcode directly in memory, and that shellcode subsequently unpacks the second-stage payload and transfers execution to it (Figure 5).
Figure 5: Unpacking next stage
Before any payload work begins in stage 2, an initializer routine confirms the process is running with administrative rights, which the later service installation requires. It builds the Administrators group SID and checks whether the current token is a member. If it is not, the malware relaunches itself with the runas verb to trigger a UAC elevation prompt and terminates the unprivileged instance, so execution only continues once elevated (Figure 6).
Figure 6: UAC Admin prompt via "runas"
The initializer also enforces a single running instance using named global events (Figure 7). If an event indicating a prior or in-progress setup already exists, the process exits quietly. Otherwise, it creates its own event as a marker and spawns the worker threads that carry out the download and delivery, then sleeps to let them finish.
Figure 7: Single Instance Check: Event Names
With elevation confirmed, the downloader prepares its staging directory under C:\Program Files\Windows Media Player, a legitimate-looking path, and removes any artifacts left by a previous run. It then retrieves a file from the command-and-control server at 118[.]107[.]0[.]197 and saves it to disk as C:\Windows\background.jpg. The downloaded file is a polyglot. As shown in Figure 8, the URL serves a perfectly valid image that renders normally in a browser, which lets the file pass casual inspection and content filters that only check the header. The malware, however, disregards the picture entirely and reads only the data appended after the image, where the real payload is stored.
Figure 8: Polyglot Image: Ouewo.jpg/Background.jpg
The downloader reads the file into memory, seeks to a fixed offset where the appended payload begins, and extracts the embedded block. It writes this block out as nvdaHelperRemote.dll in the staging directory (Figure 9). This is the next-stage DLL, positioned specifically so the signed launcher will sideload it, looping the chain back to the original DLL search-order abuse.
Figure 9: Staging next stage for execution via DLL sideloading
To provide a trusted process for the sideload, the downloader copies its own running binary into the working directory under the name Mixed Reality.exe, adopting a cover identity tied to a real Windows feature (Figure 10). Persistence is then established as a Windows service rather than a simple autorun entry, granting automatic startup with elevated privileges.
Figure 10: Self-Copying for next stage execution
The malware removes any pre-existing service from an earlier infection, creates a new auto-start service named MixedSvc pointing at the staged executable, gives it the convincing display name "Windows Mixed Reality Service" and a matching description, and starts it (Figure 11). With the service active and the sideloading components in place, the downloader terminates its own process and hands execution to the persisted service.
Figure 11: Persistence: Service Creation, MixedSvc
The DLL dropped during the previous stage is launched when MixedSvc starts, sideloaded by the staged host executable in the same directory. Functionally, it mirrors the original nvdaHelperRemote.dll module from the start of the chain, reusing the same unpacking approach.
As before, the module decodes an intermediary shellcode in memory and executes it (Figure 12). The decoded shellcode is visible in the memory dump below, beginning with its entry stub.
Figure 12: Shellcode: transferring execution to unpacking routine
The shellcode unpacks the next stage, a PE DLL that constitutes stage 4 (Figure 13). The key difference at this stage is delivery. Rather than writing the unpacked DLL to disk, the loader maps it reflectively in memory and transfers execution to it directly. Keeping stage 4 entirely in memory reduces the malware's on-disk footprint and frustrates static, file-based detection.
Figure 13: Stage 4 DLL: unpacked in-memory
The reflectively loaded DLL begins by resolving its API dependencies at runtime to avoid static imports. It XOR-decodes a set of obfuscated strings, using 0x18 as the key for most and 0x02 for one, to recover the names of kernel32.dll and the functions it needs: CreateProcessA, VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread. It then loads the library and resolves each function by name.
The injector revisits the same polyglot image dropped earlier (C:\Windows\background.jpg), this time carving a different region. It reads the file into memory, allocates a buffer of 0x29EF0 bytes, and assembles the injection payload in two parts: a 0x14F0-byte stub copied from an embedded data section within the DLL itself, followed by 0x28A00 bytes carved from the polyglot at offset 0x1587D (Figure 14). This second offset is distinct from the one used by stage 2, meaning the polyglot carries multiple embedded payloads at different positions. The carved block is then decoded using a key stored in the DLL's data section before the buffer is ready for injection.
Figure 14: Extracting additional payload components from Polyglot
With the payload prepared, the injector enumerates running processes and locates svchost.exe as its injection target (Figure 15). It opens the target with full access, allocates an executable memory region inside it, writes the assembled payload, and starts a remote thread at the payload's entry point. Once injection succeeds, the injector terminates its own process, leaving the injected payload executing within the context of a legitimate system process.
Figure 14: Injection into svchost.exe
The payload now running inside svchost.exe begins with the same single-instance guard seen earlier, checking for the global event Global\kkctsbnn. If the event already exists, the thread exits quietly (Figure 16). Otherwise, it creates the event and spawns its main worker thread.
Figure 16: Single Instance Check: Event
The worker first waits in a polling loop until the sideloaded DLL is present on disk, confirming that the earlier stages have finished writing their output before proceeding.
It then reads the polyglot image (C:\Windows\background.jpg) into memory a second time but now carves two entirely separate payloads from it at offsets not used by any previous stage. Each payload is assembled the same way: a 0x14F0-byte stub copied from the injector's own data section, followed by a larger block extracted from the polyglot. The first payload is carved from offset 0x52C04 (0x112E00 bytes) and the second from offset 0x165A04 (0xF0800 bytes). Both blocks are XOR-decrypted with keys embedded in the injector's data section. This makes the polyglot image serve as a shared payload container across multiple stages, with at least three distinct embedded components addressed by different offsets throughout the chain (Figure 17).
Figure 17: Extracting additional payload components from Polyglot
Delivery into target processes is session-aware. The injector enumerates all active terminal sessions and, for each one, spawns a suspended svchost.exe process under a duplicated token whose session ID has been reassigned to match the target session. It then performs the standard injection sequence: allocates executable memory in the remote process, writes the payload, and starts a remote thread at the payload entry (Figure 18). This is repeated for both payloads (Stage 6A/6B) across every active session, giving the malware a presence in each logged-in user's session context rather than only the service session where it originally landed.
Figure 18: Remote Thread Injection
The worker runs in a continuous loop, re-checking for new sessions and re-injecting as needed. It writes a small debug log to c:\debug.txt (hidden and marked as a system file) containing the client process ID, and monitors for a kill file (c:\kkqqexit) as a shutdown signal. When the kill file appears, the injector releases its resources, cleans up, and exits the thread.
The first payload injected into svchost.exe acts as a lightweight remote-access client with screen capture capabilities. On startup, it creates a hidden lock file (c:\kkooPPP) as a single-instance guard, terminating immediately if the file already exists (Figure 19).
Figure 19: Single instance check: File name
The payload carries its own reflective PE loader, used to map several embedded DLLs entirely in memory without touching disk. Four modules are loaded this way:
Together, these modules give the payload a self-contained screen-capture-to-JPEG pipeline and an independent networking stack for exfiltrating the captured frames to the C2 server.
The client resolves the domain kkxqbh[.]top via DNS and connects to the resulting address over port 6666 (0x1A0A) using the VTCP.dll networking library. If the resolution fails, it retries in a loop with randomized sleep intervals. Socket-level timeouts are configured at 30 seconds for sends and 5 seconds for receives (Figure 20).
Figure 20: C2 connection: RAT derivative
On a successful connection, it registers a receive callback and spawns a dedicated reader thread to process incoming data. The connection logic includes full reconnection handling: on disconnect, it tears down active sessions, cleans up handles, waits for pending operations to drain, and re-enters the resolution loop after a randomized delay.
Incoming data from the C2 is framed with a 6-byte sync marker followed by a 4-byte length field. The receive handler accumulates data until a complete message is available, buffering partial packets across multiple reads. Once a full message is assembled, the payload is decompressed using uncompress (zlib) and handed to the command dispatcher.
The dispatcher identifies each command by an 8-byte magic value at the start of the decompressed payload and spawns a dedicated worker thread for each task. The supported command set covers a broad range of remote access capabilities:
The main thread enters a standard Windows message loop after launching the C2 thread, keeping the process alive for the lifetime of the session (Figure 21).
Figure 21: RAT derivative Command dispatcher
The architecture of this payload aligns with the Gh0st RAT family, likely a modern fork. The sync-marker-plus-length packet framing with zlib compression, the 8-byte magic command dispatch, the piped cmd.exe reverse shell, and the reflectively loaded screen-capture and networking modules (CameraUtil.dll, VTCP.dll) all map to well-documented Gh0st RAT derivatives.
The second payload injected into svchost.exe serves as a native bootstrap for a .NET implant. Like its counterpart, it begins with a single-instance guard, this time using the lock file c:\ouewo (path constructed relative to the user's local AppData), and terminates if the file already exists (Figure 22).
Figure 22: Single Instance Check: File name
The payload patches the Antimalware Scan Interface (AMSI) before the .NET runtime is loaded. It resolves AmsiOpenSession in amsi.dll, marks two bytes at offset +0x1C as writable, and overwrites them with 0xFEEB, this offset falls inside a cmp instruction rather than on an instruction boundary.
The write replaces the conditional branch with a short jump backward (EB F2), redirecting execution unconditionally to the error path. While the cmp qword [rcx+0x10], 0xfffffffffffffffe is still executed, the immediately following jmp jumps straight to the error path, making the comparison result useless. This causes the function to always return 0x80070057 (E_INVALIDARG), regardless of whether the arguments are valid, and prevents AMSI from scanning the .NET assembly that is loaded immediately afterward (Figure 23).
Figure 23: AMSI patching
The loader base64-decodes an embedded blob and decrypts it using AES-128 via the BCrypt API. The key is the hardcoded 16-byte value 3343f6a8885a308da11ae0d18cd4a7f5, with a zeroed IV. The decrypted output is a .NET assembly (MSIL) protected with .NET Reactor (Figure 24/Figure 25).
Figure 24: Decrypted MSIL RAT Loader
Rather than dropping the assembly to disk, the loader hosts the CLR entirely from native code. It walks the standard COM hosting chain: CLRCreateInstance to obtain the ICLRMetaHost interface, GetRuntime targeting v4.0.30319, GetInterface for ICorRuntimeHost, then Start() to spin up the runtime.
Figure 25: Final Stage RAT payload
It retrieves the default AppDomain, wraps the decrypted bytes into a SAFEARRAY, and calls Load_3 to load the assembly from memory. Finally, it resolves the assembly's entry point via get_EntryPoint and invokes it, transferring execution to the .NET payload without it ever touching disk.
The in-memory .NET assembly is a Quasar/AsyncRAT-family implant. Its configuration strings, visible after deobfuscation, are encrypted with AES-256-CBC using an encrypt-then-HMAC scheme (Figure 26). The encryption key is derived from a base64-encoded passphrase against the well-known Quasar default salt, a signature trait of this lineage.
Figure 26: Encrypted RAT Configuration
The decrypted configuration yields the following indicators, as listed in Table 1:
Table 1: Decrypted RAT configuration
|
Field |
Value |
|
C2 Host |
ouewop[.]com |
|
C2 Port |
6351 |
|
Version |
Reach 2.0.1 |
|
Mutex |
5sGEm6Q4eTNv |
|
Group |
Default |
|
Install |
false |
This payload is a confirmed member of the Quasar/AsyncRAT family, identified by
Figure 27: Decrypted RAT configuration: reproduced in Cyberchef
This campaign demonstrates a well-structured, multi-stage infection chain that combines social engineering, signed-binary abuse, and layered in-memory execution to deliver two independent remote access implants onto victim systems. The use of a polyglot image as a shared payload container across multiple stages, session-aware injection to cover all logged-in users, and a dual-implant strategy with separated C2 channels reflect a level of operational maturity designed to maximize persistence and survivability.
Every stage after the initial download progressively reduces the on-disk footprint: the early stages write only the minimum files needed for sideloading and persistence, while the later stages operate entirely in memory through reflective loading, in-memory CLR hosting, and remote thread injection. The final implants never touch disk in their unpacked form, and the polyglot that carries them passes casual inspection as a legitimate image file.
For a defender, these design choices carry direct consequences. Two implants over two C2 channels mean blocking one does not end the intrusion. In-memory execution and signed-binary abuse mean an endpoint product can stay quiet while the operator holds full control. That gap is where threat hunting earns its place. Hunting for the staged service, the host artifacts, and the named global events finds this activity when detections do not, and the same indicators give a DFIR team a fast path to scope and contain a confirmed compromise. Defense in depth is what keeps a single missed signal from becoming a full intrusion.
|
File |
SHA256 |
| Common_Offline_Utility_ITR-1_to_4_AY2026-27.zip | 52c19cfdc25bd1c1be3386493d60ded19e2fe35e053d81dda2b212d8dde84330 |
| COU_ITR-1_to_4_AY2026-27.exe/ Mixed Reality.exe (Legitimate, but abused for sideloading) |
93dd8b7b393289f88493596faa4ae70054d9eb4fe47f2dd334f0c6bb5262f2a8 |
| nvdaHelperRemote.dll (Stage 1) | 2c0de3d5432d5a14cb03936a460ceb633b53a51881c4fa4f3dfa87fedef2148e |
| Downloader (Stage 2) | 60ad81d75bd59e12b43392f7abf95bcb66a6e27091a46f9bf5cca51a6c01853f |
| nvdaHelperRemote.dll (Stage 3, dropped) | 3dd5148cf3cfc7fe2196d066ef39d8f03d07022dd5e917227164abc8d6c6d1ed |
| Injector (Stage 4) | 030b90666a581934de0683ef9232f137867db804f6100c0479958826dc2e4cbb |
| Session-Aware Injector (Stage 5) | 7ee61469f1c171d1631a72720ecaa0516598b4671e320287674f5d6817a9fb92 |
| background.jpg (polyglot) | fd062b4096f22c47bf6124a5b58322940ff676cb8d8fccd40af4d110f93dc2fa |
| Decrypted .NET assembly (AsyncRAT, Stage 6B) | fb520caa54b7e498708a6ebd0029c2492134c87c85324a3301ab450caa19e112 |
| Injected payload PE-1 (Gh0st RAT derivative, Stage 6A) | a1521585d54fe29675f906b538d86a6d3b5804db637b714ab1fbf6fb01d0a6f1 |
|
Type |
Indicator |
Details |
|
Domain |
import[.]mom |
Lure hosting |
|
Domain |
tqhaq[.]rest |
Lure hosting |
|
Domain |
generate[.]lat |
Lure hosting |
|
Domain |
meoou[.]rest |
Lure hosting |
|
Domain |
kattp[.]homes |
Lure hosting |
|
URL Path |
/incometax |
Common lure page path |
|
IP |
118[.]107[.]0[.]197 |
Polyglot hosting |
|
URL |
hxxp[://]118[.]107[.]0[.]197/ouewo[.]jpg |
Polyglot download |
|
Domain |
kkxqbh[.]top |
Gh0st RAT C2 |
|
Port |
6666 |
Gh0st RAT C2 port |
|
Domain |
ouewop[.]com |
AsyncRAT C2 |
|
Port |
6351 |
AsyncRAT C2 port |
|
Type |
Indicator |
Context |
|
File |
C:\Program Files\Windows Media Player\Mixed Reality.exe |
Staged sideloading host |
|
File |
C:\Program Files\Windows Media Player\nvdaHelperRemote.dll |
Staged malicious DLL |
|
File |
C:\Windows\background.jpg |
Polyglot payload container |
|
File |
c:\debug.txt |
Debug log (hidden, system) |
|
File |
c:\kkooPPP |
Lock file (Gh0st implant) |
|
File |
c:\ouewo |
Lock file (AsyncRAT loader) |
|
File |
c:\kkqqexit |
Kill file (shutdown signal) |
|
Service Name |
MixedSvc |
Persistence |
|
Service Display |
Windows Mixed Reality Service |
Persistence |
|
Event |
Global\kkctsbnn |
Single-instance guard |
|
Event |
Global\ShitSetupOn26126k |
Setup-phase guard |
|
Mutex |
5sGEm6Q4eTNv |
AsyncRAT mutex |
Initial Access
Execution
Persistence
Privilege Escalation
Defense Evasion
Discovery
Collection
Command and Control