APT28: Geofencing as a Targeting Signal (CVE-2026-21509 Campaign)

by Robin Dost


EDIT: 04.02.2026:
I have YARA Rules available for detection, contact me at contact@robin-dost.de if you need them.

After publishing this article, I received technical feedback regarding the root cause of CVE-2026-21509. Based on that input, I corrected several parts of the analysis.

Update Notes:
The vulnerability does not rely on malformed OLE objects, and WebDAV is not part of the exploit primitive. CVE-2026-21509 is caused by an allowlist gap around Shell.Explorer.1, which Office still instantiates. WebDAV is only used as a delivery mechanism.
The article has been updated accordingly.


Since the beginning of this year, we have again observed an increased number of attacks by APT28 targeting various European countries. In multiple campaigns, the group actively leverages the Microsoft Office vulnerability CVE-2026-21509 as an initial access vector.

This article focuses on how CVE-2026-21509 is used in practice, how relevant IOCs can be extracted efficiently from weaponized Word documents and how the actors own geofencing can be leveraged to infer operational target regions.

Before diving into the analysis, a brief look at CVE-2026-21509 itself.

Understanding CVE-2026-21509 (Click)

CVE-2026-21509 comes down to a simple allowlist gap in Office.

Microsoft has been blocking browser OLE objects like Shell.Explorer and Shell.Explorer.2 for years. Shell.Explorer.1 just never made it onto that list.
Attackers embed a Shell.Explorer.1 OLE object inside an RTF document.
When Word parses the file, the object gets reconstructed and instantiated normally, because from Offices point of view it is still considered allowed.
No macros. No scripts. No fancy exploit chain.
Just a forgotten COM class.
Once loaded, the embedded browser object calls Navigate() and points to a remote resource, usually a .lnk file, which then becomes the actual execution vector.
The document itself carries no payload.
Its only purpose is to reach a state where Shell.Explorer.1 is active and allowed to fetch external content.
Variations of this technique have been public since at least 2016-2018.
CVE-2026-21509 merely formalizes Microsoft finally acknowledging that this specific ProgID should probably have been blocked a long time ago.

tldr;

APT28 abuses CVE-2026-21509 by embedding a forgotten OLE browser object (Shell.Explorer.1) into RTF documents.
Office happily instantiates it, the object navigates to a remote .lnk, and thats your execution path.
An allowlist gap that somehow survived for years.
The documents themselves contain no payload.
They only exist to get Office into a state where external shortcut files can be fetched. From there, the real infection chain starts.

Analyzed Samples

For this analysis, I looked at the following samples:

HashDownload
c91183175ce77360006f964841eb4048cf37cb82103f2573e262927be4c7607fDownload
5a17cfaea0cc3a82242fdd11b53140c0b56256d769b07c33757d61e0a0a6ec02Download
b2ba51b4491da8604ff9410d6e004971e3cd9a321390d0258e294ac42010b546Download
fd3f13db41cd5b442fa26ba8bc0e9703ed243b3516374e3ef89be71cbf07436bDownload
969d2776df0674a1cca0f74c2fccbc43802b4f2b62ecccecc26ed538e9565eaeDownload

When I receive potentially malicious Word documents, my first step is usually to run oleid. In most common malicious documents, this already reveals macros, external references or other active content.

In this case, oleid reports a clean file. No macros, no external relationships, no obvious indicators.

This is expected.

The document is not a classic OLE container but an RTF file. In RTF, embedded objects are stored as hexadecimal data inside the document body using control words such as \object and \objdata. These objects do not exist as real OLE structures until Word parses the document and reconstructs them in memory.

oleid operates at the container level. It can only detect features that already exist as structured objects in the file. Since the embedded OLE data is still plain text at this stage, there is nothing for oleid to flag.

The exploit surface of CVE-2026-21509 only becomes visible after this reconstruction step. Tools like rtfobj replicate this part of WordS parsing logic by extracting and rebuilding the embedded objects from the RTF stream.

rtfobj -s all b2ba51b4491da8604ff9410d6e004971e3cd9a321390d0258e294ac42010b546.doc

Once reconstructed, the embedded objects resolve to Shell.Explorer.1. Some tools flag the CLSID as unknown, but Windows loads it normally. The containers themselves are valid OLE objects. The vulnerability is triggered solely because this specific ProgID is still allowed.


After extracting the embedded objects, I inspected the resulting files using xxd. At this stage, strings did not yield anything particularly useful, which is not surprising given that the document is not designed to carry a readable payload.

From this data, the following strings could be extracted:


