Technical McAfee Detail On DoubleAgent


McAfee / Intel Security has been searching the impact of the so-called, “DoubleAgent zero-day”, technique of Windows debugging capabilities announced on 22nd Mar, 2017.

This injection technique uses a MS Windows debugging feature that requires administrative privileges. On the fly debugging is created to be used with all Microsoft Windows executables. It’s not specific to Antivirus products in general, nor McAfee products in particular.

Techniques using IFEO (Image File Execution Options) have been known for a number of years, as part of a continuing process to research and evaluate security related techniques against software and hardware that we all depend upon. For example, similar techniques manipulating the Windows process debugging registry key have been publicly discussed for at least several years.

This blog is not about the validity of any form of IFEO attack. Nor are we discussing the advantages of this attack over the myriads of approaches that would allow for the attacker to misuse a Windows device. Once an attacker gains administrative privileges on a Windows machine through whatever means, which attacks the attacker may choose lies outside of this analysis.

Rather, this analysis attempts to establish the resilience of McAfee endpoint solutions to this type of injection attack, to enumerate the mechanisms that are available to McAfee’s customers to mitigate or negate such attacks, and the ability of our solutions to expose such attack attempts.

McAfee software fundamentally must rely on the underlying operating system. Where techniques are identified that could impact the integrity of software through operating system mechanisms such as IFEO, McAfee software must implement detective and protective mechanisms. In this particular technique for example, we have implemented measures into our most up-to-date consumer and enterprise products that would prevent execution of injected McAfee binaries from malicious parties.
When it comes to our endpoint protection solutions and their ability to protect their own processes, there are multiple layers of protection at play.

For the most recent Endpoint Security Solution (ENS), McAfee offers three mechanisms:

  • #1 – Self-protection rules to prevent the creation of IFEO registry keys
  • #2 – Self-protection rules to prevent process injection from untrusted processes
  • #3 – Module sanitization to validate that a module (DLL) is validly signed by a trusted authority before loading the DLL (irrespective of the load mechanism, including injection)

You can find details about process injection self-protection (#2) and module sanitization (#3) in the following KB

Module sanitization (#3) is enforced by default in our ENS (Endpoint Security Solution).

Self-protection rules for registry (#1) come in different flavors depending of the McAfee product installed. The default rules shipped with the product protect core McAfee services from allowing IFEO keys to be created. Since the current shipping rules focus on core services, we are pushing an update to add exhaustive coverage of all product binaries for each product that uses McAfee’s Anti-Malware Core (AMCore) technologies, which includes ENS. For products using VirusScan Core (VSCore), rules can be manually added.

In addition to covering an exhaustive list of McAfee binaries, the update for the self-protection registry rules (#1), will also include coverage against a technique variant in which a malicious IFEO key has been constructed elsewhere and then renamed (IFEO rename vector).

Depending of the IFEO (Image File Execution Options) injection target, the mechanism blocking the attack may differ. If the target is protected by self-protection registry rules the attack will be mitigated. If the target is not protected by self-protection registry rules, then the injection will occur but then McAfee’s module sanitization, where enforced, will block the attempted load and revoke trust for the injected process.

In the worst-case scenario for ENS, if the registry entry is created and the injection occurs, the process will fail to launch because the load of the malicious DLL will be denied. The McAfee ENS processes will not allow the malicious module to execute.
McAfee products also offer generic protection that would prevent such attack on other non-McAfee processes.In the context of ENS, customers can enforce the “Hijacking .EXE or other executable extensions” rule, which would prevent the creation of any [program].exe key under IFEO. Dynamic Application Containment (DAC) would also restrict contained processes from creating IEFO keys.

It is important for customers to note that before the IFEO keys may be manipulated, an attacker must first gain entrance to a Windows system. If the user account has not been given administrative privileges, then an additional step must be taken by the attacker to achieve these privileges. There are numerous techniques for achieving each of these steps.

Both VSE and ENS have been designed to identify and prevent techniques used by attackers to gain a presence under Windows and to stop attacker elevation of privileges to System Administrator. Customers are always advised to keep their McAfee DAT file updated to the latest version, to use the latest versions of McAfee products, and to patch Windows swiftly whenever Microsoft issues a security update. The vast majority of the entrances to intrusion (Windows and otherwise) has typically been through issues where an available fix has not been applied (patched).

We will continue research into those techniques that target hardware and software that we rely upon. This is crucial into providing customers the confidence to rely upon systems that their businesses, and homes have grown to depend upon.

Leave a Reply