Signed Overwolf Binary Sideloads ValleyRAT Malware in India Tax Scam

During routine threat hunting, we identified an active ValleyRAT campaign targeting organizations in India by impersonating the Indian Income Tax Department. The phishing email contains a link to a spoofed notice page that downloads a ZIP archive. The archive includes a legitimately signed executable from Overwolf, a company that makes overlay software for PC gamers, and two hidden companion files: a malicious DLL and an encrypted .bin file.

Kill Chain

Fig. 1 - ValleyRAT kill chain

Delivery Starts With a Lure Email

The campaign begins with an email formatted as an official memorandum in both Hindi and English. This bilingual layout mirrors the style commonly used in Indian government correspondence, making the lure appear more credible.

The message cites Section 271(1)(c) for the alleged irregularity and threatens prosecution under Section 276C. Both are real provisions, and their use strengthens the social-engineering narrative.

The display name appears as "Income Tax Department," but the sender is a personal outlook.com address with no relationship to any gov.in namespace. The message was also delivered to a shared role mailbox rather than a named taxpayer, another indicator of fraud.

Fig. 2 - The lure email

The staging site

Clicking the embedded link opens dnfyb[.]vip. The page displays the State Emblem of India and a forged Notice of Assessment, then presents three download buttons. Each button delivers the same ZIP archive.

Fig. 3 - Downloader page

What lands on disk

The ZIP archive extracts three files into the same directory. In a default folder view, only the executable is visible; the DLL and .bin file are hidden.

Fig. 4 - The extracted archive
 

• 07.30Document details.exe: A clean, legitimately signed Overwolf Ltd executable that has been renamed. It is the only visible file in the extracted archive and side-loads the malicious DLL when executed.
• teamspeak_control.dll: The malicious loader, named to resemble a component of the legitimate executable. It reads and decrypts the accompanying .bin file.
• teamspeak_control.bin: The encrypted container that holds the ValleyRAT core and configuration. It has no PE extension and no executable attribute.

Phase 1: Side-Loaded DLL

Phase 1 exists to be loaded by a signed executable and to turn a data file into running code.

Signed executable side-loads the malicious DLL

The genuine 07.30Document details.exe searches its own folder first when resolving DLL dependencies. It imports 18 specific functions from teamspeak_control.dll, allowing the attacker-controlled DLL to load in the context of the signed executable.

Fig. 5 - The 18 tscontrol functions

UPX-packed and Astral-PE-mutated DLL

The DLL is packed with UPX and further modified with Astral-PE, a low-level PE header mutator.

Fig. 6 - UPX packed section names

We executed the file's own unpacking stub inside Unicorn, a CPU emulator that interprets instructions in a private address space without an operating system behind it. Execution was halted as soon as control reached the original entry point to get the unpacked DLL.

The unpacked DLL shows Astral-PE fingerprints: the TimeDateStamp is zeroed, and import library names are mangled.

Fig. 7 - Astral-PE fingerprint

Fig. 8 - Mangled imports

Records inside the .bin file

teamspeak_control.bin is 298,544 bytes and is parsed as a sequence of length-prefixed records. Each record begins with a 4-byte length field, followed by that many bytes of data. The parser repeats this process until it reads a zero-length value. The file contains three records and is consumed completely, with no trailing data.

Fig. 9 - BIN showing 3 records

The emulation was allowed to continue through DllMain with a synthetic Windows environment behind it, serving the real .bin file from disk.

The DLL takes its own module path, strips the extension and appends .bin. The pairing is computed, not stored.

Record 1: Phase 2, Reflective Loader

Record 1 contains the Phase 2 reflective loader. At 3,992 bytes, its purpose is to take the encrypted payload from Record 2, transform it into executable code in memory and transfer execution to it.

