🚨 From a WhatsApp ZIP to Active Remote Access: Inside a ValleyRAT-Associated Windows Compromise

A routine-looking ZIP archive received through WhatsApp Web became the starting point of a confirmed Windows endpoint compromise.

During forensic examination of the submitted artifacts, investigators identified a malicious Windows executable, a suspicious DLL masquerading as an NVIDIA/WebView2 component, persistence mechanisms, privilege-elevation activity, active command-and-control communication and a second-stage payload delivered directly through C2 traffic.

The investigation identified the malware as ValleyRAT-associated based on the observed sample characteristics and hash correlation. The primary executable was a PE32+ Windows binary, while the supplied DLL presented itself as an NVIDIA Message Bus component while exposing WebView2-related exports and importing APIs associated with process injection, token manipulation, memory manipulation and dynamic loading.

The most significant finding was that the incident was not limited to the execution of one malicious file.

The initial artifact was a ZIP archive received through WhatsApp Web.

The archive contained a Windows executable and a suspicious DLL.

At first glance, this might look like a conventional malware-delivery scenario.

But the deeper investigation revealed multiple layers.

The executable also referenced URLs associated with the downloader component.

The interesting part was its dependency.

And the supplied DLL was designed to satisfy that dependency.

The report ultimately assessed the DLL as a malicious/trojanized loader and found the relationship between the EXE's WebView2 dependency and the supplied DLL's WebView2 exports consistent with DLL sideloading/search-order hijacking.

The supplied DLL was particularly interesting.

Company: NVIDIA Corporation Original Filename: MessageBus.dll Product context: NVIDIA Message Bus

And its exported functions included legitimate-looking WebView2 APIs such as:

alongside NVIDIA-themed exports.

File metadata is not identity.

A DLL can claim to belong to a trusted vendor.

A filename can look legitimate.

A version number can look legitimate.

A directory can look legitimate.

None of these prove authenticity.

These capabilities are not sufficient by themselves to prove that every imported function was executed.

But together they created a strong technical picture of a DLL capable of process manipulation, privilege-related activity, registry modification and dynamic loading.

Dynamic analysis provided the next layer of evidence.

The initial executable started from Explorer.exe at medium integrity.

The process subsequently appeared at High integrity.

The investigation assessed the ms-settings activity and ComputerDefaults.exe execution as consistent with UAC-bypass staging.

hierarchy.

More importantly, successful deletion operations were observed after the registry activity.

This is important from a forensic perspective.

The malware wasn't simply creating artifacts.

It was also performing cleanup.

Attackers don't only create evidence.

They can also try to remove evidence.

can become extremely valuable during incident response.

The report notes that the malware used public writable directories and NVIDIA-themed naming to conceal its components.

The NVIDIA-themed directory contained the persistent executable and watchdog BAT.

Trusted vendor names appearing in unusual writable locations deserve investigation.

A filename such as nvcontainer...exe should not automatically be trusted merely because “NVIDIA” appears in the path.

The investigation identified a BAT watchdog designed to maintain process execution.

This provided another persistence/resilience mechanism beyond the scheduled task.

The investigation then uncovered a second persistence mechanism.

A scheduled task named: "nvcontainer.FvSDKTestClient" was configured to launch the malicious executable from the C:\Users\Public\NvContainer\ location.

Removing one mechanism would not necessarily remove the entire infection.

This was where the investigation became significantly more interesting.

The report attributes TCP/7800 as the primary long-lived C2/control channel and TCP/7811 as the secondary payload channel.

The process-level evidence was also important.

This links the malicious process to the observed C2 connection rather than merely showing an unrelated network conversation.

One of the most valuable parts of the investigation was the reconstruction of the C2 protocol.

as a decoded control/heartbeat value.

was associated with payload delivery.

The PCAP allowed investigators to reconstruct the application-layer behaviour.

The 7811 connection transferred a large server-to-client payload.

The recovered payload was unsigned and contained strings associated with public IP lookup services:

This is one of the most important findings in the investigation.

The network wasn't only carrying commands.

