EXPMON detected sophisticated zero-day fingerprinting attack targeting Adobe Reader users

Executive Summary

• The EXPMON system detected a highly-sophisticated PDF exploit targeting Adobe Reader users.

• Based on our analysis, the sample acts as an initial exploit with the capability to collect and leak various types of information, potentially followed by remote code execution (RCE) and sandbox escape (SBX) exploits. It abuses zero-day/unpatched vulnerability in Adobe Reader that allows it to execute privileged Acrobat APIs, and it is confirmed to work on the latest version of Adobe Reader.

• Specifically, it calls the “util.readFileIntoStream()” API, allowing it to read arbitrary files (accessible by the sandboxed Reader process) on the local system. In this way, it can collect a wide range of information from the local system and steal local file data.

• The "RSS.addFeed()" API is called to serve two purposes: sending the information collected from the local system to a remote server and receiving additional JavaScript code to be executed.

• Such a mechanism allows the threat actor to collect user information, steal local data, perform advanced "fingerprinting", and launch future attacks: if the target meets the attacker's conditions, the attacker may deliver additional exploit to achieve RCE or SBX.

• However, during our tests, we were unable to obtain the said additional exploit - the server was connected but no response. This could be due to various reasons - for example, our local testing environments may not have met the attacker’s specific criteria.

• Nevertheless, this zero-day/unpatched capability for broad information harvesting and the potential for subsequent RCE/SBX exploitation is enough for the security community to remain on high alert. This is why we have chosen to publish these findings immediately so users can stay vigilant. We will also share this blog post with Adobe Security.

The story of the detection

Just few weeks ago, on March 26, someone submitted a PDF sample on EXPMON. The sample, while named as "yummy_adobe_exploit_uwu.pdf" by the submitter*, triggered one of EXPMON's advanced "detection in depth" features. You can check out the original submission  here:

https://pub.expmon.com/analysis/328131/

The sample is also on VirusTotal since March 23, with currently a low 5/64 detection, as you can find out here.

*EXPMON doesn't collect any information regarding the submitter and we don’t know who submitted the sample.

You can see the sample was detected as the following, in the "winx64(update20250816)_reader(2023.006.20320)[acrobatreader]" env.

Informational - "the pdf may produce suspicious activity, please check (this is result of an experimental detection-in-depth feature, fp may well exist, reporting fp welcome)"

For those who are not familiar with EXPMON’s strategy to combat advanced zero-day or unknown exploits, let me try to explain it in more detail. EXPMON identifies "bad samples" through three processes:

