Fake Skype Installer Ran a Full Espionage Chain for a Decade

A Skype-Branded Trojan That Never Bothered With a Signature

A Win32 executable that calls itself Skype.exe, carries Skype's product name and a "© 2003-2012 Skype and/or Microsoft" copyright string, and still ships completely unsigned has been circulating in low volumes for more than a decade — first submitted for scanning in October 2014, most recently as March 2025. The file (b6ca1211…8f518a403) is flagged by 61 of 78 engines, a strong consensus that has held steady across its long life. What makes it worth a closer look isn't scale — this is a single artifact, not a sprawling infrastructure set — but the completeness of the tradecraft packed into it: a masquerading lure, layered anti-analysis checks, reboot persistence, host discovery, and a beacon to a since-defunct domain that trips a named intrusion-detection signature written specifically for this family.

The branding-versus-signing mismatch is the entry point. The sample presents itself internally and externally as Skype — meaningful name, internal name, and product string all read "Skype," with a plausible-looking copyright line attached — while carrying no valid code-signing certificate at all. That combination is the signature of a trojanized fake installer [T1036]: a file built to look, at a glance, like the real thing, betting that the visual cue of a familiar brand does more work than an actual certificate would. A genuine Skype installer from Microsoft would be expected to carry a verifiable signature; this one substitutes branding for that trust chain entirely, and the absence is not incidental — it is the whole mechanism. The cost of that choice is that any signature-based or publisher-allowlist control catches it instantly, which likely explains why detection has stayed consistently high across its lifetime rather than degrading the way heavily obfuscated loaders sometimes do.

Stalling the Sandbox Before Doing Anything Interesting

Once a Skype-branded executable is run on a host, the sample doesn't act immediately. Behavioural tagging shows it stalls for long periods before executing, checks whether a debugger is attached, and waits for user interaction before proceeding — three distinct anti-analysis gates stacked on top of one another rather than a single evasion trick. The first behaviour maps to time-based virtualization checks [T1497.003], where a sample compares elapsed real time against expected sandbox execution windows to infer whether it's being watched; the second maps to debugger evasion [T1622], in which the malware searches for the artifacts a debugger leaves behind and can choose to disengage rather than reveal its logic under a analyst's step-through. Layering these together buys real protection against automated triage: a sandbox with a short detonation timeout, no simulated user input, and no debugger-detection countermeasures of its own will very plausibly log this sample as benign and move on.

That layering has a cost, though, and it's a cost that shows up on the defender's side of the fence rather than the attacker's. A stalling, debugger-aware binary that also waits for user interaction is betting heavily on getting a live human session — which means it is far more brittle in an environment where execution is automated, headless, or scripted, and it surrenders speed for stealth. From inside a target network, this translates into a detection gap that looks less like "the malware was invisible" and more like "the malware was patient": a SOC running short-lived automated detonation as its first line of defense would see nothing alarming pass through, while a longer-dwell EDR trace or a human analyst who lets the process run past the initial stall would eventually see it act. The behavioural tags describing this sequence come from VirusTotal's community and static tagging rather than a fresh sandbox detonation of this specific submission, so the exact order and thresholds of the stalling and debugger checks should be read as a documented behavioural profile rather than a moment-by-moment trace — the shape of the evasion is well evidenced even if the precise timing values are not.

Rebooting Into Persistence, Then Mapping the Host

Once the sample clears its own gauntlet of stalling and debugger checks, the next tagged behaviour is persistence: it installs itself to survive a reboot, consistent with a Registry run-key or startup-folder mechanism [T1547.001]. This is a deliberately low-friction persistence choice — it doesn't require privilege escalation, kernel access, or a driver, and it survives the most common remediation step an unsophisticated user might take, which is simply restarting the machine. The trade-off is that it's also one of the most heavily hunted persistence patterns in the industry; any endpoint tool doing basic autorun-location auditing has a reasonable chance of surfacing it, which again argues that this sample was built for a target population where advanced detection tooling either wasn't present or wasn't actively tuned to catch it.

With persistence established, the malware moves into discovery: calling WMI and inspecting available disk space [T1012], reconnaissance behaviour that gives an operator a read on the host before deciding whether it's worth further attention. Querying available storage is a mundane-sounding check, but it's a useful signal for an intelligence-collection operator trying to triage which infected machines are worth the operational risk of continued tasking — a machine with negligible free space, or one that looks like a disposable VM, is a poor investment of further C2 traffic. The sequence up to this point — masquerade, stall, evade, persist, then look around — reads as coherent tradecraft aimed at getting a foothold quietly and deciding afterward whether the host is worth keeping, rather than a smash-and-grab payload designed to act the moment it lands.

A Dead-End Beacon With a Name Attached