1. Allocate memory. The loader reads the Record 2 size and requests exactly that amount of memory from Windows: 291,840 bytes.
2. Copy the payload. Record 2 is copied into the allocated memory region while still encrypted.
3. Decrypt the payload. The loader decrypts the buffer into a header-stomped PE32+ DLL for AMD64 with five sections, ImageBase 0x180000000 and SizeOfImage 0x4B000.
4. Reflectively load and run it. Phase 2 copies headers and sections, applies relocations, resolves imports, calls the entry point with DLL_PROCESS_ATTACH and then invokes the exported run function. The ValleyRAT core is not written to disk.

Fig. 10 - ZwAllocateVirtualMemory with 291,840 bytes

Record 2: The Core, With Its RC4 Key Shipped Inline

Record 2 begins with a single byte, 0x73, which represents a 115-byte key length. The next 115 bytes are the RC4 key, and the remaining bytes are ciphertext. The cipher is RC4, but not stock RC4; one line of the algorithm has been altered. Standard RC4 produces each keystream byte as S[(S[i] + S[j]) & 0xFF]. This sample instead uses S[i] XOR S[j].

Fig. 11 - The 115-byte RC4 key, at teamspeak_control.bin

Payload with no MZ header in memory

When the reflective loader reassembles the payload in memory, the buffer layout is: length byte, key, then decrypted data. This places offset 0x3C inside the key. In a PE file, offset 0x3C stores e_lfanew, the pointer to the real PE headers.

In this sample, the four key bytes at that location are 38 01 00 00, which resolve to little-endian 0x138. That value points exactly to the payload's headers, meaning part of the key also functions as file-format metadata.

Offset 0x00     0x73 0x8F        keylen and key[0]. NOT "MZ"
Offset 0x3C     0x00000138       a valid e_lfanew, supplied BY THE KEY
Offset 0x138    0x00000000       where "PE\0\0" belongs. Zeroed.
Offset 0x13C    COFF FileHeader, machine 0x8664

Fig. 12 - e_lfanew at 0x3C reads 38 01 00 00; the PE signature at 0x138 is zeroed; the COFF header follows at 0x13C with machine type 0x8664.

Fig. 13 - Reading e_lfanew from offset 0x3C

The loader reads the 32-bit value at offset 0x3C. The instruction movsxd r14, [r15+3Ch] reads e_lfanew from the buffer, and add r14, r15 turns it into a pointer to the PE headers. The subsequent reads at [r14+50h] and [r14+30h], SizeOfImage and ImageBase, confirm the loader treats it as a genuine Optional Header.

Record 3: The Encrypted Configuration

Record 3 is a 2,696-byte encrypted configuration block at offset 0x483A4. Phase 2 does not process this record. Phase 3 decrypts it after the core is mapped.

Configuration decryption

Phase 3 first reads its own configuration. It calculates the source address from the two preceding record lengths, hardcodes the configuration size, copies the record into a fixed global buffer and decrypts it in place.

Fig. 14 - Fetching its own configuration: the size 0xA88 (2,696 bytes)

The configuration decryptor locates Record 3 and applies the five-byte key 01 02 03 04 05, which appears as two immediate operands. The key appears in two instructions:

mov dword ptr [rbp+30], 0x04030201 writes the first four bytes.
mov byte ptr [rbp+34], 5 writes the fifth byte.

Fig. 15 - The five-byte configuration key materialized as two immediate operands

The output stage carries the same modification described in Record 2. The campaign therefore uses one decryption routine with two different keys: a 115-byte key shipped inline with the 291 KB payload, and a five-byte constant, 01 02 03 04 05, compiled into the RAT for configuration decryption.

We also decrypted Record 3 offline using the five-byte key.

Fig. 16 - Statically recovered decrypted configuration

With the core loaded in memory and its configuration decrypted, ValleyRAT checks its privilege level before moving into persistence and evasion.

Privilege check

The RAT checks whether it is running with administrator privileges. It constructs a Windows SID with AllocateAndInitializeSid, likely for the local Administrators group, and then calls CheckTokenMembership to test the current process token.

