AI Security vs Fake Downloads: Stop Gh0st RAT Fast

Most companies still treat “software downloads” as a low-risk activity. That’s a mistake.

Unit 42 tracked two connected 2025 campaigns that used large-scale brand impersonation—over 2,000 lookalike domains in the first phase, then 40+ impersonated apps in the second—to push Gh0st RAT variants to Chinese-speaking users. The tactics weren’t subtle: disposable domains, trusted cloud hosting, signed executables, and multi-stage installers designed to slip past controls that rely on reputation and known indicators.

This is exactly the kind of threat where AI in cybersecurity earns its keep. Not by “blocking the bad domain” (that list is always late), but by spotting behavior that doesn’t match normal software delivery and installation—even when the file is signed, the traffic looks like a mainstream cloud provider, and the attacker rotates infrastructure every week.

What these impersonation campaigns reveal about modern malware delivery

Answer first: These campaigns show that attackers are optimizing for scale + trust borrowing—and that defenders need detection that follows behavior, not brand names or static IoCs.

Across both phases, the operator ran a repeatable playbook:

• Impersonate software people already want (enterprise tools, secure messaging, gaming platforms, “popular AI software”).
• Spray domains at scale so reputation-based blocking can’t keep up.
• Use installers (MSI/EXE) as the delivery vehicle because they look normal and create lots of benign noise.
• Hide the real payload behind multiple stages, including scripts, encrypted blobs, and DLL side-loading.

The strategic detail that matters: these weren’t generic lures. The actor focused on software popular in Chinese-speaking communities (including tools used to bypass censorship). That targeting increases click-through because it matches real user intent—people are already searching for the thing the attacker is “offering.”

Why the “download portal” is the new phishing email

Email phishing still works, but search and ad-driven discovery is quietly becoming a bigger problem:

• Users search for a tool
• They land on a convincing download page
• They install a trojanized package

Security teams often don’t monitor this pathway as closely as inboxes. Yet it creates the same outcome: user-driven execution of a malicious file.

Campaign Trio (Feb–Mar 2025): 2,000+ domains, one payload source

Answer first: Campaign Trio scaled by making the front-end disposable and the payload centralized.

In the first phase (February–March 2025), the actor registered over 2,000 domains, largely on TLDs like .top and .vip, often with brand names plus random suffixes. Over 2,000 domains resolved to just three IPs:

• 154.82.84[.]227
• 156.251.25[.]43
• 156.251.25[.]112

That “many domains → few servers” pattern is a tell. It’s optimized for speed: if 200 domains get blocked, the attacker still has 1,800.

The lure strategy: popular tools + AI branding

The impersonation choices weren’t random:

• i4tools (over 1,400 domains): utility for managing Apple devices
• Youdao (over 600 domains): dictionary/translation
• DeepSeek (a handful of domains): an AI brand used to ride current attention

Impersonating AI software is more than hype-chasing. It works because AI tools are often installed quickly, sometimes outside standard procurement, and frequently by technical users who are comfortable running installers.

The infection chain: MSI custom actions that bury the malicious step

The malware was typically delivered as a ZIP containing either:

• a malicious MSI, or
• a standalone EXE

The MSI approach is clever because MSI packages naturally run many actions. In Unit 42’s analysis, one malicious MSI had 43 custom actions, with the malicious execution hidden as just one entry among legitimate-looking operations.

The second-stage executable then:

• downloads an obfuscated binary
• decodes it
• executes it

Final payload: Gh0st RAT, with capabilities including keystrokes, screenshots, remote shell, and additional downloads. Observed post-compromise behavior included:

• scheduled tasks for persistence
• PowerShell to add Windows Defender exclusions
• encrypted TCP C2 (observed on port 8080)

Campaign Chorus (May 2025): cloud buckets + multi-stage MSI + DLL side-loading

Answer first: Campaign Chorus improved evasion by borrowing trust from cloud services and signed software.

Starting May 2025, the actor expanded to 40+ impersonated applications and introduced a more structured, wave-based rollout:

• Wave 1: 40 domains (prefix guwaanzh) registered May 15
• Wave 2: 51 domains (prefix xiazaizhadia) registered May 26–28

This is operational discipline. Waves let attackers test lures, change infrastructure, and limit blast radius when defenders respond.

Cloud-hosted payloads: why network controls miss it

Instead of hosting payloads on a single obvious server, the landing pages used redirection domains that fetched ZIP archives from public cloud storage.

That matters because many organizations:

• allow mainstream cloud domains broadly
• don’t decrypt/inspect all outbound traffic
• rely on blocklists that struggle with fast-changing redirectors

In other words, the attacker made the download traffic look like normal business.

VBScript inside MSI: file assembly to defeat static scanning

Campaign Chorus embedded VBScript as an MSI custom action. Rather than storing a single suspicious binary, the MSI included payload data split across multiple files in the embedded cabinet.

The script:

1. reads multiple components
2. merges them into one payload
3. decrypts using a stored password
4. writes the next stage to disk

