office受保护视图_使用受保护的视图激发恶意Office文档-CSDN博客

office受保护视图

介绍 (Intro)

I wanted to share an interesting behavior I discovered with Microsoft Office documents using a fully patched Windows 10 operating system and an up-to-date local installation of MS Office 365. I’ve been doing a lot of development work on my phishing tool lately, PhishAPI, and more or less stumbled across this new technique. I have reported it to Microsoft.

我想分享一个有趣的行为，我发现该文件是使用完整补丁的Windows 10操作系统和最新的MS Office 365本地安装程序在Microsoft Office文档中发现的。最近，我一直在使用网络钓鱼工具进行大量开发工作， PhishAPI ，或多或少偶然发现了这项新技术。我已经报告给微软了。

I’m writing this blog post in order to hopefully shed some light on the risk this issue introduces and to assist with white-hat phishing techniques. Most savvy users know better than to enable “Protected View” mode when opening their remote Office documents. However, doing so on a malicious document (maldoc) can result in captured information such as an IP address, action timestamps, OS/Office version disclosures, and perhaps the biggest, NTLMv2 hash leaks!

我写这篇博客是为了希望阐明该问题带来的风险并协助使用白帽网络钓鱼技术。大多数精明的用户比打开远程Office文档时启用“保护视图”模式要了解的多。但是，对恶意文档(maldoc)执行此操作可能会导致捕获到的信息，例如IP地址，操作时间戳，OS / Office版本泄漏，甚至可能是最大的NTLMv2哈希泄漏！

一些背景 (Some Background)

The technique of embedding invisible HTTP and UNC calls in Microsoft Office documents is not a new one and has been around for some time now. As most of you probably know already, newer Office files such as Word documents (docx) are essentially compressed archives themselves with XML data within them. To see this for yourself, simply open a docx file in your favorite archive tool or rename to .zip and open it directly to see the contents.

在Microsoft Office文档中嵌入不可见的HTTP和UNC调用的技术并不是一项新技术，并且已经存在了一段时间。你们大多数人可能已经知道，较新的Office文件(例如Word文档(docx))本质上是压缩的存档，其中包含XML数据。要亲自查看，只需在您喜欢的存档工具中打开一个docx文件或重命名为.zip并直接将其打开即可查看内容。

Within these archives are resources such as images embedded within the Word document, as well as XML files which reference their locations. You can use external images as well, which is where HTTP calls come in. Referencing an external URI instead of a physical path within the document itself will result in Word happily calling out to retrieve it over the Internet. You can make this an invisible image so it’s not seen in the document viewer itself. A quick and easy technique used by red teams is to set up a Netcat/Python/NodeJS listener to wait for the call, something like `nc -lv 0.0.0.0 80`or `python -m SimpleHTTPServer 80`. With some basic logging, they can see the source IP which requested the resource and know when the connection occurred.

这些档案库中包含资源，例如Word文档中嵌入的图像以及引用其位置的XML文件。您也可以使用外部图像，这是HTTP调用的来源。引用外部URI而不是文档本身内的物理路径将导致Word高兴地调出以通过Internet检索它。您可以使它成为不可见的图像，以便在文档查看器本身中看不到它。红色团队使用的一种快速简便的技术是设置Netcat / Python / NodeJS侦听器以等待呼叫，例如nc -lv 0.0.0.0 80或python -m SimpleHTTPServer 80 。通过一些基本的日志记录，他们可以看到请求资源的源IP并知道何时发生连接。

With PhishAPI, I took things a step further by automating the XML creation for new documents as well as inserting a hook into existing documents the user can upload through a web interface. This way you should never have to touch the XML or open up a Word document to weaponize it, and everything can be done quickly and easily. I wrote another blog about that process if you’d like to read it. Essentially, PhishAPI works as a web service to listen for these requests and captures IP addresses, user-agent information, credentials (like Phishery, by using basic-auth), and hashes if it’s an SMB request via the UNC call (thanks to Responder in the background!). It does a lot of other things too, such as clones fake portals and creates email templates for campaigns but that’s outside of the scope of this discussion. It then looks up a GUID in a database when it receives a request in order to relate it to a specific phishing campaign and target and then alerts via a specified Slack channel so the “attacker” can be notified in real-time. Enough about PhishAPI though, this is what the XML would look like in the Word document if you were to do something like this manually:

