A Documented APT28 Exploit Document, Six Months After Disclosure

At a glance

Dekeneas classified this document as malicious at maximum risk, identifying the exploitation mechanism from the file's structure alone.

The sample is not obscure. It belongs to a campaign publicly reported and attributed to APT28, and it had been analysed on VirusTotal months before the scan shown here. Despite this, a significant group of engines — including CrowdStrike Falcon, SentinelOne (Static ML), Malwarebytes, Acronis (Static ML) and Sangfor Engine Zero — returned Undetected.

Background

CVE-2026-21509 is a Microsoft Office security feature bypass disclosed in early 2026. According to public reporting by Zscaler ThreatLabz, it was weaponised within days of disclosure in a campaign attributed to APT28, targeting organisations in Ukraine, Slovakia and Romania. Exploitation requires no macros and no user interaction beyond opening the document.

CVE-2026-21514 is a related Word security feature bypass — a reliance on untrusted inputs in a security decision (CWE-807) — which defeats OLE and Mark-of-the-Web protections. It was patched among six actively exploited zero-days in the February 2026 Patch Tuesday and added to the CISA Known Exploited Vulnerabilities catalogue.

VirusTotal associates this sample with both.

Attribution above is reported by third parties and reproduced here as context. Dekeneas does not perform actor attribution and makes no attribution claim of its own.

What the engine reported

Dekeneas identified the document as an RTF container carrying non-macro active content, and reconstructed the exploitation approach from structural evidence:

• 199 instances of DDE-related terms, indicating Dynamic Data Exchange as an execution mechanism.
• Embedded suspicious extensions and OLE native streams within the RTF body.
• Confirmation that the document is RTF without VBA macros, establishing that execution must occur through a non-macro vector.

The analyst note draws these together into a reconstruction of the exploitation approach:

Despite the absence of VBA macros, the presence of DDE and suspicious embedded active content strongly suggests exploitation tactics for executing malicious payloads.

This is inference, not enumeration. The absence of macros is a negative finding; the presence of DDE terms and OLE native streams is a positive one; the conclusion that execution must therefore proceed through a non-macro vector is reasoning that connects them. An analyst reading the raw structure would perform the same step.

The note then converts the assessment into triage actions: isolate and block the file, perform dynamic analysis in a controlled environment, extract the embedded OLE objects with rtfobj, update detection coverage for similar DDE-based exploit documents, and brief users on the risk of enabling DDE content.

The rtfobj recommendation is worth noting specifically. It is the correct tool for recovering embedded objects from an RTF body, and it is the technique used in independent published analysis of this same campaign. A team without a document-exploit specialist receives the right next step rather than having to know it already.

Why this file is hard to classify statically

RTF is an unusually difficult format for static analysis, and this sample illustrates why.

Embedded objects in RTF are stored as hexadecimal data under control words such as \object and \objdata. They are not valid OLE structures on disk. They become real objects only when Word parses the document and reconstructs them in memory.

The practical consequence is that container-level tooling has nothing structured to inspect. An analyser operating on OLE storage sees no OLE storage, because none exists until the application builds it. An engine can only evaluate the embedded content if it replicates enough of Word's parsing behaviour to recover it, or if it recognises the raw stream patterns directly.

Reaching a maximum-risk verdict on this file therefore requires operating at the correct structural level rather than at the level of the declared container.

What this case demonstrates

Detection headcount is not a measure of analytical capability. Thirty-nine engines flagged this file — but this sample has been a published indicator for months, and its hash is carried in commercial feeds. A signature match on a known hash demonstrates feed coverage, not analysis.

Dekeneas maintains no signature set, no hash lists and no malware family database. The verdict here was computed from the document's structure, exactly as it would have been on the day the campaign began, before any signature existed anywhere. That property is what the case study is about.

The engines that missed it were performing analysis, and it did not succeed. The undetected list includes several vendors whose static machine-learning models are widely regarded. These are not coverage gaps caused by a novel sample — the file had been publicly available and documented for months.

The reasoning is inspectable. The verdict cites a countable quantity (199 DDE-related terms), a structural observation (OLE native streams in an RTF body), and a negative finding (no macros present, so execution must be non-macro). An analyst can verify each of these independently.

Verify this yourself

The hash above is public. The Dekeneas free tier includes malware analysis at no cost, so the result in this case study can be reproduced directly, and the engine can be tested against documents where the ground truth is already known.

What this case does not show

This is one sample. It demonstrates that a signature-less engine reached the correct verdict on a document that several significant static engines did not flag. It is not a detection rate, and we do not present it as one.

The comparison is also specific in scope. VirusTotal runs static analysis configurations, so what is being compared here is static analysis against static analysis. That is the appropriate comparison, since Dekeneas is performing static analysis too, and we make no claim about how these vendors' full products behave at runtime — we have not tested them and have no basis for an opinion either way.

What the scope does not permit is treating runtime detection as a substitute. CVE-2026-21509 triggers on document open. Identifying the file beforehand and identifying process behaviour afterwards are not equivalent outcomes, and a static engine that fails to classify the document has failed at the task it was given.