This defeats a lot of “scan the installer” workflows because there’s no single obvious malicious blob until runtime.

DLL side-loading with a signed executable: the trust trap

The final step used DLL side-loading:

• a legitimate signed executable (wsc_proxy.exe)
• a malicious DLL (wsc.dll) placed beside it

Windows loads the local DLL first, so the attacker’s code runs inside a trusted process. Many environments still over-trust signed binaries, especially if allow-listing rules were written years ago.

If your detection logic is “signed process = safe,” this chain wins.

Where AI-driven defense fits (and where it doesn’t)

Answer first: AI helps most when it’s trained and tuned to detect inconsistencies—between user intent, download behavior, installer behavior, and endpoint outcomes.

AI won’t fix weak patching, bad admin hygiene, or uncontrolled software installation by itself. But it can dramatically reduce time-to-detection when the attacker:

• rotates domains constantly
• uses cloud hosting
• hides payloads across stages
• executes inside signed binaries

What to detect: behaviors that don’t belong in real installers

If I were building detections for this specific playbook, I’d focus on a few high-signal anomalies.

Network + web signals (pre-execution):

• first-time-seen domains that look brand-adjacent (typos, suffix patterns)
• sudden bursts of domains resolving to a small IP set
• download flows involving multiple redirects immediately before an MSI/ZIP
• “consumer-style” download patterns from corporate endpoints (especially outside software portals)

Endpoint signals (execution and post-execution):

• msiexec.exe spawning script engines (VBScript) or unusual child processes
• installer actions that write executable content to user-writable directories and then execute it
• a signed binary executed from a non-standard path alongside a new DLL (classic side-load shape)
• PowerShell commands that modify Defender exclusions
• scheduled task creation immediately following a fresh installer run

AI-based anomaly detection is particularly effective when it learns what “normal” looks like for:

• your sanctioned software installers
• your common install paths
• your typical parent/child process trees

Then it flags what’s off—even if it’s never seen wsc_proxy.exe abused that way before.

The practical win: collapsing the detection window

These campaigns rely on defenders being slow:

• slow to spot fake domains
• slow to take down infrastructure
• slow to notice that “a user installed something” turned into persistence and C2

AI-driven security operations can reduce that window by automating triage:

• correlate download event → installer execution → script action → persistence as one incident
• score risk based on sequence, not a single indicator
• contain quickly (isolate endpoint, kill process tree, block destination patterns)

That’s how you stop Gh0st RAT before it becomes a months-long espionage foothold.

What to do this quarter: a defensive checklist that matches the attacker’s playbook

Answer first: Control software acquisition paths, detect suspicious installer behaviors, and treat cloud-hosted downloads as inspectable—not automatically trusted.

Here’s a practical set of moves that map directly to what Unit 42 observed.

1) Lock down “where software comes from”

• Require installs from a managed software portal (MDM/RMM/package manager) whenever possible.
• Block or warn on installer downloads from newly registered domains and low-reputation TLDs.
• For high-risk teams (finance, IT admins, executives), consider stricter egress rules for ad-hoc downloads.

2) Add installer-focused detections

Write detections that treat these as high-risk combinations:

• msiexec.exe + VBScript/custom actions executing external binaries
• MSI writes + immediate execution from %AppData%, %Temp%, or user profile subfolders
• first-run of a signed binary from a user-writable directory plus DLL load from the same directory

3) Treat Defender exclusion changes as an incident, not a log entry

Attackers love “quietly exclude this folder.” It’s fast, reliable, and often ignored.

• Alert on Defender exclusion modifications
• auto-enrich with preceding process tree and downloaded file origin
• auto-contain endpoints if exclusion change follows an untrusted installer

4) Build cloud-download visibility, not cloud trust

• monitor for multi-hop redirects that end in ZIP/MSI
• inspect file types and run detonation/sandbox analysis on suspicious installers
• look for new cloud bucket paths suddenly accessed by many endpoints

5) Prepare for burn-and-churn infrastructure

Blocklists still have value, but they must be paired with behavior-based controls.

• detect domain registration bursts that match your user base’s language/region patterns
• track lookalike domain naming conventions targeting your org’s commonly used apps
• share IoCs internally fast, but assume the attacker replaces them weekly

The bigger lesson for the AI in Cybersecurity series

Impersonation at scale is what happens when attackers industrialize trust. They don’t need zero-days if they can get users to install a “normal” package that isn’t normal at all.

The way out is also industrial: AI-driven threat detection that connects dots across web, endpoint, identity, and network—then responds quickly enough that multi-stage chains never reach steady-state persistence.

If your organization wants a simple benchmark, use this one: Can you detect and contain a malicious MSI that uses script-based assembly and DLL side-loading within 15 minutes of first execution? If the honest answer is no, that’s the gap these campaigns are built to exploit.

What would change in your environment if you assumed every “popular download” could be a digital doppelganger—and designed detection around behavior rather than brand names?