It was carrying malware.

The C2 server effectively acted as a delivery mechanism for additional capability.

If a defender had only searched for the original EXE hash, they might have missed the later-stage activity.

If they had only blocked the C2 IP, they might have missed the local persistence.

If they had only removed the scheduled task, the watchdog could potentially restore the process.

If they had only removed the visible DLL, the malware could potentially retrieve another payload.

This demonstrates why modern incident response needs multi-source correlation.

The investigation identified behaviour corresponding to several ATT&CK techniques.

The report explicitly distinguishes capability from observed execution for some behaviours. For example, ClearEventLog capability was identified through imports, but execution was not established.

That distinction is important.

An imported API is not automatically proof that the malware executed that capability.

🔎 File IOCs

These indicators are taken directly from the anonymized investigation report.

The report states that the domain resolved to the observed C2 IP in the supplied PCAP.

There are five layers that make this investigation particularly valuable for defenders.

A ZIP archive was received through WhatsApp Web.

The malicious DLL adopted WebView2/NVIDIA characteristics.

The malware staged an elevation path through ms-settings and ComputerDefaults.exe.

Scheduled Task + watchdog.

The malware retrieved a second-stage PE payload through TCP/7811.

Initial Access → Execution → Elevation → Persistence → C2 → Payload Delivery → Remote Access

SOC teams can convert this investigation into practical hunting opportunities.

followed by cleanup/deletion.

There is another important aspect of this incident.

The reported incident included suspicious WhatsApp activity and financial loss.

Could malware operating on a Windows system interact with an authenticated WhatsApp Web session?

Technically, such interaction is possible.

A compromised endpoint can potentially interact with applications and browser sessions available to the logged-in user.

However, the forensic evidence in this investigation does not conclusively establish the exact mechanism by which the WhatsApp session was accessed or controlled.

The report therefore treats the connection between the malware compromise, WhatsApp impersonation and the reported financial loss as evidence-qualified rather than conclusively proven.

This distinction is extremely important for responsible threat reporting.

This investigation demonstrates why IOC-only detection is not enough.

The strongest detection happens when all five questions can be answered.

The most interesting finding from this investigation isn't the malware hash.

It isn't even the C2 IP.

It is the architecture of the compromise.

This is why defenders should never stop their investigation after finding the first malicious executable.

The first payload may only be the door.

The real threat may arrive after the door is already open.

☑ Monitor execution from user-writable directories ☑ Hunt suspicious WebView2 DLLs ☑ Validate NVIDIA-related binaries ☑ Monitor ComputerDefaults.exe abuse ☑ Monitor ms-settings registry modifications ☑ Audit scheduled tasks ☑ Monitor suspicious BAT watchdogs

☑ Inspect long-lived outbound connections ☑ Correlate network traffic with processes ☑ Inspect unusual non-standard ports ☑ Detect secondary payload transfers ☑ Monitor DNS resolution of suspicious domains

☑ Preserve the original ZIP ☑ Hash every artifact ☑ Capture memory where possible ☑ Preserve PCAP ☑ Collect EDR telemetry ☑ Review browser/session activity ☑ Investigate persistence ☑ Revoke compromised credentials/sessions ☑ Hunt for lateral movement ☑ Determine whether additional endpoints were affected

This anonymized investigation demonstrates a confirmed malware-enabled Windows endpoint compromise involving a ValleyRAT-associated execution chain.

The evidence showed malicious execution, a trojanized WebView2/NVIDIA-themed DLL, privilege-elevation activity, scheduled-task and watchdog persistence, active C2 communication and delivery of a secondary PE32+ DLL containing remote-access capabilities.

Don't investigate the file. Investigate the attack chain.

A malicious file is only one piece of the incident.

How did it enter?

What did it execute?

How did it elevate?

How did it persist?

Where did it connect?

What did it download?

What could the attacker do next?

That is where malware analysis becomes incident response.

And that is where an IOC becomes Threat Intelligence.

From File to Forensics. From IOC to Attack Story.

Think Before You Click. Stay Aware. Stay Secure.