Since March of 2022 we’ve seen a gradual uptick in Adobe Acrobat Reader processes attempting to query which security product DLLs are loaded into it by acquiring a handle of the DLL. The significant rise over the recent months caught our attention as it is very unusual behavior for Adobe.
The requests originated from libcef.dll (a Chromium Embedded Framework (CEF) Dynamic Link Library which is used by many programs) which was indeed updated in March 2022.
Inside this DLL you can find a long list of hardcoded DLL names:
Figure 1. Partial Hard-Coded DLL list – Libcef.dll
The full list can be found at the end of the post.
The basic documentation for the Chromium DLL contains a short list of DLLs that have been blacklisted by them for causing conflictions.
Figure 2. Hardcoded blacklist by Chromium
However, any vendor that uses libcef.dll can easily change this DLL list. The hard-coded DLL list in the Adobe libcef.dll version we checked had been edited and was surprisingly longer and also contains the DLLs of the following security products:
- Trend Micro
- BitDefender
- AVAST
- F-Secure
- McAfee
- 360 Security
- Citrix
- Symantec
- Morphisec
- Malwarebytes
- Checkpoint
- Ahnlab
- Cylance
- Sophos
- CyberArk
- Citrix
- BullGuard
- Panda Security
- Fortinet
- Emsisoft
- ESET
- K7 TotalSecurity
- Kaspersky
- AVG
- CMC Internet Security
- Samsung Smart Security ESCORT
- Moon Secure
- NOD32
- PC Matic
- SentryBay
The Libcef.dll loading process
Libcef.dll is loaded by two Adobe processes: AcroCEF.exe and RdrCEF.exe. Both these files are “handling multiple integral aspects of the application, such as network interaction and Document Cloud services (Fill and Sign, Send for Signature, Share for View/Review, and so on)”. As both use the same DLL, we found that both of them check for the security products mentioned above.
To better understand what happens to the injected DLL, we took a deeper dive into some parts of the Chromium embedded framework DLL source code.
It appears that a registry key is used to determine whether or not to check for the injected DLLs. In Adobe Reader’s case it is “SOFTWARE\Adobe\Adobe Acrobat\DC\DLLInjection\bBlockDllInjection”. The registry key is created in the first run of Adobe Reader and is set by default to ‘0’. The key is usually located in the HKEY_CURRENT_USER registry hive, which is accessible and editable by the user, which means anyone can change the key. When ‘bBlockDllInjection” is set to ‘1’, libcef.dll will perform a loaded DLL check.
With the registry key name bBlockDllInjection, and looking at the cef documentation, we can assume that the the blacklisted DLLs are designated to be unloaded. We also found a post on the Citrix blog a few months ago, in which they mention: “”Adobe suggested to disable DLL-injection for Acrobat and Reader. You need .. the newest version for this. Adobe had a lot of trouble with DLL injection from some AV vendors.””
It is worth mentioning that this key is set after every Acrobat Reader execution. We spotted that in most cases it is set by default to ‘0’. However, in other, rare cases it is set to ‘1’. The default value, we assume, is affected by the endpoint environment, version of Acrobat, and other local environmental properties.
The outcome of Adobe blocking dll injections of security modules could potentially be catastrophic. When a security product is not injected into a process, this basically disables any visibility it may have on the process and hinders detection and prevention capabilities inside the process and inside every created child processes. Actions performed by the Adobe processes and processes created by it would essentially be much harder to monitor, as will be determining context. It would be easy enough for a threat actor to add a command in the ‘OpenAction’ section of a pdf, which can then execute PowerShell, which could for example, download the next stage malware and execute it reflectively. Any of these actions would not be detected if the security product hooks are missing.
We contacted Adobe for comment, and they answered that this is due to “incompatibility with Adobe Acrobat’s usage of CEF, a Chromium based engine with a restricted sandbox design, and may cause stability issues”
Implications of findings
It would appear that what is effectively happening here is that a very wide-spread legitimate software is checking if there are any security products in the environment and perhaps even blocking them from injecting into the process. This behavior is all too common among evasive malicious software in order to stay “under the radar” and execute their malicious attack only when they’ve determined that they won’t be caught. The most devastating attacks start by scanning the environment in order to ensure they can get a strong foothold in the network.
We were initially concerned that this could be the start of a supply chain attack. This is the biggest concern with this kind of behavior and is exactly how large-scale attacks like the Solar Winds attack started, where the software suddenly started behaving differently than usual and making seemingly unnecessary and suspicious queries. This however does not seem to be the case in this instance.
It would appear that Adobe has chosen an approach which solves an immediate compatibility issue, but could create new issues from a security perspective. Instead of directly mitigating compatibility issues with security software, our opinion is that they are trying to mitigate these issues by simply preventing the interfering software from affecting the process, even if it is a security process designated to protect the system from malicious attack.
This to us, is a prime example of a large enterprise company with a multi-million strong install-base prioritizing convenience and essentially inserting malware-like behavior into their software instead of working to actually solve the issue at hand. This type of behavior essentially legitimizes suspicious behavior and creates “noise” which makes it more difficult to differentiate between bad actors and companies who don’t prioritize ensuring their software doesn’t appear malicious. This type of behavior should be mitigated, as if it becomes mainstream, it could make it all too easy for malicious software to easily query and identify whether or not they are located in an environment in which they can be detected.
Enterprises need to take responsibility for how they build their software and the implications it can have on the community as a whole.
Minerva Armor blocks this type of malicious behavior
We were able to detect this suspicious behavior as Minerva Armor’s Ransomware Protection Platform controls how software perceives its environment and not only intercepts all queries that are made to the OS, but also controls the answers that are given to the process. In this particular case, had the process been malicious, Minerva Armor would have answered that all the security tools in the query were indeed running, regardless of whether they really were, making the malicious software think it was in danger of being detected. Providing just one answer that the malware doesn’t want to hear is often enough to break the execution logic and and cause it to shut down.
Figure 3 – One of the many security tool query events triggered by Abode Acrobat on Minerva Armor
Full list of DLL queries:
| TmUmEvt.dll | zbrcom32.dll | touchoph.dll | psnmvcomm64.dll |
| tmmon.dll | vh.dll&nb” |