Home » EndClient RAT Targets NGOs via Signed MSI Installer

EndClient RAT Targets NGOs via Signed MSI Installer

Signed MSI delivers EndClient RAT while AutoIt loader runs in memory EndClient RAT abuses code-signing trust to bypass SmartScreen and persist

Attackers are pushing a remote access trojan they call EndClient RAT. They use a signed Microsoft Installer package that looks legitimate, so defenders often trust it. Because the installer bears a stolen certificate, Windows trust checks and SmartScreen signals can mislead users. Consequently, the campaign lands execution, gains persistence fast, and blends with normal administrative activity.

𝗜𝗻𝗰𝗶𝗱𝗲𝗻𝘁 𝗼𝘃𝗲𝗿𝘃𝗶𝗲𝘄

The lure pivots on a file named “StressClear.msi.” It arrives during targeted chats and direct messages where operators guide victims to run it. The MSI was signed with a certificate issued to Chengdu Huifenghe Science and Technology Co. Ltd., which lends false legitimacy. Because the package appears trusted, users proceed. Meanwhile, antivirus coverage stays low during the first hours of a campaign, and SmartScreen prompts do not always block execution, especially when policy allows user bypass.

𝗔𝘁𝘁𝗮𝗰𝗸 𝗰𝗵𝗮𝗶𝗻: 𝘀𝗼𝗰𝗶𝗮𝗹 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 → 𝘀𝗶𝗴𝗻𝗲𝗱 𝗠𝗦𝗜 → 𝗱𝗲𝗰𝗼𝘆 + 𝗹𝗼𝗮𝗱𝗲𝗿

Operators initiate one-to-one conversations with high-value targets and deliver the MSI. As the user runs the installer, the package performs a decoy install of WIZVERA VeraPort’s Delfino banking authentication component to reinforce trust. At the same time, it deploys a loader that hands off control to an obfuscated script. Users see something that looks like routine software setup; defenders see a trusted chain that rarely raises immediate red flags.

𝗟𝗼𝗮𝗱𝗲𝗿 𝗺𝗲𝗰𝗵𝗮𝗻𝗶𝘀𝗺: 𝗔𝘂𝘁𝗼𝗜𝘁 + 𝗶𝗻-𝗺𝗲𝗺𝗼𝗿𝘆 𝗲𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻

The MSI drops AutoIt3.exe with a heavily obfuscated script. The script executes in memory, avoids noisy file writes, and hides behind a legitimate parent process. Static scanners struggle because the loader looks like a standard AutoIt runtime. EDR can still catch it; however, triage needs lineage and behavior, not signatures alone.

𝗣𝗲𝗿𝘀𝗶𝘀𝘁𝗲𝗻𝗰𝗲 𝗮𝗻𝗱 𝗲𝘃𝗮𝘀𝗶𝗼𝗻

The malware establishes a scheduled task named “IoKlTr.” It runs once per minute and points to content staged under Public\Music, a path that reduces suspicion in some environments. To prevent duplicate instances, the binary sets a global mutex with a long GUID-like value. During login, a startup link relaunches the AutoIt payload. When Avast runs on the host, the loader mutates: it pads with junk data, shifts file names, and attempts to change its static profile to slip past product-specific heuristics.

𝗖𝟮 𝗽𝗿𝗼𝘁𝗼𝗰𝗼𝗹 𝗮𝗻𝗱 𝗰𝗮𝗽𝗮𝗯𝗶𝗹𝗶𝘁𝗶𝗲𝘀

The implant opens a direct TCP socket and exchanges JSON messages. Each message includes sentinel markers—“endClient9688” from the client and “endServer9688” from the server. The protocol supports command execution, file retrieval, and exfiltration. Because it rides over generic TCP and mimics normal tools, simple domain-block lists rarely work. Therefore, defenders should profile beacon intervals and TLS/JA3-JA4 traits where encryption wraps the channel.

𝗪𝗵𝗼’𝘀 𝗮𝘁 𝗿𝗶𝘀𝗸

Targets include civil society workers and NGOs, yet the delivery method generalizes. Any team that trusts signed MSI packages without additional checks can fall into scope. Because many organizations permit user-approved installs, and because SmartScreen can present a choice rather than a hard block, pressure and urgency in chat can defeat caution.

𝗗𝗲𝘁𝗲𝗰𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗵𝘂𝗻𝘁𝗶𝗻𝗴

Focus on behavior. Trace MSI install chains that spawn AutoIt3.exe. Flag AutoIt that launches cmd.exe, powershell.exe, or WScript with suspicious arguments. Hunt for the IoKlTr task scheduled per minute and look for binaries in Public\Music. On the network side, measure short, periodic beacons with small JSON payloads and unusual framing. When TLS wraps traffic, compare fingerprints; steady JA3/JA4 pairs across distinct destinations can expose automation. To validate, walk process lineage from MSI to AutoIt to child shells.

𝗠𝗶𝘁𝗶𝗴𝗮𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗵𝗮𝗿𝗱𝗲𝗻𝗶𝗻𝗴

Tighten trust first. Enforce SmartScreen blocking in policy so users cannot bypass warnings for untrusted installers. Restrict MSI execution to admins and known publishers. Where possible, revoke local trust for the stolen certificate and monitor for its issuer. Add application control rules that watch AutoIt3.exe and restrict script interpreters when launched by MSI installers. Meanwhile, map controls to your baseline and roll out changes in a limited pilot before broad enforcement.

𝗢𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗶𝗺𝗽𝗮𝗰𝘁 𝗮𝗻𝗱 𝗻𝗲𝘅𝘁 𝘀𝘁𝗲𝗽𝘀

Prioritize certificate-based risk. Identify hosts that recently executed signed MSI packages from outside your software distribution flow. If AutoIt appears on endpoints that do not develop or test scripts, review those machines first. Because the C2 uses stable framing strings, craft detections for that pattern on decrypted traffic or on egress inspection points that see metadata. After containment, validate by removing the IoKlTr task, clearing startup links, and confirming the mutex no longer appears in active processes. Finally, brief users: signed ≠ safe.

Signed installers lower friction for attackers. EndClient RAT leans on stolen code-signing, AutoIt-backed in-memory execution, and custom JSON-over-TCP C2 to cut noise and persist. Because the chain blends with normal administration, SOC teams should tighten trust decisions, instrument MSI-to-AutoIt lineage, and enforce SmartScreen blocks that remove the user’s choice. If you treat signatures as one signal—not a verdict—you reduce this family’s room to maneuver.

One thought on “EndClient RAT Targets NGOs via Signed MSI Installer

Leave a Reply

Your email address will not be published. Required fields are marked *