Fig. 17 - Stepping into administrator checks

A second path retrieves the module path and calls IsUserAnAdmin. If the privilege check succeeds, execution continues. If it fails, the malware terminates through FatalExit.

Fig. 18 - Execution terminates if user is not admin

Evasion on dropped components

The decrypted Record 3 configuration shows that the malware builds the staging directory path C:\Program Files\Common Files before accessing the dropped components.

Fig. 19 - Install path assembled and dropper components

Once running, the RAT copies all three delivery components, the signed Overwolf executable and its two companion files, from the original extraction folder into this staging directory under the names specified in its configuration. The Overwolf executable becomes 444.exe.

This second copy lets the kill chain restart from the staging location if needed. All three dropped components, 444.exe, teamspeak_control.dll and teamspeak_control.bin, are marked -rhs-: read-only, hidden and system.

Fig. 20 - Dropped components with -rhs- mode

Persistence

We observed the sample achieving persistence through a scheduled task configured to run at user logon. The task masquerades as a OneDrive entry, and its action starts a program from a path under the user's local Microsoft OneDrive directory.

Fig. 21 - Scheduled task in OneDrive entry at logon

Process hollowing into svchost.exe

The RAT hollows svchost.exe by reconstructing the command line C:\Windows\system32\svchost.exe -k netsvcs at runtime. This allows it to execute under the appearance of a legitimate Windows service host.

Fig. 22 - Process hollowing on svchost.exe

C2 connection

The hollowed process then establishes a TCP connection to the C2 endpoint, which was unresponsive at analysis time: 103[.]240[.]196[.]115:1234.

Fig. 23 - C2 connection

Conclusion

The campaign is delivered by malicious email, using a fake Income Tax Department notice as a lure. The email carries a link that downloads a ZIP archive containing a legitimately signed executable and two hidden files, a malicious DLL and an encrypted data file. Running the clean executable side-loads the attacker's DLL. The DLL then decrypts the .bin file and runs the ValleyRAT core entirely in memory. Once active, the malware hides its components in a system folder, persists through a scheduled task at logon and injects into a legitimate svchost.exe process, from where it connects to its command and control server.

Protection Statement

• Stage 2 (Lure): Phishing emails associated with these attacks are identified and blocked by email security analytics.
• Stage 3 (Redirect): The staging URLs that deliver the payload are categorized and blocked.
• Stage 5 (Dropper File): The dropper files are added to the Forcepoint malicious database and are blocked.
• Stage 6 (Call Home): C2 servers are categorized under the security category and blocked.

IOCs

Staging URL

• dnfyb[.]vip

C2

• 103[.]240[.]196[.]115:1234

Analysis Artifacts

Other Embedded Download Domains Found in Our Telemetry

• hxxps://dnfyb[.]vip/
• hxxp://taobaoker[.]vip/
• hxxps://taobaoker[.]vip/
• hxxps://kangyue[.]vip/
• hxxps://wayaya[.]vip/
• hxxps://cpxxw[.]vip/
• hxxps://usheng[.]vip/
• hxxp://wayaya[.]vip/
• hxxp://yakin[.]vip/
• hxxp://tanlianmeng[.]vip/
• hxxp://kangyue[.]vip/
• hxxp://nsseo[.]vip/
• hxxps://nsseo[.]vip/
• hxxps://dywwl[.]vip/
• hxxps://rpaai[.]vip/
• hxxps://kejiwei[.]vip/
• hxxp://cpxxw[.]vip/
• hxxp://usheng[.]vip/
• hxxp://dnfyb[.]vip/
• hxxp://dywwl[.]vip/
• hxxp://rpaai[.]vip/
• hxxp://kejiwei[.]vip/
• hxxp://shhswz[.]vip/
• hxxp://suoguan[.]vip/
• hxxp://zbrhcggp[.]vip/