We’ve noticed a slow increase in Adobe Acrobat Reader processes since March 2022 trying to find out which security product DLLs are loaded into them by obtaining a handle of the DLL. We were interested in the substantial increase over the past few months because it is quite unusual behaviour for Adobe.
The post’s conclusion includes a link to the complete list.
A brief list of DLLs that Chromium has blacklisted for generating conflicts may be found in the DLL’s basic documentation. The requests came from libcef.dll, a dynamic link library used by numerous apps that was updated in March 2022 and is part of the Chromium Embedded Framework (CEF). However, this DLL list can simply be modified by any vendor using libcef.dll. The hard-coded DLL list in the version of Adobe’s libcef.dll that we examined had been modified, was surprisingly lengthier, and also includes the DLLs of the following security programmes:
- TIGR Micro
- BitDefender
- F-Secure AVAST
- McKee 360 Security
- Citrix
- Symantec
- Morphisec
- Malwarebytes
- Checkpoint
- Ahnlab
- Cylance
- Sophos
- CyberArk
- Citrix
- BullGuard
- Google Security
- Fortinet
- Emsisoft
- ESET
- K7 TotalSecurity
- Kaspersky
- AVG
- CMC Internet Protection
- Samsung Smart Safety ESCORT
- Moon Safe
- SentryBay PC Matic NOD32
The procedure for loading Libcef.dll
AcroCEF.exe and RdrCEF.exe, two Adobe processes, both load Libcef.dll. These two files “handle various fundamental components of the application, including network interaction and Document Cloud services (Fill and Sign, Send for Signature, Share for View/Review, and so on)”. We discovered that both of them check for the aforementioned security products because they share the same DLL. We delved further into various areas of the Chromium embedded framework DLL source code to learn more about what happens to the injected DLL. It appears that the choice of whether to look for the injected DLLs is made using a registry key. It is “SOFTWAREAdobeAdobe AcrobatDCDLLInjectionbBlockDllInjection” in the case of Adobe Reader. When Adobe Reader is first launched, a registry key is generated with a value of ‘0’ by default. The key is typically found in the registry hive HKEY CURRENT USER, which is open to and modifiable by the user, meaning that anybody can alter the key. The loaded DLL check is carried out by libcef.dll when ‘bBlockDllInjection’ is set to ‘1’.
We can assume that the blacklisted DLLs are intended to be unloaded based on the registry key name bBlockDllInjection and the cef documentation. Additionally, a few months back, Citrix published a blog entry in which they mention: “It was advised by Adobe to turn off DLL injection for Acrobat and Reader. The most recent version is required for this. DLL injection from some AV vendors caused Adobe a lot of problems “It is important to note that this key is set upon each launch of Acrobat Reader. We discovered that it is typically set to “0” by default. It is set to “1” in other, extremely unusual circumstances. We assume that the endpoint environment, Acrobat version, and other local environmental characteristics have an impact on the default value. The results of blocking security module dll injections by Adobe could be disastrous. When a security product is not injected into a process, this effectively disables any visibility it may have on the process and inhibits detection and prevention capabilities both within the process itself and inside each child process that is spawned. Essentially, it would be considerably more difficult to monitor actions taken by Adobe processes and processes that it has produced, as well as establish context. A threat actor might easily add a command to a pdf’s ‘OpenAction’ section that will launch PowerShell, which could, for instance, download and execute the next step of malware. If the security product hooks are absent, none of these actions would be recognised. When we asked Adobe for a reply, they said that this was because “Adobe Acrobat’s utilisation of CEF, a Chromium-based engine with a restricted sandbox design that may cause stability difficulties,” was incompatible.
Consequences of the findings
It would seem that what is actually occurring in this situation is that a very popular and genuine piece of software is checking to see if there are any security products there and may even be preventing them from inserting themselves into the process. Evasive malicious software frequently engages in this activity in order to operate “under the radar” and carry out their harmful attack only when they are confident that they won’t be detected. The most damaging attacks begin by evaluating the surroundings to make sure they can establish a solid foothold in the network. At first, we were worried that this might be the beginning of a supply chain attack. The major issue with this type of behaviour is that it is precisely how significant attacks like the Solar Winds attack got started, where the software suddenly started acting strangely and asking questions that seemed superfluous and suspicious. However, it doesn’t appear like this is the case in this instance. It appears that Adobe has made a decision that would immediately alleviate a compatibility issue but may lead to additional security concerns. Our opinion is that they are attempting to mitigate compatibility issues by merely preventing the interfering software from affecting the process, even if it is a security process intended to safeguard the system from malicious attack, rather than directly addressing compatibility issues with security software. This, in our opinion, is an excellent illustration of a huge corporate corporation emphasising convenience and effectively introducing malware-like behaviour into their software instead of attempting to genuinely solve the problem at hand. This kind of behaviour effectively normalises suspicious activity and generates “noise,” which makes it more challenging to distinguish between criminal actors and businesses who don’t prioritise making sure their software doesn’t look harmful. This kind of activity needs to be curbed because if it spreads, dangerous software may find it all too simple to query and determine whether they are present in an environment where they may be discovered. Enterprises must be accountable for the software they develop and the effects they may have on the community as a whole.
Minerva Armor prevents this kind of harmful activity.
As Minerva Armor’s Hostile Surroundings Simulation regulates how software perceives its environment and not only intercepts all OS requests, but also controls the replies that are supplied to the process, we were able to identify this suspicious activity. In this specific example, Minerva Armor would have responded that all the security tools in the query were indeed operating, regardless of whether they actually were, giving the false impression that the malicious software was in danger of being discovered. Giving the malware just one response it doesn’t want to hear will frequently be enough to disrupt its execution logic and force it to terminate.