# ValleyRAT and the Cost of a Valid Signature: When the Payload Has No Magic Bytes Left to Catch ## Summary The victim extracts a ZIP archive and sees exactly one file: `07.30Document details.exe`. That file is a **genuine Overwolf Ltd executable with a valid digital signature**, simply renamed. The other two files in the archive — a DLL and a `.bin` file — carry the hidden attribute and do not appear in a default folder view. Run it, and everything that follows happens in memory. The defensive point to grasp: this chain is built so that **each layer is missing exactly the thing detection tooling uses to recognise it**. The executable carries a valid signature and passes signature-based controls. The `.bin` file has no PE extension and no executable attribute. And the final payload, once reassembled in memory, **has no "MZ" at the start of the file and no "PE\\0\\0" where one belongs** — it parses correctly anyway, but there is no magic byte left for a YARA rule to anchor on. Forcepoint X-Labs identified the campaign during routine threat hunting, targeting organisations in India by impersonating the Indian Income Tax Department. **Priority action: sweep endpoints for validly signed binaries running from Downloads or Desktop without the rest of their installation around them — particularly binaries belonging to software absent from your application catalogue.** * * * ## The Delivery Chain ![Kill chain diagram](https://go.forcepoint.com/sites/default/files/2026-08/fig1-valleyrat-killchain.jpg align="center") *ValleyRAT kill chain (source: Forcepoint X-Labs).* The campaign begins with an email formatted as an official memorandum in **both Hindi and English**. That bilingual layout mirrors the style commonly used in Indian government correspondence, making the lure more credible. ![The lure email](https://go.forcepoint.com/sites/default/files/2026-08/fig2-lure-email.jpg align="center") *The lure email impersonating the Indian Income Tax Department (source: Forcepoint X-Labs).* The message cites **Section 271(1)(c)** for the alleged irregularity and threatens prosecution under **Section 276C**. Both are real provisions of Indian tax law, and their use strengthens the social-engineering narrative. Forcepoint identifies two clear fraud indicators: * The display name reads "Income Tax Department", but the actual sender is a **personal outlook.com address** with no relationship to any `gov.in` namespace. * The message was delivered to a **shared role mailbox** rather than a named taxpayer. Clicking the embedded link opens `dnfyb[.]vip`. The page displays the State Emblem of India and a forged Notice of Assessment, with **three download buttons — all three deliver the same ZIP archive**. ![Downloader page](https://go.forcepoint.com/sites/default/files/2026-08/fig3-downloader-page.jpg align="center") *The staging page presenting a forged tax notice (source: Forcepoint X-Labs).* ### Three Files on Disk ![Extracted archive](https://go.forcepoint.com/sites/default/files/2026-08/fig4-extracted-archive.jpg align="center") *Archive contents after extraction — only the executable is visible (source: Forcepoint X-Labs).* | File | Role | | --- | --- | | `07.30Document details.exe` | A clean, legitimately signed Overwolf Ltd executable, renamed. **The only visible file** in the extracted archive, and the one that side-loads the malicious DLL when executed | | `teamspeak_control.dll` | The malicious loader, named to resemble a component of the legitimate executable. Reads and decrypts the accompanying `.bin` file | | `teamspeak_control.bin` | The encrypted container holding the ValleyRAT core and configuration. **No PE extension, no executable attribute** | ## Kill Chain 1. The victim receives the tax-themed lure email and clicks the link to `dnfyb[.]vip`. 2. A ZIP archive downloads containing three files, two of them hidden. 3. The victim runs `07.30Document details.exe` — the validly signed Overwolf executable. 4. That executable **searches its own folder first when resolving DLL dependencies**, and imports **18 specific functions** from `teamspeak_control.dll`, allowing the attacker-controlled DLL to load in the context of the signed process. 5. The DLL takes its own module path, strips the extension and appends `.bin` — **the pairing is computed, not stored anywhere**. 6. The DLL reads `teamspeak_control.bin` (298,544 bytes) and parses it as a sequence of length-prefixed records: each begins with a 4-byte length field followed by exactly that many bytes. The parser repeats until it reads a zero-length value. The file contains **three records and is consumed completely, with no trailing data**. 7. **Record 1** (3,992 bytes) is the Phase 2 reflective loader. 8. The loader reads the Record 2 size and requests exactly that much memory from Windows: **291,840 bytes**. 9. Record 2 is copied into the allocated region while still encrypted, then decrypted into a **header-stomped PE32+ DLL for AMD64** with five sections, ImageBase `0x180000000` and SizeOfImage `0x4B000`. 10. The loader copies headers and sections, applies relocations, resolves imports, calls the entry point with `DLL_PROCESS_ATTACH`, then invokes the exported `run` function. **The ValleyRAT core is never written to disk.** 11. **Record 3** (2,696 bytes) is the encrypted configuration block, decrypted by Phase 3 using a five-byte key. 12. The RAT checks for administrator privileges; without them it terminates via `FatalExit`. 13. The RAT builds the staging path `C:\Program Files\Common Files` and copies all three original components there under the names in its configuration — the Overwolf executable becomes `444.exe`. 14. All three dropped components are marked `-rhs-`: read-only, hidden and system. 15. Persistence is established through a scheduled task running at user logon, **masquerading as a OneDrive entry**. 16. The RAT hollows `svchost.exe`, reconstructing the command line `C:\Windows\system32\svchost.exe -k netsvcs` at runtime. 17. The hollowed process establishes a TCP connection to the C2 at `103[.]240[.]196[.]115:1234`. ![Three records in the .bin file](https://go.forcepoint.com/sites/default/files/2026-08/fig9-bin-with-three-records.jpg align="center") *The three-record structure inside* `teamspeak_control.bin` *(source: Forcepoint X-Labs).* * * * ## Three Technical Details Worth Separating Out ### The RC4 Key Is Also File-Format Metadata This is the most refined piece of design in the campaign, and it deserves close reading by anyone writing detection rules. Record 2 begins with a single byte, `0x73`, representing a 115-byte key length. The next 115 bytes are the RC4 key, and the remainder is ciphertext. When the reflective loader reassembles the payload in memory, the buffer layout is: **length byte, key, then decrypted data**. That layout places **offset 0x3C inside the key** — and in the PE format, offset 0x3C is where `e_lfanew` lives, the pointer to the real PE headers. The four key bytes at that location are `38 01 00 00`, which resolve little-endian to `0x138`. That value **points exactly to the payload's headers**. ```plaintext 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 ``` The loader reads the 32-bit value at offset 0x3C with `movsxd r14, [r15+3Ch]`, then `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. ![Allocating 291,840 bytes](https://go.forcepoint.com/sites/default/files/2026-08/fig10-zwallocatevirtualmemory-with291840-bytes.jpg align="center") `ZwAllocateVirtualMemory` *requesting exactly 291,840 bytes (source: Forcepoint X-Labs).* **What this means for defenders:** the in-memory payload has no "MZ" at its start and no "PE\\0\\0" at the conventional location. A memory scanner hunting PE headers by magic byte will walk straight past it. Part of the encryption key simultaneously serves as file-format metadata — and that is why the payload parses correctly despite both magic bytes being absent. ### RC4 With One Line Changed 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]`. It is a small change with a very concrete operational consequence: **every standard RC4 decryption tool will return garbage**. An analyst who has not read the code closely will conclude they extracted the wrong key or the wrong offset, and spend time re-deriving something that was already correct. ### Two Keys, One Decryption Routine The campaign uses a single decryption routine with two different keys: * A **115-byte key** shipped inline within Record 2, for the 291 KB payload * A **five-byte key** `01 02 03 04 05` compiled into the RAT, for configuration decryption ![The five-byte configuration key](https://go.forcepoint.com/sites/default/files/2026-08/fig15-five-byte-configuration-key.jpg align="center") *The five-byte configuration key materialised as two immediate operands (source: Forcepoint X-Labs).* The second key appears in two instructions: `mov dword ptr [rbp+30], 0x04030201` writes the first four bytes, and `mov byte ptr [rbp+34], 5` writes the fifth. Phase 3 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. Forcepoint decrypted Record 3 offline using this five-byte key — meaning the **campaign configuration is statically recoverable without executing the sample**, a useful point for analysis teams. * * * ## The Administrator Check, and What It Means for Sandboxes ![Execution terminates if not admin](https://go.forcepoint.com/sites/default/files/2026-08/fig18-execution-terminates.jpg align="center") *Execution terminates via* `FatalExit` *if the user lacks administrator privileges (source: Forcepoint X-Labs).* With the core loaded in memory and its configuration decrypted, ValleyRAT checks its privilege level before moving into persistence and evasion. The RAT constructs a Windows SID with `AllocateAndInitializeSid` — likely for the local Administrators group — then calls `CheckTokenMembership` to test the current process token. 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`**.** This has a notable consequence for automated analysis workflows. It is not sandbox evasion in the classical sense — no VM fingerprint checks, no analysis process name lists, no execution delays. But the effect is equivalent: **a sandbox running the sample under a standard user account will observe no malicious behaviour at all** and may return a clean verdict. If your triage process relies on automated sandbox results to classify samples, this is a specific reason to verify your analysis environment runs with appropriate privileges. * * * ## Persistence and the Final Stage The decrypted Record 3 configuration shows the malware builds the staging directory path `C:\Program Files\Common Files` before accessing its dropped 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`**.** ![Dropped components with -rhs- attributes](https://go.forcepoint.com/sites/default/files/2026-08/fig20-dropped-components.jpg align="center") *Dropped components marked read-only, hidden and system (source: Forcepoint X-Labs).* 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-`. ![Scheduled task masquerading as OneDrive](https://go.forcepoint.com/sites/default/files/2026-08/fig21-scheduled-task-in-onedrive.jpg align="center") *Scheduled task masquerading as a OneDrive entry, running at logon (source: Forcepoint X-Labs).* Persistence is achieved through a **scheduled task configured to run at user logon, masquerading as a OneDrive entry**, with an action that starts a program from a path under the user's local Microsoft OneDrive directory. Finally the RAT performs **process hollowing into** `svchost.exe`, reconstructing the command line `C:\Windows\system32\svchost.exe -k netsvcs` at runtime. This lets it execute under the appearance of a legitimate Windows service host. The hollowed process establishes a TCP connection to the C2 endpoint `103[.]240[.]196[.]115:1234` — unresponsive at the time of Forcepoint's analysis. * * * ## On Attribution: Three Distinct Levels This needs careful presentation, because public sources do not agree on how far to attribute. **Forcepoint does not attribute this campaign to any group.** The X-Labs report is purely technical analysis, describing the infection chain and components without naming an actor. **Foresiet, in an analysis published in July 2026, describes this same campaign** — the same fake tax notice lure, the same three-file Overwolf/TeamSpeak sideloading kit, the same 18 `tscontrol_*` exports — and **attributes it to Silver Fox**, a China-nexus actor identified as the operator of the ValleyRAT (also known as Winos) backdoor. **ValleyRAT/Winos in general is linked to Silver Fox** by multiple vendors in separate reporting. We present these three levels separately rather than collapsing them into a single statement. For internal reporting, the safe formulation is: *"the campaign deploys ValleyRAT; ValleyRAT is linked by multiple sources to Silver Fox; Forcepoint does not attribute this specific campaign."* ### A Discrepancy Between Sources Worth Noting The two analyses describe the same campaign but differ on a technically significant detail: | Item | Forcepoint (Aug 2026) | Foresiet (Jul 2026) | | --- | --- | --- | | DLL characteristics | UPX-packed, Astral-PE mutated | **~30 MB** | | Final payload type | **Native PE32+ AMD64**, header-stomped | **.NET / CLR** | | Loading mechanism | Reflective loading, PE32+ | Execution via the .NET runtime | These are most likely **two variants of the same campaign**, analysed a month apart. The distinction matters practically for anyone writing detection: a rule anchored on .NET characteristics will miss the native variant, and vice versa. If you are building coverage for this campaign, account for both payload forms. * * * ## Indicators of Compromise > Indicators taken from the Forcepoint X-Labs report of 18 August 2026. Domains and IPs are defanged. > > **Note:** Forcepoint publishes hashes as **SHA-1**, not SHA-256. **Primary files** ```plaintext 62e3ba37a23669139a222cd43ec2b202277a4030 07.30Document details.exe Legitimate signed file abused for sideloading f062e682ee38b33141ba03b17880b9cacca0e376 teamspeak_control.dll Malicious DLL executed via DLL sideloading 7de942da8993a45a5a7547de0a883f9b13f2f71c teamspeak_control.bin Encrypted file holding the ValleyRAT core and config ``` **Analysis artifacts (extracted by Forcepoint)** ```plaintext 061f3e304c65f3f062f2aacc41b6d6f8a4f43816 Phase1_teamspeak_control_unpacked.dll Unpacked DLL, Astral-PE mutated ab530af5603ce3f98b51b3c6f612074e020f572e phase2_reflective_loader.bin (Record 1) d03fb03e8969e7ecbd763aa4bdc67a4629e19b10 payload_key_115bytes.bin (Record 2 key) 2d830905581ae5c29d1e6bad27c6b63a097f79d7 phase3_config_encrypted.bin (Record 3) 07846091fdeb1011cbd80d9ca45fd7dcb40b5c40 phase3_config_decrypted.bin (Record 3, decrypted) ``` **Staging URL and C2** ```plaintext dnfyb[.]vip Staging page delivering the ZIP 103[.]240[.]196[.]115:1234 C2, raw TCP ``` **Other download domains in Forcepoint telemetry** > This is where the campaign's real infrastructure scale shows — the same naming pattern across the `.vip` TLD. ```plaintext taobaoker[.]vip kangyue[.]vip wayaya[.]vip cpxxw[.]vip usheng[.]vip yakin[.]vip tanlianmeng[.]vip nsseo[.]vip dywwl[.]vip rpaai[.]vip kejiwei[.]vip shhswz[.]vip suoguan[.]vip zbrhcggp[.]vip ``` **On-host artifacts** ```plaintext # Staging directory C:\Program Files\Common Files\444.exe Renamed Overwolf executable C:\Program Files\Common Files\teamspeak_control.dll C:\Program Files\Common Files\teamspeak_control.bin -> all three marked -rhs- (read-only, hidden, system) # Persistence Scheduled task at user logon, masquerading as a OneDrive entry, action pointing to a path under the local Microsoft OneDrive directory # Process hollowing svchost.exe -k netsvcs (command line reconstructed at runtime) ``` **Technical artifacts usable for detection** ```plaintext # Imports 18 tscontrol_* functions imported from teamspeak_control.dll # Record sizes within the .bin (298,544 bytes total) Record 1 3,992 bytes Phase 2 reflective loader Record 2 291,840 bytes Encrypted ValleyRAT core (with inline 115-byte key) Record 3 2,696 bytes Encrypted configuration (offset 0x483A4) # Keys 0x73 + 115 bytes Inline RC4 key for the payload 01 02 03 04 05 Hardcoded key for the configuration # Algorithm variant Modified RC4: S[i] XOR S[j] instead of S[(S[i] + S[j]) & 0xFF] # In-memory payload characteristics No "MZ" at offset 0x00 "PE\0\0" at offset 0x138 zeroed e_lfanew at 0x3C sits inside the key, value 0x138 ImageBase 0x180000000, SizeOfImage 0x4B000, 5 sections, machine 0x8664 ``` * * * ## MITRE ATT&CK Mapping | Tactic | Technique ID | Technique Name | Observed in campaign | | --- | --- | --- | --- | | Resource Development | T1583.001 | Acquire Infrastructure: Domains | 25+ domains on the `.vip` TLD | | Initial Access | T1566.002 | Phishing: Spearphishing Link | Tax-themed email linking to the staging page | | Execution | T1204.002 | User Execution: Malicious File | Victim runs the renamed Overwolf executable | | Persistence | T1574.002 | Hijack Execution Flow: DLL Side-Loading | Signed EXE loading `teamspeak_control.dll` | | Defense Evasion | T1036.005 | Masquerading: Match Legitimate Name or Location | EXE renamed as a document; OneDrive task; `svchost -k netsvcs` | | Defense Evasion | T1027.002 | Obfuscated Files or Information: Software Packing | DLL packed with UPX | | Defense Evasion | T1027 | Obfuscated Files or Information | Astral-PE header mutation; zeroed TimeDateStamp; mangled import names | | Defense Evasion | T1140 | Deobfuscate/Decode Files or Information | Modified RC4 with two distinct keys | | Defense Evasion | T1620 | Reflective Code Loading | Record 1 loads the ValleyRAT core entirely in memory | | Defense Evasion | T1055.012 | Process Injection: Process Hollowing | Hollowing `svchost.exe` | | Defense Evasion | T1564.001 | Hide Artifacts: Hidden Files and Directories | Hidden files in the archive; `-rhs-` attributes on dropped components | | Persistence | T1053.005 | Scheduled Task/Job: Scheduled Task | Logon task masquerading as OneDrive | | Discovery | T1069.001 | Permission Groups Discovery: Local Groups | `CheckTokenMembership` against the Administrators group | | Discovery | T1033 | System Owner/User Discovery | `IsUserAnAdmin` | | Command and Control | T1095 | Non-Application Layer Protocol | Raw TCP connection to C2 | | Command and Control | T1571 | Non-Standard Port | Port 1234 | | Command and Control | T1105 | Ingress Tool Transfer | ZIP download from the staging page | | Exfiltration | T1041 | Exfiltration Over C2 Channel | ValleyRAT's C2 channel | * * * ## Assessment **Code signing was designed to answer "has this file been modified", not "what is this file about to do".** That is the campaign's central point, and it deserves stating plainly because it is not a flaw in the signing mechanism. The Overwolf executable in this chain is **entirely intact**. Its signature is valid because it genuinely is the file Overwolf signed. The attackers modified nothing — they simply **placed another file next to it**, exploiting entirely standard Windows behaviour: an executable resolves DLL dependencies from its own folder first. Signature-based controls answer their question correctly. The problem is that it is not the question that needed answering here. **The best detection point is context, not file content.** There is nothing in `07.30Document details.exe` to detect. But there is a great deal in the circumstances of its appearance: * An Overwolf binary running from Downloads or Desktop, **without the rest of an Overwolf installation around it** * Overwolf is overlay software for PC gamers — it **has no reason to appear on a finance or HR workstation** * An executable spawning `svchost.exe` with a `-k netsvcs` command line * Three files sharing a base name with different extensions, sitting in `C:\Program Files\Common Files` with `-rhs-` attributes None of these requires prior knowledge of a hash or a malware family name. **On removing local administrator rights.** This is the most concrete argument I have seen in some time for a control usually discussed in the abstract. In an environment where users hold local admin rights, this chain runs all the way to C2. In an environment where they do not, **the malware calls** `FatalExit` **and quits by itself**. No EDR block required, no rule fired — it stops on its own. The limit should be stated: this holds for the variant Forcepoint analysed. Another variant could add a low-privilege branch. But here, the control's effectiveness is observed rather than assumed. **On the payload with no magic bytes.** The `e_lfanew`\-inside-the-key detail is the kind of design that shows the authors understand both the PE format and how defensive tooling looks for it. For teams building memory-scanning detection the message is clear: **scanning for "MZ" or "PE\\0\\0" magic bytes will miss this**. What is catchable here is the allocation and mapping behaviour, not the content. ### Relevance for Vietnam **Tax lures are universal, and this Indian version translates intact into a Vietnamese context.** Vietnam has the General Department of Taxation, the eTax and eTax Mobile systems, and an annual personal income tax finalisation season — everything needed to rebuild this exact scenario in Vietnamese. Two details from the Indian version stand out because neither depends on language or country: *Citing real legal provisions.* The email cites Section 271(1)(c) and Section 276C — both genuine. A recipient who looks them up quickly will find they are real, and that raises credibility rather than lowering it. An equivalent Vietnamese version using provisions of the Law on Tax Administration is entirely feasible. *Delivery to a shared mailbox.* Forcepoint cites this as a fraud indicator, but it is also a calculated targeting choice. Shared mailboxes such as `ketoan@`, `hcns@` or `info@` typically have **no single accountable owner**, rarely feature in awareness training, and are often accessed by several people using one set of credentials. In many organisations we encounter this is a near-unmonitored attack surface — and with a tax lure, the accounting mailbox is exactly where such an email *should* arrive, so it raises no suspicion. **A note on application catalogues.** This chain works only because Windows loads DLLs from the executable's own directory. If your organisation runs application allowlisting, the question to ask is not "is Overwolf on the list" but **"is this binary allowed to run from the Downloads folder"**. Many publisher-based allowlisting deployments would permit this exact chain, because the publisher genuinely is legitimate. * * * ## Recommendations * **Remove local administrator rights from standard user accounts** — in this chain, the absence of admin privileges causes the malware to terminate itself before establishing persistence or reaching C2. * **Alert on validly signed binaries executing from Downloads, Desktop or temp directories** without the rest of their installation present — particularly software outside your application catalogue. * **Hunt two specific artifacts:** files in `C:\Program Files\Common Files` carrying read-only + hidden + system attributes, and logon scheduled tasks masquerading as OneDrive entries. * **Block the 25** `.vip` **domains in the IOC list**, and consider tighter monitoring of the `.vip` TLD generally if your organisation has no business need for it. * **Verify your sandbox environment runs with appropriate privileges** — this sample terminates without admin rights, so a misconfigured sandbox will return a clean verdict on a malicious sample. * **Bring shared mailboxes into awareness training and monitoring scope**, assign a named owner to each, and consider stricter controls on attachments and links arriving in them. * * * ## References * Forcepoint X-Labs — [Signed Overwolf Binary Sideloads ValleyRAT Malware in India Tax Scam](https://www.forcepoint.com/blog/x-labs/valleyrat-overwolf-sideload-tax-scam), Raghu Ram (18 August 2026) — original report * Redmondmag — [ValleyRAT Attack Turns Legitimate Windows App into a Malware Launcher](https://redmondmag.com/articles/2026/08/19/valleyrat-attack-turns-legitimate-windows-app-into-a-malware-launcher.aspx) (19 August 2026) * Foresiet — [Fake Tax Notice Campaign: ValleyRAT Loader Unmasked (Part II)](https://foresiet.com/blog/fake-tax-notice-campaign-valleyrat-unmasked/) (July 2026) — analysis of the same campaign, with attribution * MITRE ATT&CK — [T1574.002: DLL Side-Loading](https://attack.mitre.org/techniques/T1574/002/) * MITRE ATT&CK — [T1620: Reflective Code Loading](https://attack.mitre.org/techniques/T1620/) * MITRE ATT&CK — [T1055.012: Process Hollowing](https://attack.mitre.org/techniques/T1055/012/)