使用PhishAPI，我为自动为新文档创建XML以及在用户可以通过Web界面上传的现有文档中插入钩子，迈出了一步。这样，您就不必接触XML或打开Word文档对其进行武器化，并且可以快速，轻松地完成所有工作。如果您想阅读该文章，我也写了一篇有关该过程的博客。本质上，PhishAPI充当Web服务来侦听这些请求，并捕获IP地址，用户代理信息，凭据(如Phishery，通过使用basic-auth)，如果通过UNC调用是SMB请求，则散列(感谢Responder)在后台！)。它还做很多其他事情，例如克隆伪造的门户网站并为活动创建电子邮件模板，但这不在本讨论的范围之内。然后，它在收到请求时在数据库中查找GUID，以便将其与特定的网络钓鱼活动和目标相关联，然后通过指定的Slack通道发出警报，以便可以实时通知“攻击者”。尽管足够使用PhishAPI，但是如果您要手动执行以下操作，那么XML在Word文档中将是这样：

Image for post — **document.xml.rels with Custom External HTTP/UNC Calls** **带有自定义外部HTTP / UNC调用的document.xml.rels**

To mitigate this, Microsoft added something called “Protected View” to the Office suite back in the 2010 version. Everyone’s probably familiar with this little yellow ribbon at the top of your documents which you have to “Enable” in order to make changes or run dynamic content. This is Microsoft’s way of protecting the average user who just wants to view a remote document without needing to run macros and other dynamic/remote content. There’s actually a flag that gets set when the document originates from somewhere other than your workstation which enables Protected View. Once you manually override it once, the flag gets reset and will not prompt again for that document. You’re essentially marking this document as safe and can move on. You can also universally disable the setting in Word but that’s not recommended and isn’t a default, so not many users would be susceptible out of the gate.

为了缓解这种情况，Microsoft在2010版本的Office套件中添加了称为“保护视图”的内容。每个人都可能熟悉文档顶部的小黄丝带，必须对其进行“启用”以进行更改或运行动态内容。这是Microsoft保护普通用户的一种方法，该用户只需要查看远程文档而无需运行宏和其他动态/远程内容。当文档来自工作站以外的其他地方时，实际上会设置一个标志，该标志会启用受保护的视图。手动覆盖一次后，该标志将重置，并且不会再次提示该文档。您实际上是在将该文档标记为安全并且可以继续使用。您也可以在Word中普遍禁用该设置，但是不建议这样做，也不是默认设置，因此不会有很多用户受到影响。

If you don’t supply your own document to PhishAPI, it uses this as a default template in an attempt to fool users into “Enable Editing” on their own. I know, dirty! I borrowed this technique from somewhere else. However, if they just view the document and do not bypass Protected View on their own, the call will never make it to the PhishAPI server and I won’t receive any notification the user even opened it. Bummer!

如果您不向PhishAPI提供您自己的文档，它将使用此文档作为默认模板，以试图欺骗用户自己进行“启用编辑”。我知道，脏！我从其他地方借来了这项技术。但是，如果他们只是查看文档而不自己绕过保护视图，则该调用将永远不会到达PhishAPI服务器，并且我什至都不会收到用户打开它的任何通知。 mm！

发现 (The Discovery)

I used PhishAPI to generate a new document using the default template as I had done many times before. This was for a current social engineering engagement we were performing for a client. I downloaded the Word doc, browsed out to the location using Windows File Explorer, and sent it to a co-worker so they could have some Phishing fun in our Slack channel. I was surprised to see the document had already fired off an alert, knowing that this was a newly created document from the Internet and would have had the Protected View flag still set. I never opened it!

我使用PhishAPI使用默认模板来生成新文档，就像我之前做过很多次一样。这是因为我们目前正在为客户执行的社会工程活动。我下载了Word文档，使用Windows File Explorer浏览到该位置，然后将其发送给同事，以便他们可以在我们的Slack频道中获得网上诱骗的乐趣。我很惊讶地看到该文档已经发出警报，因为它知道这是来自Internet的新创建的文档，并且仍会设置“保护视图”标志。我没打开过！