file://wellnessmedcare.org/davwwwroot/pol/Downloads/document.LnK?init=1
file://wellnessmedcare.org/buch/pol/Downloads/document.LnK?init=1
file://wellnessmedcare.org@ssl/cz/Downloads/document.LnK?init=1
file://freefoodaid.com@80/documents/2_2.lNk?init=1


Why file://…/davwwwroot/…lnk appears in these samples

Some in-the-wild samples use paths like:

file://wellnessmedcare.org/davwwwroot/pol/Downloads/document.lnk

This is more an operational choice, then a technical requirement of CVE-2026-21509.
The same behavior can be triggered using plain HTTP or HTTPS URLs.
The exploit primitive is simple: the embedded Shell.Explorer.1 object calls Navigate() to a remote URI.
What happens next is handled by the legacy Internet Explorer engine (ieframe.dll), which does not implement modern protections such as SmartScreen or Smart Application Control.
WebDAV mainly provides delivery convenience.
It exposes remote files as filesystem-like objects via the Windows WebClient service, but it does not change the exploit mechanics.
As already mentioned, the Word document itself contains no payload and performs no execution.
Its only purpose is to instantiate Shell.Explorer.1 and trigger navigation to a remote shortcut file.
The .lnk becomes the actual execution vector. When accessed, the user is prompted to open or save the file, and any follow-on activity happens outside the document.
The query parameter is client-side only and used to avoid caching. It has no functional relevance for the server.

Identifying Targets

While analyzing the documents and extracted URLs, it became apparent that they reference potential target regions:

  • /cz/ -> Czech Republic
  • /buch/ -> Bucharest / Romania
  • /pol/ -> Poland

Additional indicators inside the Word documents further support this assessment:

  • Romanian language content
  • References to Ukraine
  • Mentions of Slovenia
  • EU-related context

None of this is accidental.

At this point, the next step is validation. Russian threat actors are known to rely heavily on geofencing and APT28 is no exception. Fortunately, this behavior can be turned into a useful source of intelligence for us ^-^

Turning Geofencing into Intelligence

The first step was to take a closer look at the domains extracted from the samples:

wellnessmedcare.org193.187.148.169
freefoodaid.com159.253.120.2

What stands out here is the choice of hosting locations.
Both IP addresses resolve to providers in Romania and Moldova. It is reasonable to assume that these locations were selected based on the campaigns intended target regions.

Next, I attempted to replicate the WebDAV requests generated by Windows in order to test the observed geofencing behavior.
To do this, I executed the document in a sandbox and captured the resulting network traffic.

Geofence Analysis

To validate the geofencing, I needed to determine which proxy locations were required to access the malicious resources without being blocked.
After identifying suitable proxies, I performed test requests using a custom script, once without a proxy and once using a Romanian proxy.

Without proxy:

With proxy:

The result is fairly clear. Requests originating from outside the expected regions are rejected with HTTP 403, while requests routed through a Romanian proxy succeed. This pattern can be used to validate likely operational target regions.

Out of 114 tested countries, only three were allowed access: Czech Republic, Poland and Romania. This aligns perfectly with the indicators observed earlier in the documents and URLs.

As this example shows, defensive measures such as geofencing can provide valuable intelligence when analyzed properly. Even access control mechanisms can leak information about an actors operational focus if you know where to look.
The second domain, freefoodaid.com, was already offline at the time of analysis. Given how short-lived APT28 infrastructure tends to be, this is hardly surprising. It is reasonable to assume that similar geofencing behavior would have been observable there as well, but for demonstration purposes, the remaining data is more than sufficient.

How to protect against these attacks

Update Microsoft Office and enforce a structured update routine.
Treat unexpected Word documents as untrusted and have them analyzed before opening them.
(or stop using windows :3)

Conclusion

CVE-2026-21509 works because it fits neatly into how Office processes documents today.
The exploit relies on Office instantiating an allowed OLE object during normal parsing, not on macros or embedded payloads, which makes it easy to overlook during initial analysis.
The tradecraft follows a familiar pattern.
Remote shortcut files and strict geofencing have been used by APT28 before and continue to show up in current campaigns.
WebDAV appears here mainly as a delivery detail.
The technique is stable, requires little user interaction, and sidesteps many modern Office protections by falling back to legacy browser behavior.
At the same time, this setup exposes useful signals.
Geofencing decisions, hosting locations and access behavior provide insight into intended target regions when tested systematically.

In this case, the infrastructure behavior aligns closely with the indicators found inside the documents.
From an analytical POV, the value lies less in the exploit itself and more in what can be inferred from how it is deployed and constrained.

Upload Response

Your data will be stored in the mainframe. Required fields are marked *