1. The first is when the system reports a threat immediately on the UI or via the Web APIs. In this case/sample, the system successfully flagged the sample as suspicious and requested a manual analysis. This is the ideal and fastest method of detection.
2. The second is that admins (for EXPMON Public, that's me) can check the detection logs on the Controller, or if you are just an analyst you can examine the Indicators displayed on the UI/Web APIs - even if the high-level Detection Result is still labeled as "Undetected". These logs and Indicators contain much more granular information, allowing analysts to uncover sophisticated exploits that the automated system may not have flagged immediately. While this manual review could be fast, it does require dedicated manpower and deep domain knowledge.
3. The final approach to finding true advanced zero-day or unknown exploits is what I call the "Big Data Analytics" (BDA) process. Thanks to the architecture of the EXPMON system, we are able to perform meaningful Big Data Analytics across millions of logs. In this process, we may find abnormalities or threats missed during the previous two processes and learn how to improve our Detection Logic. This is a powerful way of threat hunting; however, it involves significant manual analysis and usually requires a lot of time.

This "detection in depth" feature triggered by this particular sample is a very advanced detection capability I specifically developed for Adobe Reader. It is designed to counter the complexity and flexibility of Acrobat’s PDF JavaScript engine. While I prefer not to disclose the full details of how this feature works yet (as noted by the redacted indicator names in the public version) - the reason is obvious - for detection purposes, a trigger of this nature already warrants a manual analysis. If you are an EXPMON user and see a sample detected in this manner, you should perform an in-depth manual analysis and proceed with caution.

Manual analysis of the sample

Recently, I haven't been reviewing the logs or performing BDA on the data collected by EXPMON Public as often - I've been quite busy with my other project which is about "fuzzing Office at scale". However, this week, while planning to perform a long-overdue BDA, this sample caught my eye immediately because it triggered the Acrobat "detection-in-depth" feature! So I decided to perform a manual analysis of this sample, and I quickly hit a "wow" moment - it turns out this one is highly sophisticated. First, it attempts to execute JavaScript within object 9; as you can see in the image below, the JS code is heavily obfuscated.

And.. aha, yes, I used AI and quickly de-obfuscated the code, to something like the following.

app.t = app["setTimeOut"](util["stringFromStream"](SOAP["streamDecode"](util["streamFromString"](getField("btn1")["value"]), ("base64"))

Basically, what the above code does is base64-decoding the string from an object named "btn1" and run it as JavaScript. Looking at where "btn1" is located, we found it within object 7.

Then, we decoded the long string w/ base64, which reveals a significant amount of JavaScript code.

As you could see, the base64-decoded JavaScript is still highly obfuscated. I asked AI to help me de-obfuscate the JS (though I had a mix of good and bad experiences with that - sigh). Eventually, I managed to get a sense of the clean code.

The following are some readable, clean code blocks generated by AI based on the obfuscated code. Please note that in my experience, this AI-generated code only helps you quickly understand at a high level what the malicious code is doing; it is not the same as the actual, working de-obfuscated JavaScript. Keep that in mind.

The start, calling “RSS.addFeed()” API in a privileged way.

The URL parameters for the “RSS.addFeed()” call.

Note that the script collects various information from the local system, including language settings, the Adobe Reader version number, the exact OS version, and the local path of the PDF file. It then sends all of this data as part of the URL to the remote server. The server address is “169.40.2.68:45191”.

It can even read local files by calling the privileged “util.readFileIntoStream()” API. The following abstract code reads data from the ntdll.dll file and calculates the exact OS version number from it. This is particularly useful for future exploitation.

When/if it successfully obtains the returned JavaScript from the remote, attacker-controlled server (via the “RSS.addFeed()” API), it even utilizes cryptography to decrypt the payload, specifically to evade network-based detection I'd guess.

Testing the sample

With all the previous understandings of the abstract code, we can now do real-world testing and analysis. Please note that the previous static analysis (aided by AI) only produced abstract code - while this may help you understand the general behaviors, really, you need to do some real, dynamic tests in real environments to confirm anything.

I tested the sample on the latest version of Adobe Reader (26.00121367), and it still worked. Therefore, the initial exploit we detected - which collects local information and sends it to a remote server - remains a zero-day/unpatched vulnerability as of this writing.

The attacker-controlled server was still online at the time of testing - as you could see in the above image, it got connected. However, it did not deliver the potential RCE/SBX exploit indicated in the sample. This could be due to several factors: for instance, the attacker's server might have "blocked" my IP address, or perhaps I needed to provide specific local information to satisfy the server's conditions. This strongly resembles an advanced fingerprinting attack.

Regardless, I would be interested to see if anyone else manages to figure out what the RCE/SBX or additional exploit looks like.

I even went farther..

1. I modified the exploit code to connect to my own server. When my server returned a simple line of JavaScript code – ‘app.alert("inside the JS returned from the server!")’ – it was successfully executed by the Adobe Reader client. This confirms that the remote server has the capability to deliver and launch subsequent RCE or SBX exploits.

2. I modified the code to read a local .png file from the system32 directory and send it to my controlled server. It successfully performed the task. This proves that, even without a subsequent RCE/SBX exploit, this initial exploit is fully capable of stealing a wide range of sensitive data from the local system.

Conclusions

In this blog post, we shared an EXPMON detection and our analysis of a highly sophisticated, fingerprinting-style PDF exploit targeting Adobe Reader users. This "fingerprinting" exploit has been confirmed to leverage a zero-day/unpatched vulnerability that works on the latest version of Adobe Reader without requiring any user interaction beyond opening a PDF file. Even more concerning, this exploit allows the threat actor to not only collect/steal local information but also potentially launch subsequent RCE/SBX attacks, which could lead to full control of the victim's system.

For defense, we will notify Adobe Security immediately about our findings. We hope they can patch the zero-day vulnerabilities exploited in this initial attack as soon as possible. We recommend that Adobe Reader users remain vigilant regarding PDF files sent by untrusted parties until an official patch is available.

For detection, If you have security products in place, you may also block and monitor the attacker-controlled IP address found in this sample – the 169.40.2.68:45191 – but keep in mind that this will not stop other variants using different infrastructure. A better approach is to look at all http/https traffic which have the "Adobe Synchronizer" string in the User Agent field.

If you encounter suspicious PDF samples, you may consider submitting them to EXPMON Public (https://pub.expmon.com). As we discussed, the EXPMON system employs highly advanced "detection-in-depth" features to combat sophisticated PDF zero-day exploits like this one. If you see a detection similar to this, you must be extremely careful, as it could be a new variant. The EXPMON system is designed to detect such variants without requiring any signature updates.

Finally, if you are interested in further collaborations against advanced zero-day or unknown exploits – for example, if your samples cannot be shared publicly – please reach out to contact@expmon.com. You can also follow EXPMON updates on Twitter/X at https://x.com/EXPMON_.

[Update on April 8] A new variant was found today by @greglesnewich. I've confirmed this finding, it connects to IP address 188.214.34.20:34123. This sample appeared on VT on 2025-11-28, showing that this 0day/APT campaign has been ongoing for at least 4 months.

[Update on April 11] 

Adobe has confirmed our findings and has issued an emergency security update for all Adobe Reader (and other affected products) users.

https://helpx.adobe.com/security/products/acrobat/apsb26-43.html

The underlying exploited zero-day vulnerability has been rated Critical (CVSS 8.6) and is tracked as CVE-2026-34621. It appears that Adobe has determined the bug can lead to arbitrary code execution - not just an information leak. This aligns with our findings and those of other security researchers over the last few days.

EXPMON would like to thank Adobe for releasing this emergency security update quickly to help protect users. We highly recommend that users to apply the official patch/update as soon as possible.

[Update on April 12]

Adobe has informed us that they previously made a mistake with the CVSS score and have now corrected it to 8.6. This reflects the fact that the vulnerability is triggered via a local file-opening attack vector. Please note that this does not reduce the urgency of the issue and users should continue to apply the patch as soon as possible in order to prevent potential attacks.

A major update of the EXPMON system: focusing on modern software exploits

After a year-long focus on another project - an innovative initiative aimed at discovering bugs in rich, UI-heavy closed-source software like Microsoft Office applications through large-scale, code-coverage-based fuzzing (resulting in 26 valid CVEs in Office) - I’ve finally had the chance to update the EXPMON Public system.

The updated version is now open to everyone at the same URL:

https://pub.expmon.com

Or, if you're first to this place and want to know more about the EXPMON approach and methodology, please read here:

https://justhaifei1.blogspot.com/2024/04/opening-expmon-for-everyone.html

Let me explain briefly why this major update is necessary.

When we talk about exploits or vulnerabilities, it’s crucial to specify the "environment" - the software and its specific version that the exploit targets (sometimes, this also includes the particular configuration of the software environment or hardware). Without specifying the environment, discussing an exploit or vulnerability is meaningless. For example, a Microsoft Office .docx Word exploit may pose no harm when opened in LibreOffice. This is the core concept behind the EXPMON project: the "environment-binding" approach to analyzing software behaviors.

After opening up the system for public for more than 1.5 years (in addition to the public online version, I also have EXPMON instances running in my lab, which has been quite helpful for analyzing and understanding software), it’s time to update the system to reflect the fact that some of the environments are now outdated.

For example, the EXPMON system previously included an Office 2010 environment, which is now very outdated. The goal of the public version of EXPMON is to help users detect potential modern, advanced, or zero-day exploits, so maintaining the Office 2010 environment is no longer necessary. As a result, this update has removed all Office 2010 virtual machines. Consequently, you may notice that an Office 2010 exploit sample might now be marked as "Undetected", as EXPMON Public now only supports modern versions of Office.

(Also please note that this update is partly a resource-saving consideration. Since the EXPMON system is configurable, we can always bring back the Office 2010 environment if needed.)

Another major update is the addition of alternative office suites, in response to their growing popularity - particularly the open-source LibreOffice and the WPS Office Suite. In fact, a significant portion of the work in this major update was focused on bringing these new software environments into the EXPMON system.

In the last year or so, I've read some information regarding advanced zero-day exploits or vulnerabilities in the LibreOffice and WPS apps. For example, this article details two very interesting vulnerabilities in LibreOffice, and this is about threat actors have been exploiting WPS zero-days in the wild for quite some time.

Beyond that, I've also added the Mozilla Thunderbird environment as an email client application to open and test .eml samples. This allows us to detect potential email-based (zero-day) exploits not only targeting Microsoft Outlook but also Mozilla Thunderbird users.

Other smaller updates include software version upgrades: I’ve updated the operating system, Office 2021, and Foxit Reader in the VMs.

In summary, the changes are as follows:

• An Office file sample will now be tested in three environments: Office 2021, LibreOffice, and WPS Office, compared to the previous testing of only Office 2021 and Office 2010.
• A PDF sample will now be tested in three environments: Acrobat Reader, Foxit Reader, and the PDF app in WPS Office, compared to the previous testing of only Acrobat Reader and Foxit Reader.
• An .eml email sample will now be tested in two environments: Microsoft Outlook and Mozilla Thunderbird, compared to the previous testing of only Microsoft Outlook.

You can find all the detailed environment specifications at https://pub.expmon.com/static/system/supported_filetype_apps.txt.

With these major updates, the EXPMON Public system is now capable of monitoring and analyzing potential zero-day exploit threats targeting modern Microsoft Office, LibreOffice, WPS Office, as well as Acrobat Reader, Foxit Reader, and Thunderbird - all with deep & retrospective Big Data Analytics supports.

That’s it! If you're interested, feel free to test it out at https://pub.expmon.com.

And of course, if you have ideas for collaborations (e.g., if you have a bulk of samples and want to check for potential zero-day exploits), or if you’d like to see EXPMON support additional applications or file formats, please contact me or email me at contact@expmon.com.