I quickly realized this occurred due to my use of the “Preview Pane” in file explorer on Windows 10. Just highlighting the document caused the internal payload to execute in the context of my user account on Windows. With it being a “preview”, there was no “Protected View” ribbon to display. This was interesting to me because my assumption was that by default, the preview version of the document (both handled by Microsoft) would have simply not shown dynamic or remote content.

我很快意识到发生这种情况是由于我在Windows 10的文件浏览器中使用了“预览窗格”。突出显示文档会导致内部有效负载在Windows上的用户帐户环境中执行。由于它是“预览”，因此没有要显示的“保护视图”功能区。这对我来说很有趣，因为我的假设是默认情况下，文档的预览版本(均由Microsoft处理)根本不会显示动态或远程内容。

You can see in the above image I still received the Slack notification even though this document has yet to be opened. It did not clear the flag from the document, however, because when I opened it in Word I was still prompted and it did not fire the payload. Protected View simply does not apply when previewing it in File Explorer!

您可以在上图中看到，即使此文档尚未打开，我仍然收到Slack通知。但是，它没有从文档中清除该标志，因为当我在Word中打开它时，仍然会提示我并且它不会触发有效负载。在文件资源管理器中预览时，受保护的视图根本不适用！

Okay, so HTTP requests are one thing, but can SMB requests initiated from UNC calls still leak an NTLMv2 hash from my user account? You bet! I fired up a local instance of Responder to listen on TCP 445/139 and even though “Protected View” was still set, I received my own hash on the local network. Yikes!

好的，所以HTTP请求是一回事，但是从UNC调用发起的SMB请求是否仍会从我的用户帐户中泄漏NTLMv2哈希？你打赌！我启动了Responder的本地实例以侦听TCP 445/139，即使仍设置了“ Protected View”，我仍在本地网络上收到自己的哈希。 kes！

To be thorough, I also tested Macros within Excel to see if the same is true, but it seems to be protected. You can preview older “.xls” files but the macros will not fire by default. You have to still “Enable Macros” from the ribbon for those to execute. I tested it myself in the same way with a local Responder instance just to be sure:

确切地说，我还测试了Excel中的宏，以查看是否相同，但似乎受到保护。您可以预览较旧的“ .xls”文件，但默认情况下不会触发宏。您仍然必须从功能区中“启用宏”才能执行这些操作。为了确定自己，我使用本地Responder实例以相同的方式对其进行了测试：

Lastly, another thing I noticed is that O365 for web (in a web browser) renders the page without protected view as well and causes (at least) the HTTP payload to fire. This is nice if your target is using O365 and you want to collect those Phishing statistics and know if they opened your email. During my research, I wasn’t able to get SMB to fire in the same way that this bypass technique works. I also noticed the PhishAPI/Phishery plain-text credential technique does not work here or locally due to the preview functionality not prompting for basic-auth when responding to 401 status codes.

最后，我注意到的另一件事是，Web的O365(在Web浏览器中)也呈现了没有保护视图的页面，并导致(至少)触发了HTTP有效负载。如果您的目标使用的是O365，并且您想收集这些网络钓鱼统计信息并知道他们是否打开了您的电子邮件，这很好。在研究期间，我无法以这种旁路技术起作用的方式触发SMB。我还注意到，由于预览功能在响应401状态代码时不提示基本身份验证，因此PhishAPI / Phishery纯文本凭据技术在此处或本地不起作用。

So preview pane might not always be enabled on your victim’s workstation, but that’s okay! I’ve noticed the major web browsers (at least Firefox and Chrome) enable previews by default when you’re uploading a file to a web site. The following screenshots are after I disabled Preview Pane in File Explorer and uploaded a file via Firefox and Chrome (Slack). You can see the call in the background of the second image.

因此，可能不一定总是在受害者的工作站上启用预览窗格，但这没关系！我注意到，当您将文件上传到网站时，默认情况下，主要的网络浏览器(至少是Firefox和Chrome)会启用预览。以下屏幕截图是我在“文件资源管理器”中禁用“预览窗格”并通过Firefox和Chrome(Slack)上载文件后的截图。您可以在第二张图像的背景中看到呼叫。

