This report presents a detailed investigation of an Indian tax-themed phishing campaign delivering a sophisticated multi-stage malware framework through a combination of social engineering, phishing infrastructure, and memory-resident malware execution techniques. The campaign begins with a fraudulent tax notification email impersonating an official Indian tax authority, leveraging government branding, urgency-based messaging, and compliance-related threats to manipulate victims into interacting with a malicious phishing website. Victims are subsequently instructed to download a malicious ZIP archive containing three staged payload components: कर विवरण.exe, SbieDll.dll, and SbieDll.bin, which collectively establish the complete infection lifecycle. Initial static analysis identified multiple indicators of suspicious behaviour, including modified PE structures, packed components, debug artifacts, and custom execution logic designed to evade conventional security solutions.
Further reverse engineering revealed a highly modular malware architecture implementing advanced defense-evasion and anti-analysis techniques such as DLL Search Order Hijacking, API Hooking, Token Manipulation, COM callback-based execution, Mutated RC4 payload encryption, Reflective PE Loading, and LLVM-based Control Flow Flattening (CFF). The malware executes primarily in memory, significantly reducing forensic artifacts and making traditional detection approaches considerably more difficult. Additionally, the malware establishes persistent WebSocket-based Command-and-Control (C2) communication, allowing malicious traffic to blend with legitimate network activity. Multiple Chinese-language artifacts and suspicious infrastructure indicators were observed throughout the analysis; however, these findings alone are insufficient for definitive attribution and therefore remain at a moderate level of confidence. Overall, the campaign demonstrates characteristics commonly associated with stealth-focused, modular, and highly sophisticated malware ecosystems.
The increasing use of government impersonation and social engineering tactics has become a preferred strategy among threat actors seeking to distribute malware through trusted entities and fear-driven narratives. This report analyses an Indian tax-themed phishing campaign designed to deliver a sophisticated multi-stage malware framework through a structured infection chain involving phishing infrastructure, ZIP-based payload delivery, and memory-resident execution mechanisms. The analysis combines campaign infrastructure investigation, static analysis, reverse engineering, execution flow reconstruction, and command-and-control analysis to provide a comprehensive understanding of the attack lifecycle. The primary objective is to identify the campaign’s delivery mechanisms, malware functionality, evasion techniques, and operational behaviour, while providing actionable intelligence that can support threat detection, incident response, and security monitoring activities.
| Target Technologies | Windows Operating System |
| Threat Type | Phishing Campaign |
| File Types | EXE (Portable Executable), DLL (Dynamic Link Library) |
| Key Malware Identifiers | “कर विवरण.exe”, SbieDll.dll & SbieDll.bin |
| Observed First | 20 May 2026 |
| Impact | Full Access (Command and Control) |
| MD5 Hashes | कर विवरण.exe “3a8f6454927b8993aded75de0de2bd00” SbieDll.dll “e83ff54e58f0b295a392c7fc39a7d0de” SbieDll.bin “b498256cb086a6962077cdd6d2f65327” |
The attack chain begins with a social engineering email impersonating an official Indian tax authority notification, designed to create urgency through financial penalties and compliance-related warnings. The email contains a malicious link directing victims to a fake tax-themed phishing website that visually imitates a legitimate government portal. The phishing page persuades users to download a malicious ZIP archive presented as an official tax notice or supporting document package.
Once extracted, the ZIP archive delivers three staged payload components: कर विवरण.exe, SbieDll.dll, and SbieDll.bin. The executable file acts as the initial execution vector and establishes the environment by performing mutex validation, operating system checks, and dynamic API resolution before installing multiple malicious hooks. The malware then abuses DLL Search Order Hijacking to load the malicious SbieDll.dll instead of a legitimate library. This DLL acts as a polymorphic loader and implements advanced anti-analysis techniques, including API Hooking, Token Manipulation, Mersenne Twister-based execution logic, and COM callback execution for stealth purposes.
The final stage involves loading SbieDll.bin, which contains an encrypted shellcode payload protected using a mutated RC4 stream cipher. Following decryption, the shellcode executes a Reflective PE Loader that manually reconstructs and loads the payload directly into memory without relying on LoadLibrary() or creating artifacts on disk. The malware further protects execution using LLVM-based Control Flow Flattening (CFF) and establishes persistent WebSocket-based Command-and-Control (C2) communication through HTTP protocol upgrades, allowing malicious traffic to blend with legitimate web application activity while maintaining covert communication with attacker-controlled infrastructure.
The screenshot reveals detailed email header metadata associated with the initial phishing email used during the campaign. Analysis of the header information indicates the use of government impersonation tactics, where the sender identity attempts to imitate an official Income Tax enforcement authority while using a suspicious underlying domain structure. The visible sender address [email protected] demonstrates a display name spoofing technique, where attackers insert a trusted-looking subdomain before the actual controlled domain to mislead recipients into believing the email originates from a legitimate government source.
Further analysis indicates that SPF, DKIM, and DMARC authentication mechanisms successfully passed validation checks. However, these results do not imply legitimacy because the authentication applies only to the attacker-controlled domain mnb-ny.com rather than an official government domain. The email delivery path additionally shows routing through SendGrid’s outbound infrastructure, indicating the use of a legitimate third-party email delivery service for improved delivery reliability and reduced suspicion. The combination of sender impersonation, trusted email services, and successful authentication records highlights an attempt to increase credibility and bypass conventional email security mechanisms.
Email header analysis showing sender impersonation techniques, successful SPF/DKIM/DMARC validation, and the use of third-party email delivery infrastructure (SendGrid) to increase email credibility, delivery success rate, and social engineering effectiveness.
The screenshot illustrates the malicious tax-themed phishing webpage designed to impersonate an official Indian government tax department and exploit user trust through government identity abuse. The page visually replicates legitimate government branding, including official logos, department names, and bilingual content (English and Hindi), to increase authenticity and reduce suspicion among victims. Such techniques are commonly used within social engineering campaigns to create psychological trust and encourage user interaction.
Further examination reveals several social engineering indicators embedded within the phishing page. The message contains urgency-driven language, tax penalty references, and time-sensitive compliance requests, specifically instructing victims to review details and submit documents within 48 hours. The webpage additionally includes a malicious download button disguised as an official document retrieval mechanism, ultimately leading users toward downloading the ZIP-based malware package. The combination of fear-based messaging, government impersonation, and deceptive download mechanisms indicates a deliberate attempt to manipulate victims into initiating the infection chain.
Figure 2: Tax-themed phishing webpage impersonating an Indian Tax department using government branding, bilingual content, urgency-based messaging, and a malicious download mechanism to facilitate social engineering-based malware delivery.
The screenshot demonstrates that the same malicious infrastructure is not limited to impersonating Indian government entities but is also being reused to imitate an official Japanese government tax portal. The webpage attempts to visually replicate legitimate Japanese government branding, including language localization, navigation menus, official tax terminology, and user interface elements commonly found on authentic government platforms. This behavior indicates a broader multi-region phishing strategy designed to target victims across different geographical locations rather than a campaign focused on a single country.
A significant observation is that the same suspicious infrastructure previously used for Indian tax-themed phishing activity is now hosting a Japan-themed government impersonation portal, suggesting infrastructure reuse by the threat operators. Reusing infrastructure across multiple themes and regions is commonly observed in large-scale phishing operations, allowing threat actors to rapidly rotate lures while minimizing operational costs. The transition from Indian tax authority impersonation to Japanese tax authority impersonation indicates a flexible campaign architecture capable of dynamically changing themes depending on the intended target demographic. Such behavior increases the likelihood that the operators maintain a centralized phishing framework supporting multiple localized templates.
Figure 3: Japanese Government tax portal impersonation webpage hosted on previously identified suspicious infrastructure, demonstrating multi-region government impersonation, localized phishing templates, and infrastructure reuse techniques used to expand social engineering effectiveness across different target populations.
The screenshots reveal the presence of Chinese-language artifacts embedded within the phishing webpage source code and HTML metadata. The JavaScript snippet contains multiple Chinese comments associated with ZIP file processing and filename handling mechanisms, indicating that the phishing infrastructure or webpage components may have been developed using a Chinese-language development environment or reused from previously developed templates. The code references ZIP-related operations, including filename decoding and extraction functionality, which aligns with the campaign’s delivery mechanism involving ZIP-based malware payload distribution.
The phrase “官方税务通知” translates to “Official Tax Notice” in English. The coexistence of English tax-related content with embedded Chinese-language strings is a notable operational artifact because legitimate Indian government portals would not normally contain such metadata. While these indicators may suggest Chinese-speaking operators, Chinese-language development tools, or template reuse, such artifacts alone are insufficient for definitive attribution. Therefore, these findings should be treated as supporting indicators rather than direct evidence of actor origin.
Figure 4: Embedded Chinese-language artifacts identified within JavaScript source code and HTML metadata, showing references to ZIP processing functionality and the page title “官方税务通知” (“Official Tax Notice”), indicating potential template reuse, Chinese-language development environments, or Chinese-speaking operational indicators.
The screenshot illustrates the contents extracted after downloading and unpacking the malicious ZIP archive, revealing a structured multi-stage malware package consisting of three primary components: कर विवरण.exe, SbieDll.dll, and SbieDll.bin. Rather than delivering a single executable payload, the attackers employ a modular payload architecture in which individual files perform dedicated roles during different stages of execution. This approach enables improved payload separation, execution control, and anti-analysis capabilities, making the infection chain more difficult to identify and disrupt.
Analysis of the extracted components indicates that कर विवरण.exe functions as the initial execution vector (Stage 0 Host Loader) responsible for environment preparation and malicious execution setup. The SbieDll.dll file acts as a polymorphic loader DLL, implementing API hooking, execution manipulation, and anti-analysis functionality, while SbieDll.bin serves as the encrypted shellcode payload that is later decrypted and executed in memory. The use of multiple staged components demonstrates an intentionally designed multi-stage infection mechanism, allowing threat actors to separate functionality and reduce direct exposure of the final malicious payload during initial execution.
Figure 5: Extracted contents of the malicious ZIP archive showing a multi-stage payload structure consisting of कर विवरण.exe (Stage 0 Host Loader), SbieDll.dll (Polymorphic Loader DLL), and SbieDll.bin (Encrypted Shellcode Payload) used to establish the complete malware execution chain.
The static analysis identified कर विवरण.exe as a 64-bit Portable Executable (PE64) compiled for AMD64 architecture using Microsoft Visual C/C++ with Visual Studio 2019. The sample contains debug information, overlay data, and certificate-related structures, indicating the presence of embedded resources or additional payload content. Although the filename attempts to appear legitimate through localized naming conventions, the executable primarily functions as the initial host loader responsible for environment preparation, dynamic API resolution, and transferring execution to subsequent malware stages.
Figure 6: Static analysis results of कर विवरण.exe using Detect It Easy (DiE) showing PE64 architecture, Visual Studio compilation artifacts, debug information, and overlay structures, indicating its role as the initial execution vector responsible for preparing the multi-stage malware execution chain.
The static analysis identified SbieDll.dll as a 64-bit Portable Executable Dynamic Link Library (PE64 DLL) compiled for AMD64 architecture using Microsoft Visual C/C++ with Visual Studio 2022. The sample exhibited multiple anomalies commonly associated with packed or obfuscated malware, including modified DOS headers, abnormal section structures, repeated section names, and manipulated metadata timestamps. These indicators suggest the DLL was intentionally protected to hinder static analysis and reverse engineering efforts.
Figure 7: Static analysis results of SbieDll.dll using Detect It Easy (DiE) highlighting PE64 DLL architecture, packing and obfuscation indicators, timestamp anomalies, custom section structures, and anti-analysis characteristics, supporting its role as the polymorphic loader component within the multi-stage malware framework.
The extracted strings confirmed that the malware sample was obfuscated using the Astral-PE obfuscation tool.
The code begins with mutex enforcement through the creation and validation of SBIE_BOXED_ServiceCrypto_Mutex1, ensuring that only a single malware instance executes on the system and preventing duplicate execution within the compromised environment.
Further examination shows the malware performing operating system version checks using GetVersionExW(), allowing execution only on supported Windows environments. Following validation, the malware dynamically loads essential system libraries such as KernelBase.dll and ntdll.dll and resolves critical APIs using GetProcAddress(), avoiding static imports and reducing visibility during analysis. The code additionally demonstrates use of SbieDll_Hook(), confirming that the malware leverages the malicious SbieDll.dll component to establish runtime API hooking mechanisms.
The lower code section further reveals service-related initialization behavior, where CryptSvc.dll and CryptServiceMain() functions are dynamically resolved and executed. Environment variables and service structures are also initialized before invoking the next execution phase, indicating preparation for persistent execution, hook deployment, and transition into later malware stages.
WinMain Execution Logic and API Hook Registration
Service Initialization and CryptSvc Registration Logic
The screenshots demonstrate the implementation of Hook 1, targeting the Windows AccessCheckByType() API responsible for validating whether a process or thread has sufficient permissions to access protected resources. The malware registers a malicious replacement function through SbieDll_Hook(), redirecting the legitimate API execution to a custom handler identified as sub_1400014D0. Analysis of the replacement routine shows that it directly assigns GrantedAccess = 0xFFFFFFFF (full access permissions) and sets AccessStatus = TRUE, forcing the operating system to treat all access requests as successful regardless of actual security restrictions.
By bypassing normal Windows access control mechanisms, every authorization check performed within the hooked process automatically succeeds. This effectively removes privilege boundaries and allows the malware to access protected objects, open restricted handles, manipulate process tokens, and interact with sensitive system resources without encountering permission limitations. Such behavior significantly increases malware capabilities and enables unrestricted interaction with otherwise protected system components.
AccessCheckByType Hook Registration through SbieDll_Hook()
Malicious replacement routine forcing successful access validation
The implementation of Hook 2 targets the Windows CreateFileW() API responsible for creating and opening files, devices, and system resources. The malware intercepts file access requests and performs path manipulation before passing execution to the original function. Analysis of the code reveals logic that checks for specific paths, including \\.\PhysicalDrive and \system32\CatRoot2\, indicating that the malware selectively modifies how file operations are handled for system resources.
By intercepting and modifying file-related parameters, the malware gains the ability to alter normal file access behaviour and redirect execution toward controlled paths or resources. Such behaviour can be used to evade monitoring mechanisms, hide malicious activity, manipulate access to protected system files, or ensure subsequent malware stages interact with attacker-controlled resources rather than legitimate locations. The use of CreateFileW API manipulation provides an additional layer of execution control and defense evasion within the overall malware lifecycle.
CreateFileW path manipulation and conditional file handling logic
The implementation of Hook 3 targets the Windows DuplicateHandle() API responsible for duplicating object handles across processes and threads. The malware intercepts the original API execution and monitors for specific failure conditions, particularly ERROR_ACCESS_DENIED (Error Code: 5). Instead of allowing the operation to fail normally, the replacement routine generates an alternative execution path by creating a new object through CreateEventW(), clearing the error state using SetLastError(0), and forcing a successful return value.
This behaviour effectively acts as an error suppression and execution recovery mechanism, preventing access-denied failures from interrupting malware execution. By masking permission-related issues and returning artificially successful results, the malware ensures that subsequent operations continue without interruption, increasing execution reliability and reducing the likelihood of operational failure caused by security restrictions or access limitations. Such techniques are commonly used to maintain stable execution flow and conceal abnormal behaviour from monitoring mechanisms.
DuplicateHandle error interception and failure suppression logic
The implementation of Hook 4 targets the Windows SetThreadToken() API responsible for assigning security tokens to execution threads. The hook monitors for scenarios where SetThreadToken() fails with ERROR_ACCESS_DENIED (Error Code: 5) while operating on the current execution thread. Instead of allowing execution failure, the malware invokes OpenProcessToken() using TOKEN_ALL_ACCESS (0xF01FF) permissions to obtain the current process token and subsequently duplicates it using DuplicateToken() with SecurityImpersonation privileges. The duplicated token is then associated with the current thread, allowing the malware to continue execution under an impersonated security context.
This mechanism enables the malware to bypass normal security restrictions and manipulate thread-level privileges without interrupting execution flow. Additionally, the original token information is stored within Thread Local Storage (TLS) for later retrieval and manipulation by subsequent hooks. The use of token impersonation techniques significantly enhances malware capabilities by allowing execution within elevated contexts while reducing failures caused by permission restrictions.
SetThreadToken interception and token duplication logic
The implementation of Hook 5 targets the Windows GetTokenInformation() API responsible for retrieving security token attributes and permission-related information. Analysis of the code shows that the malware retrieves previously stored token information from Thread Local Storage (TLS) using TlsGetValue(dwTlsIndex) and conditionally replaces the original token reference before forwarding execution to the legitimate function.
By intercepting token retrieval operations and substituting stored values, the malware can manipulate how token-related information appears during execution. This behaviour assists in concealing prior token manipulation activities, maintaining execution consistency, and ensuring that subsequent components interact with attacker-controlled token contexts rather than original security information. The use of TLS-based token substitution creates an additional abstraction layer that complicates behavioural analysis and strengthens the malware’s overall defense-evasion capabilities.
GetTokenInformation TLS retrieval and token substitution logic.
Mersenne Twister VM Dispatcher
The execution logic of Stage 1 is implemented within the malicious SbieDll.dll component loaded through DLL Search Order Hijacking. Windows normally searches the application’s local directory before system directories when resolving DLL dependencies, allowing the malware to force execution of the malicious SbieDll.dll instead of the legitimate Sandboxie library. This component functions as the campaign’s primary anti-analysis and execution control layer, responsible for initiating complex runtime behaviour before transitioning to subsequent payload stages.
Further analysis of the code reveals the implementation of a 64-bit Mersenne Twister (MT19937-64) based execution dispatcher, which initializes its internal state using GetTickCount64() as a dynamic seed source. The observed mathematical operations and repeated state-generation logic indicate the use of a pseudo-random execution engine capable of generating varying execution patterns during runtime. This mechanism likely serves as a custom Virtual Machine (VM) dispatcher, ensuring that execution characteristics differ across infections and making behavioural analysis, signature generation, and execution tracing significantly more difficult. Such polymorphic behaviour reduces consistency between executions and strengthens the malware’s overall defense-evasion capabilities.
Mersenne Twister VM initialization and state generation logic
The screenshots demonstrate the implementation of the MT19937-64 Core State Engine embedded within the malicious SbieDll.dll component. Analysis of the code reveals mathematical operations and state-generation routines characteristic of the 64-bit Mersenne Twister pseudo-random number generator (PRNG). The observed logic initializes and continuously updates an internal 624-element state array, where each generated state value is derived from previous entries through a series of bitwise XOR operations, right-shift calculations, conditional masking, and predefined constants, including 0xB5026F5AA96619E9. These operations align with the standard MT19937-64 state transition algorithm, which is widely known for generating statistically random outputs across large periods.
Within the malware execution chain, this MT19937-64 implementation appears to function as a dynamic execution engine responsible for introducing runtime variability and polymorphic behaviour. Rather than producing predictable execution paths, the generated pseudo-random values can influence internal execution states, dispatch routines, or subsequent transformations used by the malware. This behaviour significantly complicates reverse engineering, behavioural analysis, and signature-based detection, since execution characteristics may differ across environments and individual infections. The integration of a custom PRNG-driven execution model demonstrates deliberate anti-analysis and evasion-oriented design choices within the malware framework.
MT19937-64 internal state generation logic
MT19937-64 state transformation operations
Pseudo-random value generation and output calculation
The screenshot demonstrates the implementation of a Thread Local Storage (TLS)-based string transformation and decryption routine embedded within SbieDll.dll. Analysis of the code reveals operations involving NtCurrentTeb(), ThreadLocalStoragePointer, and TlsIndex, indicating that the malware stores and retrieves data through thread-specific storage locations rather than maintaining static values within global memory structures. The routine performs multiple mathematical transformations, including XOR operations, offset calculations, and dynamic memory access, before reconstructing internal values during runtime.
Unlike conventional decryption routines that rely on static keys and linear processing sequences, this implementation appears to utilize a non-linear transformation approach, where reconstructed values depend on TLS-derived context information and dynamically calculated operations. Such behaviour makes the extraction of embedded strings significantly more difficult because the decrypted content may vary depending on execution state and thread context. This technique strengthens the malware’s anti-analysis capabilities by hiding important artifacts such as API names, configuration values, and internal execution strings until runtime execution occurs.
TLS-based string transformation and decryption logic
The screenshot demonstrates the implementation of a COM-based execution mechanism used by the malware to execute payload components while avoiding traditional thread creation APIs. Analysis of the code shows references to CoInitializeEx(), CoGetObjectContext(), and COM-related callback handling routines, indicating that the malware leverages COM object infrastructure instead of directly invoking APIs such as CreateThread(). The loader dynamically resolves these functions and registers execution handlers through COM interfaces before transferring execution to the next payload stage.
Rather than creating a new thread through standard Windows APIs that are frequently monitored by Endpoint Detection and Response (EDR) solutions, the malware appears to execute shellcode through a COM IContextCallback::ContextCallback handler, causing execution to occur within legitimate COM apartment thread contexts. This technique reduces behavioural visibility because the shellcode execution appears to originate from normal COM activity rather than suspicious thread creation events. By blending malicious activity with legitimate system behaviour, the malware significantly strengthens its defense-evasion and anti-analysis capabilities.
COM callback registration and execution handling logic
Dynamic API Hashing via ROR13 PEB Walk
The screenshots demonstrate functionality from Stage 2, where the malicious SbieDll.bin component performs dynamic API resolution using a Process Environment Block (PEB) walk combined with ROR13 hashing operations. The code begins by accessing __readgsqword(0x60), which retrieves a pointer to the Process Environment Block (PEB) in a 64-bit environment. Rather than relying on static imports that can be easily identified during analysis, the malware traverses internal process structures to enumerate loaded modules and resolve required APIs dynamically during runtime.
Further analysis reveals repeated ROR4/ROR13 rotation operations, character processing, and hash calculations used to generate API identifiers instead of storing readable function names. The malware compares these calculated hash values against internally stored values to locate target APIs and obtain their addresses during execution. This technique hides important APIs from static analysis tools and significantly complicates reverse engineering efforts because analysts cannot directly observe imported functions through conventional import tables. The use of dynamic API hashing enhances the malware’s anti-analysis, obfuscation, and defense-evasion capabilities, while reducing dependency on traditional executable structures.
PEB access through __readgsqword() for module enumeration
ROR13 hashing routine and dynamic API resolution logic
The screenshots demonstrate the implementation of a modified RC4-based stream cipher used within Stage 2 (SbieDll.bin) for payload decryption and protection of embedded shellcode components. The first code section resembles the traditional RC4 Key Scheduling Algorithm (KSA), where an initial 256-byte state array is created and rearranged using key-dependent operations. However, additional variables and modified state manipulations indicate that the malware does not implement a standard RC4 algorithm directly and instead introduces custom transformations to alter the internal state generation process.
The second code segment demonstrates functionality like the Pseudo-Random Generation Algorithm (PRGA) used in RC4, where dynamic state values are continuously updated and combined with payload data through XOR-based operations. Unlike conventional RC4 implementations, the observed modifications introduce additional calculations and state transitions that alter the generated keystream. This mutated RC4 implementation likely serves as an additional anti-analysis mechanism, making payload decryption more difficult and reducing the effectiveness of automated detection tools that rely on identifying traditional RC4 patterns. The decrypted output is subsequently used to reconstruct and execute the next memory-resident payload stage.
Modified RC4 Key Scheduling Algorithm (KSA) implementation
Modified RC4 Pseudo-Random Generation Algorithm (PRGA) logic
The screenshots demonstrate the implementation of a Reflective PE Loader Engine responsible for loading the decrypted payload entirely within memory without relying on the standard Windows loading process. Analysis of the code reveals references to memory-related APIs, including ZwFreeVirtualMemory and ZwAllocateVirtualMemory, indicating direct manipulation of process memory regions during runtime. The malware allocates memory dynamically, reconstructs required executable structures, and prepares the decrypted payload for execution without invoking conventional loading mechanisms such as LoadLibrary(). This behaviour indicates that the malware performs manual Portable Executable (PE) loading rather than allowing the operating system loader to manage execution.
Further analysis of the memory allocation and execution logic suggests that the malware manually handles critical PE loading operations, including memory allocation, section mapping, address resolution, and execution preparation, entirely in user space. By avoiding disk writes, standard library loading routines, and native loader involvement, the malware significantly reduces forensic artifacts and bypasses security mechanisms that commonly monitor conventional process loading behaviour. This technique represents a classic implementation of Reflective PE Injection, enabling the final payload to remain memory-resident while improving stealth and strengthening defense-evasion capabilities.
Figure 26: Memory allocation and payload preparation routines
Reflective PE loading and execution logic
The screenshot demonstrates the implementation of Control Flow Flattening (CFF) used to protect the malware’s core execution routines from static analysis and reverse engineering. Analysis of the code reveals multiple mathematical transformation operations, including __ROR4__, __ROL4__, and _byteswap_ulong, which are applied to internal state values before transferring execution through an indirect jmp rax instruction. Instead of maintaining a traditional linear execution flow, where functions follow predictable branches and control paths, the malware restructures execution into dynamically computed transitions controlled by runtime state variables.
This behaviour is consistent with LLVM-based Control Flow Flattening, where multiple execution branches are collapsed into a centralized dispatcher mechanism that computes the next execution target dynamically. As a result, the original logical structure becomes hidden behind multiple mathematical transformations and indirect jumps, making execution tracing significantly more difficult. Such techniques disrupt IDA Pro graph reconstruction, reduce the effectiveness of signature-based detection, and complicate behavioural analysis, as analysts cannot easily identify the original execution sequence. The use of CFF obfuscation demonstrates a deliberate anti-analysis strategy intended to increase reverse engineering complexity and conceal critical malware functionality.
Control Flow Flattening dispatcher and state transformation logic
The screenshots demonstrate the implementation of WebSocket-based Command-and-Control (C2) communication through the libwebsockets library within the malware framework. Analysis of the identified symbols, including lws_http_serve, lws_http_to_callback, and lws_http_transaction_completed, confirms the presence of libwebsockets-related functionality, indicating that the malware leverages legitimate networking libraries to establish covert communication channels. Rather than initiating direct or easily identifiable C2 traffic, the malware begins communication using a standard HTTP GET request, after which the connection is upgraded through HTTP/1.1 101 Switching Protocols, identical to the mechanism used by legitimate web applications when establishing WebSocket sessions.
This communication technique allows malicious traffic to blend seamlessly with normal web activity, making network-level detection significantly more difficult. Additional artifacts such as CONNECT %s:%u HTTP/1.0 indicate that the malware is proxy-aware, allowing C2 traffic to be tunnelled through enterprise HTTP proxy environments to bypass network restrictions and filtering mechanisms. The absence of visible hardcoded IP addresses or domain references further suggests that C2 configuration is dynamically supplied during earlier execution stages, preventing straightforward extraction of infrastructure indicators through static analysis. This combination of WebSocket tunneling, proxy support, and dynamic configuration retrieval significantly enhances the malware’s stealth, resilience, and defense-evasion capabilities.
libwebsockets-related function references
HTTP/1.1 WebSocket upgrade response artifacts
Upon execution, the malware loaded SbieDll.dll and performed process injection into multiple running processes, including svchost.exe and mitmweb.exe. The DLL exhibited broad injection behaviour by dynamically attaching itself to newly launched processes, indicating the presence of system-wide API hooking or persistent process injection mechanisms designed to maintain execution and expand malware control across the environment. During execution, the malware established network communication with the external IP address 43[.]128[.]54[.]184 over port 1234, suggesting command-and-control (C2) or remote communication activity.
The malware’s original name is “SandboxieCrypto.exe”.
This campaign indicates the emergence of a highly adaptive and stealth-focused malware operation leveraging government impersonation, multi-region phishing infrastructure, and advanced in-memory execution techniques to target victims through socially engineered tax-related lures.
The campaign demonstrates a broader operational capability beyond a single geography, as the same infrastructure was observed hosting both Indian and Japanese government-themed phishing templates, suggesting the existence of a centralized phishing framework capable of dynamically localizing content for different target regions.
The use of trusted third-party email delivery services, spoofed government identities, and multilingual phishing portals highlights a deliberate effort to increase delivery success rates and bypass traditional email security controls. From a technical perspective, the malware ecosystem reflects a mature threat model emphasizing defense evasion, runtime obfuscation, and covert persistence through DLL Search Order Hijacking, reflective PE loading, dynamic API hashing, token manipulation, and WebSocket-based encrypted C2 tunnelling.
The absence of hardcoded infrastructure, combined with proxy-aware communication and memory-resident execution, indicates an operational design intended to reduce forensic visibility and complicate attribution efforts. Additionally, the presence of Chinese-language artifacts, reusable phishing infrastructure, and modular payload staging suggests possible access to shared malware development resources or professionally maintained builder frameworks commonly observed within organized cybercriminal ecosystems.
Collectively, these characteristics indicate an evolving external threat landscape in which threat actors increasingly combine localized social engineering, modular malware delivery, and stealth-oriented post-exploitation techniques to maintain resilient and difficult-to-detect intrusion capabilities against both enterprise and individual targets.
This investigation identified a highly sophisticated multi-stage malware campaign delivered through an Indian tax-themed phishing operation leveraging social engineering, government impersonation, and ZIP-based payload delivery mechanisms to compromise victims.
The malware architecture demonstrated advanced defense-evasion and anti-analysis capabilities, including DLL Search Order Hijacking, API Hooking, Token Manipulation, Mersenne Twister-based execution logic, COM callback-based execution, Mutated RC4 encryption, Reflective PE Loading, Control Flow Flattening (CFF), and WebSocket-based Command-and-Control communication. The combination of memory-resident execution, dynamic API resolution, runtime obfuscation, and stealth-oriented communication techniques significantly reduces forensic visibility and complicates detection through conventional security mechanisms.
Additionally, the observed multi-region government impersonation activity, Chinese-language artifacts, and reusable phishing infrastructure suggest a flexible and modular operational framework; however, attribution remains at moderate confidence. Overall, the findings indicate a stealth-focused, highly modular, and technically mature malware ecosystem designed to maintain persistent and covert access while minimizing opportunities for detection and analysis.
Strategic Recommendations
Tactical Recommendations
Operational Recommendations
MITRE ATT&CK MAPPING
| Tactic | ID | Technique Name | Description |
| Initial Access | T1566.002 | Phishing: Spear phishing Link | Threat actors used social engineering emails containing malicious links redirecting victims to phishing infrastructure hosting malware payloads. |
| Initial Access | T1189 | Drive-by Compromise | Victims were redirected to a malicious phishing webpage which delivered a ZIP package containing staged malware payloads. |
| Execution | T1204.002 | User Execution: Malicious File | Execution required user interaction through extraction and execution of कर विवरण.exe. |
| Execution / Defense Evasion | T1574.001 | Hijack Execution Flow: DLL | Malware used DLL Search Order Hijacking to force loading of malicious SbieDll.dll instead of the legitimate library. |
| Execution | T1620 | Reflective Code Loading | The malware manually reconstructed and executed PE components entirely in memory without using LoadLibrary(). |
| Defense Evasion | T1027 | Obfuscated/Compressed Files and Information | Malware used Control Flow Flattening, mutated RC4, and dynamic execution logic to conceal behaviour. |
| Defense Evasion | T1140 | Deobfuscate/Decode Files or Information | Encrypted payloads within SbieDll.bin were decrypted during runtime before execution. |
| Defense Evasion | T1036 | Masquerading | The executable कर विवरण.exe used deceptive naming and impersonation techniques to appear legitimate. |
| Defense Evasion | T1055 | Process Injection | Malware used reflective loading and memory-based execution mechanisms to inject and execute payloads without standard process creation behaviour. |
| Defense Evasion / Privilege Escalation | T1134 | Access Token Manipulation | Hooks targeting SetThreadToken() and GetTokenInformation() manipulated security tokens and impersonation contexts. |
| Credential Access / Defense Evasion | T1553 | Subvert Trust Controls | Malware abused trusted Sandboxes DLL mechanisms and legitimate components for execution concealment. |
| Discovery | T1082 | System Information Discovery | Malware performed operating system version checks and environment validation before execution. |
| Command and control | T1071.001 | Application Layer Protocol: Web Protocols | Malware established C2 communication through HTTP/WebSocket protocols. |
| Command and control | T1573 | Encrypted Channel | Communication channels were protected using encrypted WebSocket-based sessions. |
| Command and control | T1090 | Proxy | Presence of HTTP CONNECT functionality indicates support for proxy-aware communication through enterprise environments. |
| Command and control | T1105 | Ingress Tool Transfer | Additional payload components were dynamically loaded and transferred between execution stages. |
| S. No | Indicators of Compromise (IOCs) | Type | Remarks |
| 1 | guhxmg.com | Domain | Block |
| 2 | naiqja.icu | Domain | Block |
| 3 | zh-welcome-1xbet.com | Domain | Block |
| 4 | d.pc-weide.com | Subdomain | Block |
| 5 | taxations.cn-web-okooo.com | Subdomain | Block |
| 6 | taxations.indiagov.it.com | Subdomain | Block |
| 7 | zhengfu666.com | Domain | Block |
| 8 | asdqxcdsa.icu | Domain | Block |
| 9 | appradarr.cc | Domain | Block |
| 10 | ws4962.com | Domain | Block |
| 11 | 185b7a487316454da04e9cc0fe6eb370bb2955cf6096fe3e8c02c46f8989ba37 | SHA-256 | Block |
| 12 | 4c9061a07d667bf7dd6f597a43a8552af2f4277b7be06d6ea138abdb668d6a49 | SHA-256 | Block |
| 13 | 949acbe543fc244ffbc981ea169067da7c5792af3c3d19b2c31b3d7e19106880 | SHA-256 | Block |
| 14 | be31a63cad112723178289968ad6f93a576c5a7984099c42eec3521cdf6e5fc0 | SHA-256 | Block |
| 15 | 7d87a86dbd2379ef2516c99258137cd9c25ca19c48aeb096c5332c02fcbf16d0 | SHA-256 | Block |
| 16 | 43.128.54.184 | IP Address | Block |
import “hash”
rule Operation_Tax_Shadow_Malware_Campaign
{
meta:
author = “Cyfirma Research”
description = “Detection rule for phishing infrastructure and malware samples”
date = “2026-05-29”
strings:
// Domains
$d1 = “guhxmg.com” nocase
$d2 = “naiqja.icu” nocase
$d3 = “zh-welcome-1xbet.com” nocase
$d4 = “d.pc-weide.com” nocase
$d5 = “taxations.cn-web-okooo.com” nocase
$d6 = “taxations.indiagov.it.com” nocase
$d7 = “zhengfu666.com” nocase
$d8 = “asdqxcdsa.icu” nocase
$d9 = “appradarr.cc” nocase
$d10 = “ws4962.com” nocase
// IP Address
$ip1 = “43.128.54.184”
condition:
// Match embedded infrastructure indicators
any of ($d*) or
$ip1 or
// Match known malware hashes
hash.sha256(0, filesize) == “185b7a487316454da04e9cc0fe6eb370bb2955cf6096fe3e8c02c46f8989ba37” or
hash.sha256(0, filesize) == “4c9061a07d667bf7dd6f597a43a8552af2f4277b7be06d6ea138abdb668d6a49” or
hash.sha256(0, filesize) == “949acbe543fc244ffbc981ea169067da7c5792af3c3d19b2c31b3d7e19106880” or
hash.sha256(0, filesize) == “be31a63cad112723178289968ad6f93a576c5a7984099c42eec3521cdf6e5fc0” or
hash.sha256(0, filesize) == “7d87a86dbd2379ef2516c99258137cd9c25ca19c48aeb096c5332c02fcbf16d0”
}
