
A Political Decoy Document Reopens a 2016 Word-Processor Flaw
A Korean-language decoy document is still triggering a nine-year-old Hangul Word Processor exploit (CVE-2016-2569) to drop a loader first compiled in 2017. VirusTotal submission history shows the same payload lineage still circulating as recently as December 2025.
A Political Decoy Document Reopens a 2016 Word-Processor Flaw
A Korean-language document about inter-Korean political affairs is still being used to trigger a nine-year-old Hangul Word Processor flaw, and the payload it drops is evading a meaningful share of security engines nearly a decade after it was first compiled. The lure — a corrupted HWP container (29430240cb59a12fcde8e4153c0859c90d5a928503a1ca05433f08a7b3c50bf2) carrying an internal object path that resolves to a temp file named for a comparison of "2016 and 2017 South Korea-facing affairs" — pairs with a Windows executable explicitly tagged for CVE-2016-2569, the long-known HWP/EPS exploit chain that this activity cluster has leaned on for years. What makes the pairing newsworthy in 2025 is not the exploit's age but its persistence: VirusTotal submission history for the paired payload spans from January 2017 through December 2025, ten submissions from eight distinct sources, meaning either the original sample or close variants of it are still circulating in the wild.
The HWP file itself is nearly invisible to detection — zero of 58 scanning engines flag it, and it carries no signature or import data of its own. That is not surprising: HWP droppers built around this exploit chain are designed to look like ordinary documents until the embedded object stream executes, and a corrupted CDF/HWP header (the dossier records it flatly as "corrupt: Cannot read summary info") is consistent with a file that has been deliberately truncated or repackaged around a malicious payload rather than authored normally [T1203]. This stage is the weakest-evidenced link in the chain — there is no sandbox detonation of the HWP file itself in this record, and the exploit-execution mechanics have to be inferred from the paired executable's own CVE tag rather than observed directly. That gap matters for anyone trying to reconstruct the intrusion with confidence: the lure's role is plausible and consistent with known Group123/ScarCruft tradecraft, but it is not, on this evidence alone, proven.
From Document to Payload: A Loader Built to Stall, Check, and Hide
Once the embedded object fires, a 156-kilobyte Win32 executable (7ebc9a1fd93525fc42277efbccecf5a0470a0affbc4cf6c3934933c4c1959eb1) is dropped under names that reference the very document that carried it — the dossier lists alternate names including "Hwp (3).exe" and "mz_decom_BIN0004.exe" — before it loads additional modules at runtime [T1055]. That naming choice is itself a small piece of tradecraft: an analyst glancing at a process list sees a file named after the decoy document rather than a generic dropper, buying the operator a few extra seconds of plausibility inside a target's endpoint telemetry. From here the loader is reported to install itself so it survives a reboot [T1547.001], though — as with the initial exploit — the specific persistence artifact (registry key, scheduled task, or service) isn't captured in this record and the claim should be read as a behavioural inference from the underlying tag rather than a directly observed autostart entry.
What is directly observed, and observed richly, is the evasion layer. The executable stalls for long periods before executing, checks whether a debugger is attached, and reads the CPU timer directly to detect whether it is running inside an analysis environment [T1497.003] — three separate anti-analysis techniques stacked on top of one another rather than a single check. That stacking produced a split verdict rather than a clean one: of three sandboxes that detonated the sample, Zenbox and Lastline both call it malicious, with Zenbox specifically classifying it as an evader, while a third sandbox, C2AE, returns no verdict at all. That divergence is the tell. A single anti-analysis trick is a speed bump; three layered together are enough to make one automated detonation engine simply give up and report nothing — which is exactly the outcome an operator wants from a sandbox farm that automatically triages incoming samples before a human analyst ever looks at them. From inside a defender's SOC, that split reads less like "the file is safe" and more like "our tooling disagreed with itself," which is often the first sign that something is engineered specifically to survive automated triage rather than a human reviewer.
The build artefact underneath that behaviour supports the evasion reading rather than undercutting it. The executable's resource section carries entropy of 7.86 — high enough to indicate packed or encrypted content sitting inside what would otherwise be a normal PE resource segment — against a comparatively low 2.07 in its data section, a contrast that is consistent with a loader that keeps its working code in cleartext while hiding a payload or configuration blob inside a densely packed resource. Neither file in this set carries a code-signing certificate; both are recorded simply as unsigned, which removes one common evasion path (a stolen or fraudulently obtained signing certificate) from the picture entirely — this operator relied on behavioural evasion and low-noise delivery rather than signed-binary trust abuse to get past defenses.
Detection Says 64 of 77 — But Naming Conventions Still Disagree
The loader is not stealthy in the aggregate detection sense: 64 of 77 engines flag it, a strong majority, and the community vote split (two malicious, zero harmless) reinforces that consensus. But detection volume and detection agreement are different things, and here they diverge in a way worth noting. VirusTotal's own label for the sample reads trojan.midie/evnyca, with popular names midie, evnyca, and adrpt attached — none of which map cleanly onto the "dogcall" family name attached to this activity cluster in threat-tracking records, and none of which invoke ROKRAT by name either. Yet the sample also trips a YARA rule named ROKRAT_Nov17_1, drawn from a public ruleset (apt_rokrat) authored by Florian Roth of Nextron Systems and explicitly built to detect ROKRAT malware. Eight years after that rule was written, and eight years after this sample first appeared, engine-level naming still hasn't converged on a single label for what the community-authored detection logic recognizes as the same lineage. That gap between signature-based recognition and naming-convention consensus is itself a small, concrete signal about how fragmented multi-vendor detection remains for an established, well-studied toolset — it is not that the malware is unknown, it is that the industry's naming layer has never fully caught up with what its own detection rules already know.
The rule overlap runs further than YARA alone. The same sample fires the Snort signature "MALWARE-CNC Win.Trojan.Malear variant outbound connection" — and fires it twice, a repeated hit rather than a one-off — while separately carrying a tag indicating outbound traffic routed via Tor [T1071.002]. Layered together, three different evidence types — a YARA rule built specifically for ROKRAT, a network-layer IDS signature naming an unrelated "Malear" trojan family, and a raw behavioural tag for anonymized egress — describe a single sample that behaves like a backdoor capable of reaching out through more than one covert channel, even though no two of those three signals individually would justify that conclusion on their own. This is the kind of cross-evidence judgment that a bare detection ratio can't produce: 64/77 tells you engines think it's bad; the rule stack tells you specifically what kind of bad, and that the sample's command-and-control behaviour was deliberately built to blend into ordinary encrypted or anonymized traffic rather than beacon in the clear. Thirteen engines still miss it outright — the missing set includes consumer and mobile-focused products rather than enterprise EDR names, which is a modest but real reminder that "64 of 77" does not mean universal coverage across every deployment context a target organisation might run.
A Korea Telecom Host With a Century-Long Certificate — and No Link Back to the Payload
The only infrastructure indicator in this record is a single IP address, 222.122.86.253, sitting on Korea Telecom's network under AS 4766, in the 222.122.80.0/20 block. Zero of 89 engines flag it as malicious, and nothing in the record — no shared certificate serial, no shared A-record, no domain layer at all — directly ties this address to the loader's outbound traffic. That absence is itself informative: running C2 or staging infrastructure as a bare IP with no fronting domain removes an entire tier of the infrastructure trail that defenders normally pivot on, and it means anyone trying to track this cluster by registrar or DNS history has nothing to work with here.
What does distinguish the host is the TLS certificate it serves. It is self-signed, and both the issuer and subject fields read identically — "My Company Ltd," registered to an address in Newbury, Berkshire, under the country code for the United Kingdom — a boilerplate, non-CA-issued identity with no relationship to the Korean network it actually sits on. The certificate's validity window runs from April 2017 to March 2117: a century of nominal validity, which is not something any legitimate production TLS deployment does, since real certificate authorities cap lifetimes at a few years precisely to force periodic re-issuance and revocation checks. A hundred-year self-signed certificate on a host with no other distinguishing infrastructure is the kind of boilerplate default that shows up when an operator spins up a TLS listener quickly and never bothers to replace the placeholder identity — a pattern more typical of a staging or C2-capable box than a production service someone actually maintains.
That reading, however, has to be held as a lead rather than a conclusion. The cross-indicator linkage that would confirm this IP as this loader's actual command channel — a shared certificate serial, a shared hosting fingerprint, any campaign-level cohesion signal — simply isn't present in this record; the address stands alone on its ASN with no cohort tying it to the file cohort's traffic. Braiding the Snort "Malear" C2 signature and the Tor-egress tag from the loader with this KR-hosted self-signed host produces a plausible operational picture — decoy document to loader to covert channel to a boilerplate-certificate box — but the final hop in that picture is inference, not observation, and should be read that way.
Espionage Framing, Held at Arm's Length
Threat-tracking records tie this activity to Group123, an actor also referenced under the aliases APT37, ScarCruft, Reaper, Red Eyes, Ricochet Chollima, and InkySquid, and log its motivation as espionage — a label consistent with the Korean-language, inter-Korean political subject matter used as the lure. One of those aliases, Ricochet Chollima, follows a naming convention some vendors reserve for DPRK-nexus clusters, though that inference rests on the alias string alone; nothing in this record independently confirms state sponsorship through infrastructure, victim targeting, or an explicit attribution statement. The record's own geographic and industry tags point toward administrative or support-function entities rather than a specific targeted vertical, but that likely reflects where samples were submitted for scanning rather than confirmed victim identity, so it is best read as a weak signal rather than a targeting profile.
What a Decade of Reuse Signals About This Cluster's Priorities
The throughline across every section of this record is reuse, not reinvention. A 2016-vintage exploit still opens the door; a 2017-compiled loader is still being submitted for scanning as recently as December 2025; a community YARA rule written in November 2017 still fires cleanly on the payload; and the operator has apparently felt no pressure to swap the anti-analysis stack, the delivery mechanism, or even the file naming convention in the intervening years. That is not the profile of a group racing to stay ahead of detection engineering — it is the profile of a group that has calculated, correctly so far, that aging tradecraft still clears enough of the field to be worth the low cost of reuse. Sixty-four of 77 engines flagging the payload sounds like a defeat for the operator; in practice, thirteen engines still miss it, and the sample's own layered stalling and debugger checks are enough to make at least one automated sandbox return nothing at all — which is the only outcome that matters at the moment a security team's automated triage pipeline decides whether a file gets escalated to a human analyst or quietly closed out.
The absence of any corroborated infrastructure trail beyond a single, isolated, self-signed-certificate host is also a signal in its own right, even if a modest one. It suggests either that this cluster's actual staging and C2 fabric sits outside what any single scanning platform captures, or that the operators have kept their network footprint deliberately minimal and disposable — a bare IP with a placeholder certificate, no domain layer, no registrar history to mine. Either reading points toward an actor prioritizing operational durability over infrastructure sophistication: reuse a working exploit chain, reuse a working loader, keep the network footprint thin enough that there's little for a defender to pivot on even after the payload itself is caught. For organisations whose work touches Korean political or diplomatic subject matter, the practical takeaway from this record is less about a single indicator to block and more about what the reuse pattern implies: a decade-old delivery chain evidently still clears enough defenses, often enough, that its operators have had no reason to retire it.