结论 (Conclusion)

So what’s the big deal? Well, for one, if you were crafty with your phishing campaign and you wanted to gather leaked information and hashes, you could probably prompt for an upload on your site to trigger the payload, for example. For another, there’s a big false sense of security users have when dealing with maldocs. They assume as long as they don’t open the file, or they open it but do not accept any prompts, they’re completely safe. However, as I’ve just demonstrated, just having the file exist on their file system is likely to eventually be triggered when the victim is browsing files at a later time. Perhaps they want to select it to send it to the Recycling Bin. This likely explains why a number of my phishing campaigns did not trigger initially but did several months after the campaign had ended, resulting in crackable NTLMv2 hashes.

那有什么大不了的？好吧，例如，如果您对网络钓鱼活动比较狡猾，并且想要收集泄漏的信息和哈希，则可能会提示您在网站上进行上传以触发有效负载。另一方面，用户在与maldocs打交道时会产生很大的错误安全感。他们假设只要不打开文件，或者打开文件但不接受任何提示，便是完全安全的。但是，正如我刚刚演示的那样，当受害者稍后浏览文件时，仅在文件存在于文件系统中时最终可能会触发该文件。也许他们想选择它以将其发送到回收站。这可能可以解释为什么我的许多网络钓鱼活动最初并未触发，而是在活动结束后几个月才触发，从而导致可破解的NTLMv2哈希。

I’ve sent this to Microsoft’s MSRC team as a potential bypass technique for Office’s “Protected View”. Unfortunately, after a couple of weeks of waiting for a response, they acknowledged this is in fact an issue they plan to address in the future but will not be awarding me with a bounty and plan to offer no future updates. That’s bad news for me, but great news for anyone who plans to leverage this for red teams since there’s unlikely to be a fix anytime soon. Here’s the quote:

我已将此邮件发送给Microsoft的MSRC团队，作为Office“保护视图”的一种潜在绕过技术。不幸的是，一对夫妇的等待响应星期后，他们承认这其实就是他们计划在未来的地址，但不会有赏金被授予了我，并计划未来提供没有更新的问题。这对我来说是个坏消息，但对于计划将其用于红队的任何人来说，这都是个好消息，因为不太可能很快就解决问题。这是报价：

“Our engineering team(s) determined that a fix for this issue does not meet our criteria for immediate security servicing. However it is a candidate for consideration for potential improvements in a future version of this product or service. At this time, we will not be providing ongoing updates of the status, or if there will be a fix for this issue, and we have closed this case.

“我们的工程团队确定针对此问题的修复不符合我们立即提供安全服务的标准。但是，它是考虑在此产品或服务的未来版本中进行潜在改进的候选人。目前，我们将不会提供状态的持续更新，或者是否有针对此问题的修复程序，我们已经结案。

Your report is not acknowledged as a security vulnerability by Microsoft. While all security vulnerabilities are bugs not all bugs are security vulnerabilities that meet the criteria for immediate security servicing.”

Microsoft未将您的报告确认为安全漏洞。尽管所有安全漏洞都是漏洞，但并非所有漏洞都是符合立即进行安全服务的标准的安全漏洞。”

Although it doesn’t entirely bypass the security feature within the suite itself, I think there’s still an issue here that exposes users to the risk of stolen credentials or leaked sensitive information at the very least. In fact, I believe it’s more severe than a direct bypass since you don’t even have to open the file, you just have to simply select it. I hope this blog helps to highlight this risk as a user and gives white-hat red teams another vector when Phishing. Hopefully, it will be resolved as I do believe the default should be to not render dynamic or external content. Stay safe out there!

尽管它并没有完全绕过套件本身的安全功能，但我认为这里仍然存在一个问题，使用户至少有被窃取凭据或泄露敏感信息的风险。实际上，我认为它比直接绕过更为严重，因为您甚至不必打开文件，只需选择它即可。我希望该博客有助于突出显示用户的这种风险，并在网络钓鱼时为白帽子红色团队提供另一个媒介。希望它将得到解决，因为我相信默认值应该是不呈现动态或外部内容。在那里安全！