What happened (short version)

Here’s the messy, slightly sci-fi summary: an advanced group has been abusing the update area of the ViPNet product suite to plant a sneaky loader and a proxy inside systems used by Russian organizations — think government, energy, transport, education and logistics. The campaign, tracked as HelloNet, has been active since at least May and uses a staged approach that gets code running with elevated rights and stays across reboots.

The attackers dropped a malicious DLL into the local ViPNet Update System folder so the legitimate updater would load it at startup. That DLL (nicknamed HelloInjector) injects into the svchost.exe process, then runs a memory-resident proxy/loader dubbed HelloProxy, which talks back to a command-and-control server to fetch more modules. Those follow-on pieces include a remote executor, a cleaner that erases ViPNet logs, and a Rust-based backdoor that can move files and run commands.

Researchers note they don’t see evidence that ViPNet’s official update servers were compromised — instead it looks like an attacker got write access locally and replaced or added files. Attribution is tentative: some artifacts hint at a Chinese-speaking actor, but the evidence is weak and could be a deliberate false flag.

How to detect and respond (quick checklist)

If you run ViPNet or support environments that do, these are the practical signals and actions to prioritize. No, you don’t need a lab coat — just a little vigilance and some checklist discipline.

  • Inspect the ViPNet Update directory for unexpected files (for example, wtsapi32.dll or other unfamiliar DLLs) and note file timestamps and owners.
  • Monitor svchost.exe behavior — look for unusual DLL injections, unexpected network connections, or processes spawning from updater binaries like itcsrvup64.exe.
  • Watch network traffic and logs for connections to odd external hosts, especially on ports 5003, 5060 and 443, which were observed in this campaign.
  • Check for artifacts of log tampering or missing ViPNet logs (the attackers used a cleaner to erase traces).
  • Harden update directories with file integrity monitoring and least-privilege controls so local accounts can’t plant DLLs in trusted update locations.
  • Use EDR/AV to detect memory-resident loaders and anomalous child processes; apply threat-hunting queries for the loader/proxy behavior described above.
  • Assume compromise for any host where a malicious update was found: isolate the host, collect forensic images, and rotate credentials and certificates used by that system.

Short version: don’t trust update folders to be quiet places — treat them like high-risk real estate. Keep an eye on the Update directory, svchost activity, and those specific ports. And if you spot anything weird, assume the attacker is trying to hide and move like they belong there.

Want to sound smart in the next incident review? Mention the three-stage pattern: loader → in-memory proxy → modular implants. It’s a neat little chain that’s effective because it piggybacks on a trusted process and trims its tracks.