The chain's final observed stage is a DNS lookup to flushupate.com, and this is where the sample stops being an anonymous piece of malware and becomes something a named detection rule was written for: "ET MALWARE Arid Viper APT DNS Lookup (flushupate.com)," a high-severity signature published through Proofpoint's Emerging Threats Open ruleset, fires directly on this traffic. That's a meaningfully different kind of evidence than a generic heuristic flag — it means a rule-writer had previously seen this exact domain tied to this exact activity cluster and built a durable detection specifically around the hostname. The domain itself carries tags describing it as showing signs of command-and-control traffic while also, in the same breath, no longer resolving to anything at all — a beacon whose destination has already gone dark. Two Sigma rules also fire against the sample independently of the network-layer signature, giving the file a second, host-based line of detection alongside the domain-based one.

Reading those two facts together — a named, actor-specific IDS rule and a domain that's since collapsed — supports an inference rather than a fact: this sample was likely encountered, or built, during a window when flushupate.com was live infrastructure, and what's being caught now, years later, is the tail end of that operation rather than an active command channel. The domain's own detection footprint is thin — 13 of 89 security vendors flag it, a modest ratio that's typical of infrastructure long since abandoned rather than actively monitored malicious hosting. There's no TLS certificate on record and no resolved-IP data behind the domain to work from, which means the C2 stage of this chain has to be read through the DNS check-in behaviour and the named rule alone, without a server-side fingerprint to corroborate it.

Isolation as a Signal, Not a Gap

Both indicators in this record sit alone. The file shares no imphash, no signer, and no threat-label lineage with any peer sample available for comparison, and the domain's registrar — ProtonDomains.com LLC, with name servers under the ZTOMY.COM reseller pool — appears nowhere else in the broader indicator set either. One piece of build provenance does give a forward-correlation hook worth flagging: the binary's compile timestamp reads 2014-05-08, roughly five and a half months before its first appearance on VirusTotal on 2014-10-25, and its import-table hash — 7647cdf4939f… — is the one concrete fingerprint that could, in principle, tie a future sample to this same builder if one ever surfaces. That gap between compilation and first sighting is itself just an observation; it doesn't establish how the file was distributed in the interim, only that a window of that length existed.

The practical reading is straightforward: a single defunct domain and a single unlinked file are too thin a base to support an infrastructure-cluster claim, and this record is better understood as one well-fingerprinted artifact than as evidence of an active, ongoing campaign. The operational sophistication here lives in the chain itself — the masquerading, the stacked anti-analysis checks, the persistence, the discovery step, the named-rule beacon — not in any hosting fabric behind it, because there simply isn't one visible to describe. That distinction matters for how this indicator should be weighted going forward: it's a strong artifact-level detection, not a live infrastructure lead.

Espionage Tradecraft, Loosely Tied to a Familiar Name

The record attaches this sample to Molerats — also tracked under Gaza Cybergang, Extreme Jackal, Aluminum Saratoga, Moonlight, and TA402 — with espionage listed as the motivation, which fits the tradecraft on display: quiet persistence and host reconnaissance rather than any monetisation behaviour like ransomware or a coin-mining payload. That attribution carries only low confidence here, and the popular naming attached to the file itself — "arvid," "desertfalcon," and the named IDS rule's own "Arid Viper" reference — points toward a related but separately tracked naming lineage within the same Gaza-linked espionage ecosystem rather than confirming the two labels describe one operation. The retail-sector and China/Hong Kong tags attached to this indicator should be read as this record's observed metadata rather than a settled targeting pattern; the sample offers no independent victim telemetry to corroborate or expand on that pairing.

The motivation label and the technique stack agree with each other more than the actor name adds anything new: an espionage-oriented operator willing to spend the engineering effort on a three-layer anti-analysis gate, silent persistence, and pre-tasking host discovery is optimizing for staying resident and unnoticed on a machine worth watching, not for immediate payoff. Whether the Molerats attribution and the Arid Viper rule-naming genuinely describe the same infrastructure or simply sit adjacent to each other in an overlapping regional threat ecosystem is a question this single artifact cannot settle on its own.

What a Decade of Reuse Says About This Kind of Tooling

The span between this sample's first VT submission in 2014 and its most recent in March 2025 is the detail that reframes everything else in the chain. A file built with this level of layered evasion and this specific a persistence/discovery/C2 sequence surviving in scattered submissions across roughly a decade suggests either genuinely durable, still-encountered tooling, or a pattern of delayed and duplicate detections against an artifact that stopped being operationally relevant years ago — the data here can't fully distinguish between those two readings, and that ambiguity is itself informative. What it does rule out is a fast-burn, high-volume campaign: five total submissions from four unique sources over more than ten years is the profile of sporadic re-encounter, not active distribution.

What this leaves for defenders and analysts alike is a lesson less about this particular file and more about how espionage-oriented toolkits age. The masquerading-plus-evasion chain documented here didn't need updating to keep tripping detections a decade after it was compiled — signature-based tools still catch the branding mismatch, and the named IDS rule still catches the DNS pattern, because neither the lure nor the beacon domain ever needed to change to remain technically functional as an artifact, even after the underlying campaign itself clearly went cold. That durability, more than any single technique in the chain, is the real signal in this record: low-cost, well-worn tradecraft doesn't have to be fresh to keep resurfacing, and a decade-old sample turning up again in a submission log in 2025 says as much about how long these artifacts linger in the wild as it does about the operator who originally built them.