Security researchers just found a malware campaign built around a file that never plays. Censys, the internet-scanning firm that maps exposed infrastructure worldwide, tracked 18 distinct malware builds across 40 live delivery endpoints in six hosting networks and four countries, all pushing a remote-access tool that dates to 1989 through video files engineered to look real and do nothing else.
What Censys Found
Andrew Northern, a principal security researcher at Censys, published the findings on August 28 under a title that states the problem outright: “The Video That Plays You.” The delivery infrastructure appears to have gone live on August 21. Censys’ scanning system, ARC, picked up the first Cloudflare-fronted host serving raw PowerShell the next day.
The 40 tracked endpoints don’t hide as neatly as a single tactic would suggest. Twelve are origin servers, exposed directly. Another 12 sit behind Cloudflare edge addresses that front roughly half the tracked hostnames. The remaining domains and bare IP addresses expose their origins directly too. That means most of this infrastructure, not the minority, was never actually hidden. The data points to operators who cared more about standing servers up quickly than about covering their tracks.
What Censys did not capture is the lure itself. Its report labels that gap “Inferred Entry Point”: two later stages in the infection chain systematically wipe the Windows registry key that records commands typed into the Run dialog, a cleanup step that only makes sense if a victim typed and ran something there. That is a forensic footprint, not a confirmed pretext, and Censys stops short of naming the specific page or prompt that got a command running in the first place.
Inside the File That Was Built Not to Play
The infection chain starts with an environment check. A first-stage script compares the machine’s computer name against encoded markers built to catch sandboxes and analysis tools, and quits if it doesn’t like what it finds. Once clear, it compiles a small C# program on the fly that requests the carrier file using a spoofed Chrome browser signature, then scans the file’s internal structure for a 16-byte marker specific to that build.
The carrier is a 6.5-megabyte file that Censys describes as passing a “shallow file type check” while being “effectively empty.” A single “uuid” box, a section the ISO Base Media File Format reserves for optional metadata, takes up 99.95 percent of it. Inside sits an XOR decryption key and a compressed PowerShell script that expands to nearly 17 megabytes once unpacked. The video track carries zero-by-zero dimensions and none of the decode parameters a real MP4 needs. Standard validation tools like ffprobe reject it outright. The file was never meant to play. It was built to pass one specific check and stop there.
A Familiar Payload, a New Disguise
Every one of the 18 builds Censys tracked ends the same way: installing NetSupport Manager, a remote-administration tool NetSupport Ltd first released for DOS-based networks in 1989. The final stage drops the client into a randomized subdirectory under C:\Users\Public and sets up persistence through the SecurityHealth Run key. Security tools frequently allowlist NetSupport by name, treating it as sanctioned IT software even when a stranger controls the session on the other end.
Pairing NetSupport with a fake-CAPTCHA “ClickFix” lure, where a page talks a visitor through pasting a command into the Run dialog, is not new. The Hacker News documented that combination as far back as February 2025. What’s new here is the wrapper: routing delivery through a file built to pass as an MP4 instead of as a script or an executable.
Six autonomous systems host the infrastructure, with providers in Frankfurt, Los Angeles, Helsinki, and Bellinzona. The command-and-control gateway runs on a host geolocated to Bellinzona, Switzerland, inside the AS209413 network. Censys found the two domains behind that gateway were registered less than 80 seconds apart, timing that points to automated, templated infrastructure rather than one attacker standing up each server by hand.
Why Automated Filters Missed It
The reason the campaign worked is not sophistication. It is a structural gap in how most security tools inspect files. Automated scanners commonly confirm a file’s type by reading its header, the handful of opening bytes that identify a format, rather than decoding the whole file. A PDF that opens like a PDF gets treated as a PDF. An MP4 with a valid container header gets treated as a video, whether or not it actually plays. Attackers who understand that shortcut can build a file that satisfies the check without ever satisfying the format.
NetSupport’s abuse through ClickFix-style pages was already a known problem before this campaign. Wrapping delivery in a fake MP4 extends the same trick to any security layer that still trusts a header signature over an actual render, and there’s no reason it has to stop at video. An image file, or any other container format with an optional metadata slot, works the same way.
What’s Happened Since, and What to Do Next
Coverage since Censys published on August 28 has mostly built on the findings rather than added new ones. A September 4 write-up from Inception Security turned the report into hunting queries for Splunk, Kibana, Microsoft’s KQL, and CrowdStrike’s Falcon platform, while noting that “coverage is still thin” across the industry, a sign that most security teams have not yet built detection specifically for this technique.
Censys’ own guidance is narrow: flag any file that identifies as MP4 but fails to decode, or one that carries nearly all its data inside a uuid box rather than standard video content. My take is that advice understates how many organizations are exposed. Any security stack still leaning on extension or header checks for file-type validation, rather than an actual decode or a sandboxed render, carries the same blind spot this campaign exploited. Security teams should test their content-disarm and file-inspection tools against a deliberately broken container, not just a malicious one.
No victim in this campaign was fooled by a convincing video, because none of them ever saw one play. They were fooled by a security stack that approved a file it never actually tested. Until that changes industry-wide, a fake MP4 will keep working exactly as well as a real one is supposed to.
