One Trojan Sample Shows Full Evasion Playbook, No Campaign in Sight

A Single Trojan Sample Reveals a Full Anti-Analysis Playbook, But No Campaign to Attach It To

A Win32 executable currently flagged by 61 of 76 antivirus engines packs a textbook sandbox-evasion triad — checking for an attached debugger, reading the CPU clock directly, and inspecting the CPU model string — into a single unsigned dropper that has circulated under at least four unrelated decoy filenames since 2016. What makes the sample newsworthy is not a hosting cluster or a signing certificate; there is neither. It is the unusually complete operational-technique chain running end to end on one indicator — user-triggered execution, evasion, persistence, host discovery — with nothing beside it to anchor a broader campaign narrative.

The file (4d651f1030ec2c17…) surfaces in VirusTotal under the threat label trojan.python/fkuk, tracked internally as part of a family called "stitch," and it is worth being upfront about what that pairing does and doesn't tell us. The label and the tracked family name both gesture toward Python-sourced tooling compiled down into a native PE32 — a pattern seen across several public RAT families that started life as Python scripts before being wrapped for Windows distribution. But no reference reporting or MITRE description in this record corroborates a specific lineage, so that reading belongs in the hedged-inference column, not the confirmed-family one. What can be stated as fact is the detection profile itself: 61 of 76 engines flag the binary, including ESET-NOD32, Kaspersky, BitDefender, CrowdStrike, and Google's detection engine, while a group of 14 engines — among them Acronis, ClamAV, Jiangmin, and TACHYON — still return nothing. Community sentiment tracks the same split, with eight malicious votes and zero harmless ones recorded against it.

From Decoy File to Sandbox Kill Switch: Walking the Chain

The earliest visible link in this sample's life is not a delivery mechanism observed directly but an inference drawn from how the file has been renamed. The same sha256 has been submitted 85 times from 66 unique sources, and its recorded alternate names span wildly different social-engineering registers: a spreadsheet-tutorial lure ("In-Session Advanced Formulas and Functions.exe"), a personal-name lure ("Hamid Baroudi - City No Mad.exe"), a French-accented filename, and a generic Arabic-transliterated name ("tawdif.exe"), sitting alongside its own internal path reference of C:\boots\syswin.exe. That spread is not itself proof of a delivery vector — no email, no download URL, no exploit chain appears in this record — but the variance across languages and pretexts is consistent with a file distributed opportunistically under whatever decoy title suited a given target population, which maps to user-executed malicious file delivery [T1204.002]. That the count runs to dozens of submissions from dozens of independent sources over roughly a decade suggests durability rather than a single burst campaign; a file this repackaged has clearly found repeat utility for whoever keeps redistributing it.

Once a victim runs the disguised executable, the sample does not fire immediately. It is tagged as waiting for user interaction before running, a gate that buys the operator two things: it filters out automated detonation in sandboxes that don't simulate real user behaviour, and it delays the moment of compromise until the target has plausibly convinced themselves the file is legitimate — a spreadsheet macro helper, a résumé, a personal document. That gating choice costs the operator reliability; some fraction of targets will simply never trigger the payload if they don't interact with it the way the malware expects. The build itself shows why the operator was willing to accept that trade: the binary is packed with F-PROT, carries a .rsrc section bloated to 3,007,488 bytes against a modest 8,704-byte .text section, and — most tellingly — appended data past the executable's own end-of-file boundary, a classic overlay pattern for stashing a secondary payload or configuration blob outside the PE's normal structure. Combined with an anomalous PE compile timestamp of 2008-11-10, eight years before the file's earliest submission in this record, the picture that emerges is either a reused build environment whose clock was never corrected, or a stolen/carried-over compilation timestamp baked into a toolchain that has been reused across builds for a long time. This dataset offers no peer sample to settle which explanation is correct, so both stay on the table as inference rather than fact — but either reading argues against a rushed, single-use build, and toward a tool with some institutional continuity behind it.

The sandbox-evasion layer is where this sample's evidence is strongest, because it is one of the few places static tagging and dynamic verdict line up. The file checks whether a debugger is attached, reads the CPU timer directly to detect analysis, and inspects the CPU model string — three distinct fingerprinting techniques for detecting virtualized or instrumented execution environments, all present in the same binary [T1497]. Crucially, this evasion instrumentation did not prevent detonation: two independent sandboxes, Dr.Web vxCube and Lastline, both returned a malicious classification against this file, a 2/2 consensus that means the evasive behaviour was actually observed running, not merely inferred from a static tag list. That is a meaningful distinction for a defender to sit with — an anti-analysis check that fails to stop dynamic classification is a check that bought the operator less than it looks like on paper. From inside a monitored endpoint, the sequence would likely have registered as a brief pause after launch — the interaction wait — followed by CPU-timing queries and debugger-presence checks that, on a real machine, return "clean" and simply let execution proceed; on an automated analysis box lacking those signals, the same checks are what should trip the alarm, and here, evidently, they did.

