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 finding 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 via the UI. In this case, 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 analysts (for EXPMON Public, that's me) can check the detection logs on the Controller. These logs contain much more granular information, allowing us to potentially uncover more "bad samples" during that process. This can also be fairly fast most of the time.
3. The final approach to finding 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 samples. 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 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_.