Key takeaways

  • APT28 phishing campaign using PixyNetLoader is still ongoing
  • PixyNetLoader has been slightly modified since our last blogpost
  • Since september, the persistence mechanism has changed
  • The observed targetting is still the same

Publishing research on an adversary is always a delicate exercise. You can safely assume that they will read what has been written about them, and that everything made public should be considered burned from that point onward. In early June 2026, we published a blog post analyzing APT28's PixyNetLoader code. Since then, the malware has slightly evolved: the July update breaks the YARA rules and the payload extraction script we provided in our first blogpost, and the September one shifts the persistance mechanism.

While the September changes were probably related to detection issues, the COM registry keys being quite unique, the July update targets key points we provided in our first blogpost (string encryption routines targeted by our yara rule and payload encryption technique) and do not appear to be related to detection issues. This update being released shortly after our initial publication, without being a very robust patch, we estimate that it was issued in order to address our findings.

In this blog post, we examine the modifications introduced by the threat actor, highlighting which changes proved effective and which did not. We will also cover the last September updates, and provide detection guidance.

2026 Post June Campaigns

These campaigns appears to be part of an operational pattern that has remained consistent since 2025, primarily targeting Ukrainian military logistics through malicious XLS and DOC documents.

excel decoys
word decoy
word decoy

Document lures displayed to the victim

July updates

Reminder: the PixyNetLoader malware consists in a DLL file, which loads and executes a payload embedded in the PNG companion file, using steganography. Both are dropped by the exploit, which also installs the PixyNetLoader persistance mechanism. In the previous versions, it was registered as a COM handler.

Our first observation on one of these samples (125abe1a497067a61011eb6072b1b3d91d3f0b658ed20a99734f0341d9cbdd6a, dropped in the c:\users\<USER>\appdata\roaming\microsoft\internet explorer\userdata\low\db\uimanager.dll file path) is that every YARA rule we publicly released—or shared with our trusted partners—has now become ineffective. As we anticipated this possibility, we deliberately kept several detection rules private, allowing us to retain detection capabilities despite these modifications.

At first glance, the malware has not been significantly rewritten. A substantial portion of the codebase remains shared with the June 6 version.

Code similarity between the 20260611 version and the 20260720 version

View on Exalyze

As expected, the code responsible for string encryption and has been modified and the password used to derive the AES key is now encrypted.

Password decryption before derivation

View on Exalyze

This modification is quite simple, and we can still identify big similarities with other samples :

matching function

View on Exalyze

The remainder of the execution flow remains essentially unchanged, ultimately loading a CovenantGrunt payload in the C:\Users\<USER>\AppData\Roaming\Microsoft\Network\Cache\icon.png file, that uses the FILEN service as its command-and-control (C2) channel.

September updates

The september strain now uses another persistence mechanism: the dropper will now create the HKCU\Software\Classes\CLSID\{0a556d98-cfee-4d84-82a7-00377f939198} registry key, which will supersede the HKLM handler, which is the Default Associations Profile Handler. This handler is implemented in the legitimate shell32.dll and loaded by explorer.exe. The PixyNetLoader variants will simply export the same functions and forward them to the legitimate shell32.dll. As this handler is only used by explorer.exe, the PixyNetLoader code will check at its startup that the current process is indeed explorer.exe.

Finally, the HIDE magic number is not present anymore, along with other checks.

Otherwise, the most part of the logic remains unchanged : it stills load its .png companion file, extracts the payload using LSB steganography, decrypts then executes it. The payload still being a Covenant Grunt payload using the legitimate FILEN API to communicate.

Detection Guidance

The detection remains relatively straightforward: in addition to the PNG and DLL paths (provided in appendix below), the presence of the HKCU\Software\Classes\CLSID\{0a556d98-cfee-4d84-82a7-00377f939198} registry key is not normal on a sane system. Moreover, even if this registry key existed, its Default value should point to the legitimate shell32.dll.

An earlier sample also used the HKEY_CURRENT_USER\Software\Classes\CLSID\{30d49246-d217-465f-b00b-ac9ddd652eb7}\InProcServer32 as a persistance mechanism (which normally points to the legitimate IDStore.dll system file).

Conclusion

Publishing technical research on a threat actor should always be done with the understanding that every publicly disclosed detection or analysis technique is effectively compromised from that moment onward. Beyond enabling defenders, such publications also give adversaries the opportunity to improve their tooling, evade existing detections, and learn from their previous mistakes.

In this case, however, the modifications introduced by the threat actor were relatively minor and did not appear to significantly disrupt or delay their operational activities.

This also highlights the importance of rapid defender response following the publication of new detection content. Mature threat actors will typically adapt their tooling and tradecraft as quickly as possible to preserve their operational stealth. We have previously observed actors withdrawing from compromised environments as soon as they became aware of an upcoming publication concerning their activities. Although modern EDR solutions with extensive logging capabilities often allow retrospective threat hunting, this is not always sufficient. More discreet threat actors actively work to minimize the forensic artifacts that would enable such investigations.

For this reason, certain portions of our reports are only shared upon request.

Appendix : IOCs

PixyNetLoader DLL file paths

Remark: the PixyNetLoader payload can virtually be installed anywhere on the system. These paths are the ones we identified in the exploits we analyzed.

C:\ProgramData\Microsoft\DeviceSync\DNX\dnxstore.dll
C:\Users\<USER>\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\PSReadLineCore.dll
c:\users\<USER>\appdata\roaming\microsoft\internet explorer\userdata\low\db\uimanager.dll

PixyNetLoader PNG companion file paths

C:\Users\<USER>\AppData\Roaming\Microsoft\Network\Cache\icon.png
C:\ProgramData\Microsoft\DeviceSync\Edge\wallpaper.png

Registry COM handlers used as persistance

Remark: these registry paths should not be set in users' Classes registry keys. However, their Default value should be checked against legitimate ones, in order to avoid false positives.

HKEY_CURRENT_USER\Software\Classes\CLSID\{30d49246-d217-465f-b00b-ac9ddd652eb7}\InProcServer32 
HKEY_CURRENT_USER\Software\Classes\CLSID\{0a556d98-cfee-4d84-82a7-00377f939198}

PixyNetLoader SHA256