Having cleared its own evasion gate, the sample moves to entrench itself. It is tagged as installing itself to survive reboot, and in the same breath, as deleting itself after running — a dropper pattern where the artifact a victim or a defender might have captured at the moment of infection is deliberately erased, while whatever it installed persists across restarts [T1547]. This is a cost-benefit decision worth naming plainly: self-deletion buys the operator forensic cleanliness, denying incident responders the original launcher to analyse after the fact, but it also means that anyone investigating this infection after the initial moment is working from the installed secondary artifact rather than the file that actually landed — a real complication for reconstruction, and a likely explanation for why this indicator sits so isolated in available telemetry despite years of resubmission. The chain's final documented step is host discovery: the sample calls Windows Management Instrumentation and loads additional modules at runtime [T1047], a combination that reads as environment enumeration gating further module delivery, rather than a monolithic, all-in-one payload dropped in a single shot. None of those follow-on modules appear in this record — what WMI queries return, and what modules get pulled in response, remains outside what this indicator alone can show — but the staging logic itself, discovery before expansion, is consistent with a deliberate operational choice to keep the initial artifact lean and modular.

Two named rule matches close the observable loop on this binary without adding much texture. A YARA rule called Windows_API_Function fires on the sample, a broad signature that its own author notes is not inherently indicative of malicious behaviour on its own — it flags the presence of Windows API functionality commonly found in embedded executables, which is consistent with this file's layered, overlay-bearing construction rather than diagnostic of intent by itself. One medium-severity Sigma detection also matches. Neither rule is specific enough to tie this sample to a named toolkit or a peer cluster, which is itself a data point: a decade-old, widely resubmitted file with a strong detection ratio has still not accumulated the kind of tightly-scoped rule coverage that usually develops around a well-studied campaign, suggesting analysts have treated it as a generic trojan rather than as the anchor of a tracked operation.

Why This Indicator Stands Alone

The single most consequential fact about this record is not anything the file does — it's what surrounds it, or rather, what doesn't. There are no IP addresses, no domains, and no URLs anywhere in this catalog; the entire indicator set is this one file. That absence rules out any infrastructure framing outright: there is no certificate to trace, no autonomous system to map, no registrar pattern to compare against a hosting fabric, because none of those indicator types exist in this record at all. The binary itself carries no code-signing certificate — signature validation simply isn't present to evaluate — which forecloses a supply-chain-abuse reading too; whatever trust this file earns with a victim, it earns through its decoy filename and nothing else, since there is no signer identity for a target to (mis)trust.

That isolation extends to the file's own technical fingerprints. Its import-table hash (7af2fe87a3ab930007d141d21c36ceda) and its structural hash (046046655d156az2anz2az2f1z) match no other sample in this catalog, and the underlying evidence pack scores this record's overall confidence as low — a rationale built on a single indicator with no shared signer, no shared import table, and no shared classification against any peer. That's a genuinely useful signal in its own right: a file this heavily resubmitted, with a detection ratio this strong, would ordinarily be expected to sit inside a recognizable cohort of related builds if it were part of an actively-tracked campaign infrastructure. Its complete isolation instead points toward one of two possibilities — either this is a long-running, low-volume tool that has simply never been cross-referenced against sibling builds in available telemetry, or its builder varies its output enough from run to run that no shared fingerprint has yet been captured. The data here can't distinguish between those two readings, and pretending otherwise would overstate what a single artifact can support.

An Attribution Tag Without a Trail

The underlying feed attaches this file to an actor named HolyWater, also referenced under the alias Storm Cloud, with a listed motivation set spanning espionage and financial gain. That pairing is unusual enough to flag on its own — espionage and financially-motivated crime rarely sit inside the same operator's stated intent — but there is no region, no infrastructure, and no second corroborating indicator in this record to substantiate the linkage beyond the tag itself. Treated honestly, this reads as a low-confidence label rather than a demonstrated attribution, and the safest interpretation is that either the tasking genuinely spans both goals or the classification is an artifact of how the sample was originally catalogued upstream. No public reporting in the material available here fills in that gap, so it stays unresolved rather than guessed at.

What a Strong Detection Score Can't Tell You

The temptation with a file like this is to read a 61-of-76 detection ratio and a clean 2/2 malicious sandbox consensus as evidence of a well-understood, high-confidence threat — and on the narrow question of "is this file malicious," that reading holds. But detection strength and campaign confidence are different axes, and this record is a clean illustration of the gap between them. The evidence pack behind this indicator scores overall confidence low, built on the fact that a single file with no signer, no shared import hash, and no infrastructure to correlate against simply cannot support conclusions beyond its own behaviour. What this sample demonstrates clearly is a complete, self-contained anti-analysis and persistence design: gated execution, a fingerprinting triad that dynamic sandboxes still caught, reboot survival paired with launcher self-deletion, and WMI-based discovery ahead of further module loading. What it cannot yet demonstrate is who is running it, how many other builds share its lineage, or what those additional runtime-loaded modules actually do once discovery clears. For a threat-hunting team, the actionable takeaway isn't a signature to deploy — it's a reminder that lure-filename diversity and reboot-persistence-with-self-deletion, seen together on an otherwise unremarkable unsigned trojan, are worth flagging for correlation the moment a second, related sample turns up. Until then, this is a tradecraft data point sitting on one artifact, not yet a campaign, and the honest version of that story is more useful to a working analyst than an inflated one would be.