You just fought long and hard to convince a user to click on your link. They are dying to know about the contents of your macro enabled excel file. So, don’t let web proxies ruin your fun by blocking your payload! We are in the home stretch, but that doesn’t mean we get to take a victory lap just yet.
你只是为了说服用户点击你的链接而进行了漫长而艰苦的斗争。他们迫切想知道启用宏的 excel 文件的内容。因此，不要让网络代理通过阻止您的有效负载来破坏您的乐趣！我们正处于主场，但这并不意味着我们还没有取得胜利。
我，尽量不吓到网络钓鱼
The Good Ol’ Days 美好时光
I remember it well. The year was 2014, and I was embarking on my first phishing expedition as a fledgling penetration tester. I fired up my Metasploit listener, minted an EXE payload with Veil, and called it ‘dresscode_policy.doc.exe’. I sent out my emails and, in return, was blessed with a bounty of shells raining in from the deep blue internet. In those days, it seemed like there would always be phish on the table. Looking back now, I can hardly believe it was ever so easy.
我记得很清楚。那一年是 2014 年，我作为一名初出茅庐的渗透测试人员开始了我的第一次网络钓鱼探险。我启动了我的Metasploit监听器，用Veil铸造了一个EXE有效载荷，并称它为“dresscode_policy.doc.exe”。我发送了我的电子邮件，作为回报，我得到了从深蓝色互联网上如雨点般涌来的炮弹。在那些日子里，似乎总是会有网络钓鱼。现在回想起来，我简直不敢相信它曾经如此容易。
Sparse Waters 稀疏水域
We’ve continued to overphish the same waters year after year with reckless abandon and now the phish don’t bite like they used to. The same bait doesn’t work. The same nets come up empty. We have only ourselves to blame for being so selfish (selphish?). We used EXEs like harpoons and now they are completely blocked unless they are signed. We wove nets of PowerShell until AMSI and constrained language mode cut them to ribbons. We dredged scores of users with Excel macros until Microsoft almost did away with macros entirely. We even used mark of the web bypasses to the brink of extinction.
我们继续年复一年地肆无忌惮地过度使用相同的水域，现在网络钓鱼不再像以前那样咬人了。同样的诱饵不起作用。同样的网是空的。我们只能责怪自己如此自私（selphish？我们使用了像鱼叉一样的 EXE，现在除非签名，否则它们会被完全阻止。我们编织了 PowerShell 的网络，直到 AMSI 和受约束的语言模式将它们切割成丝带。我们用Excel宏疏通了数十个用户，直到Microsoft几乎完全取消了宏。我们甚至使用网络绕过标记到灭绝的边缘。
How will we ever catch a phish again?
我们将如何再次捕获网络钓鱼？
What’s Really Happening 到底发生了什么
I was being a bit dramatic, but I did want to make one point:
我有点戏剧化，但我确实想说明一点：
Defenses adapt to threats and we are the threats.
防御适应威胁，而我们就是威胁。
As new phishing techniques emerge, one of the most obvious defenses has always been to try to block initial access payloads based on their file type. Someone starts slinging malware in Microsoft Excel add-in (XLL) files, and suddenly it makes sense for most organizations to just block these files outright. Payload types that were ‘working’ across the board just months ago tend to make too much noise and now get blocked.
随着新的网络钓鱼技术的出现，最明显的防御措施之一始终是尝试根据文件类型阻止初始访问有效负载。有人开始在 Microsoft Excel 加载项 （XLL） 文件中投放恶意软件，突然间，大多数组织完全阻止这些文件是有意义的。几个月前还在全面“工作”的有效载荷类型往往会产生太大的噪音，现在被阻塞了。
We may mourn the fall of our favorite initial access payloads (R.I.P. OLE), but not all hope is lost. Let’s talk about the challenge of initial access from a high level so we can see our options more clearly. First, we’ll talk about objectives, then discuss defenses, and finally bypasses!
我们可能会哀悼我们最喜欢的初始访问有效载荷（R.I.P. OLE）的倒塌，但并非所有的希望都消失了。让我们从高层次讨论初始访问的挑战，以便我们可以更清楚地看到我们的选择。首先，我们将讨论目标，然后讨论防御，最后绕过！
Can It Run Code? 它可以运行代码吗？
If a file type can run code, or open another application that can run code, then it can likely be used for initial access. To get a full list of potentially dangerous files, we can look at the ones blocked by default on Outlook:
如果文件类型可以运行代码，或者打开另一个可以运行代码的应用程序，则它可能可用于初始访问。要获取潜在危险文件的完整列表，我们可以查看 Outlook 上默认阻止的文件：
The list is 120 entries long! And even that is not the full list, considering that Outlook still allows dangerous file types like macro enabled Office documents. Thanks to @mrd0x, another good source is filesec.io:
该列表有 120 个条目！考虑到 Outlook 仍然允许危险的文件类型，例如启用宏的 Office 文档，这还不是完整的列表。多亏了@mrd0x，另一个很好的来源是 filesec.io：
Use the “Double Click” filter to find file types that are particularly useful for phishing. These “Double Click” files initiate some action when clicked by a user. Often running a script or executable of some kind. That list is 77 entries long!
使用“双击”过滤器查找对网络钓鱼特别有用的文件类型。这些“双击”文件在用户单击时启动一些操作。通常运行某种脚本或可执行文件。该列表有 77 个条目！
Our goal for initial access is to successfully deliver at least one of these files to the target and convince them to open/run it. Which file types are allowed will vary depending on controls in your target environment, but it is extremely unlikely that all of these file types are blocked. Often, several of these “dangerous” files are used in business processes and have exceptions applied to them. We just need to find one exception!
我们的初始访问目标是成功地将这些文件中的至少一个交付给目标，并说服他们打开/运行它。允许的文件类型因目标环境中的控件而异，但阻止所有这些文件类型的可能性极小。通常，这些“危险”文件中的几个在业务流程中使用，并且对它们应用了例外。我们只需要找到一个例外！
The Wall 长城
There is a wall between us and our target. It is lined with turrets that want to destroy our payload. This wall consists of the corporate proxy, the corporate firewall, and the target’s browser. Each has some visibility into what users are downloading and each will try to prevent users from inviting us into the network, but there’s a problem with their eyesight. They really only have three ways of knowing what file type is being downloaded, and we can control each one.
我们和目标之间有一堵墙。它两旁布满了想要摧毁我们有效载荷的炮塔。此墙由公司代理、公司防火墙和目标浏览器组成。每个都对用户正在下载的内容有一定的可见性，并且每个都会试图阻止用户邀请我们进入网络，但他们的视力存在问题。他们实际上只有三种方法来知道正在下载的文件类型，我们可以控制每一种。
- Extensions — The last characters of the file name (e.g., doc, txt, exe)
扩展名 — 文件名的最后几个字符（例如，doc、txt、exe） - MIME Types — The content type we specify in our server response headers (e.g., application/msword, text/plain, application/x-msdownload)
MIME 类型 — 我们在服务器响应标头中指定的内容类型（例如，application/msword、text/plain、application/x-msdownload） - Magic Numbers — The first bytes in a file (e.g., “50 4B 03 04” for .zip files or “4D 5A” for Windows executables)
幻数 — 文件中的第一个字节（例如，.zip文件为“50 4B 03 04”，Windows 可执行文件为“4D 5A”）
Under normal circumstances, these indicators should all tell a consistent story like:
在正常情况下，这些指标都应该讲述一个一致的故事，例如：
A windows executable with an extension of “exe”, AND a MIME type of “application/x-msdownload”, AND “4D 5A” (the “MZ” header) as the first two bytes.
扩展名为“exe”的 Windows 可执行文件，MIME 类型为“application/x-msdownload”，并且“4D 5A”（“MZ”标头）作为前两个字节。
Therefore, you could write a program to detect these dangerous files based on any single characteristic. Writing detections based on all three would be extremely redundant. I suspect many software engineers have made this very mistake. Choosing a single indicator, writing the detection logic, and thinking that would be enough. However, it’s the contents of the file and not its name, MIME type, or magic number that make it dangerous. Now that we have a clear view of our adversary, let’s talk about how we might slip past their watch.
因此，您可以编写一个程序来根据任何单个特征检测这些危险文件。基于这三者编写检测将是极其多余的。我怀疑许多软件工程师都犯了这个错误。选择一个指标，编写检测逻辑，并认为这就足够了。但是，使它变得危险的是文件的内容，而不是其名称、MIME 类型或幻数。现在我们已经清楚地了解了我们的对手，让我们谈谈我们如何从他们的监视中溜走。
Bypasses 绕过
As I mentioned, we will need to slip past the proxy, firewall, and browser controls to get our payload on the target’s system; however, for sake of example, let’s say the most restrictive of these controls is the corporate proxy. System administrators have fine tuned their proxy rules to block any attempts to download known malicious file types over HTTP and HTTPS. Similar rules apply to the other two, but it will help to focus on just one control for now.
正如我所提到的，我们需要绕过代理、防火墙和浏览器控件，才能在目标系统上获取有效负载;但是，举例来说，假设这些控件中限制性最强的是公司代理。系统管理员已微调其代理规则，以阻止任何通过 HTTP 和 HTTPS 下载已知恶意文件类型的尝试。类似的规则也适用于其他两个控件，但现在只关注一个控件会有所帮助。
Bypass 1 — Exceptions 绕过 1 — 例外
I told you that the proxy was going to block all malicious files, but were you really going to just take my word for it without testing? Tisk tisk! As mentioned earlier, there are tons of potentially malicious file types we can use. Some may be too obscure for network defenders to even know about. Others might need to be explicitly allowed because of a business need. Wouldn’t it cause problems for many companies if every Office document hosted on OneDrive was suddenly blocked? How long will our system administrators take the heat before they cave in and put in an exception? In practice, I have found these surprisingly often, so you might just get lucky.
我告诉过你，代理会阻止所有恶意文件，但你真的会不经测试就相信我的话吗？啪！如前所述，我们可以使用大量潜在的恶意文件类型。有些可能太晦涩难懂，网络防御者甚至不知道。由于业务需要，可能需要明确允许其他人。如果 OneDrive 上托管的每个 Office 文档突然被阻止，是否会给许多公司带来问题？我们的系统管理员在屈服并设置例外之前会承受多长时间？在实践中，我经常发现这些令人惊讶，所以你可能会很幸运。
Bypass 2 — Embed in HTML
绕过 2 — 嵌入 HTML 中
Did you know you can dynamically generate a blob of data in JavaScript, in the browser, and then use just JavaScript to “Download” the contents to a file? This is a totally legitimate feature for most browsers. For example, web developers might need a way to expose a button on a page to download the contents of a “table” element to a CSV file for the user.
您是否知道您可以在浏览器中用 JavaScript 动态生成一团数据，然后仅使用 JavaScript 将内容“下载”到文件中？对于大多数浏览器来说，这是一个完全合法的功能。例如，Web 开发人员可能需要一种方法来公开页面上的按钮，以便将“表”元素的内容下载到用户的 CSV 文件中。
We can use this same feature to download arbitrary file contents to arbitrary file names. What makes this technique so useful to us is that there is no separate call to the server to download the payload. We can slip the contents of our payload inside a ‘script’ tag in an HTML document like a Trojan horse. The proxy will only see the HTML document being downloaded, and not know it contains another malicious file inside it. This technique is known as “Embed in HTML’’ and there are several tools that can help us automate weaponization. Here’s one that I’ve used for years:
我们可以使用相同的功能将任意文件内容下载到任意文件名。这种技术对我们如此有用的原因在于，没有单独调用服务器来下载有效负载。我们可以像特洛伊木马一样将有效负载的内容放入 HTML 文档的“脚本”标签中。代理只会看到正在下载的 HTML 文档，而不知道它包含另一个恶意文件。这种技术被称为“嵌入HTML”，有几种工具可以帮助我们自动化武器化。这是我用了多年的一个：
https://github.com/Arno0x/EmbedInHTML
You might want to make a few tweaks so that you aren’t signatured based on the template, but the project is a great example of how to execute this attack well using encryption to further protect your payload.
你可能想要做一些调整，这样你就不会基于模板进行签名，但该项目是一个很好的例子，说明如何使用加密来进一步保护你的有效负载。
Bypass 3 — Password Protected ZIP
绕过 3 — 受密码保护的 ZIP
I have found that ZIP files are very commonly allowed in corporate environments. There are so many legitimate uses for ZIP that it would be prohibitive to block them outright. To account for potentially dangerous ZIP files, many security products will actually unzip the contents to see what’s inside before making a determination about whether it is safe.
我发现ZIP文件在企业环境中非常普遍。ZIP的合法用途如此之多，以至于完全阻止它们将是令人望而却步的。为了解决潜在的危险ZIP文件，许多安全产品实际上会解压缩内容以查看其中的内容，然后再确定它是否安全。
But what if they can’t open it? What if we include a password in our phishing email that the target will then use to open a password protected ZIP file? In most cases, the security product will not be able to properly vet the file, but will let the user download it anyway. I’ve used this technique with great success to slip all sorts of sketchy file types past corporate proxies.
但是，如果他们打不开怎么办？如果我们在网络钓鱼电子邮件中包含一个密码，然后目标将使用该密码来打开受密码保护的ZIP文件，该怎么办？在大多数情况下，安全产品将无法正确审查文件，但无论如何都会让用户下载它。我使用这种技术取得了巨大的成功，将各种粗略的文件类型滑过公司代理。
Bypass 4 — FTP and WebDAV
旁路 4 — FTP 和 WebDAV
Did you know that most browsers support FTP URLs? In our example of an extremely restrictive web proxy blocking downloads of HTTP and HTTPS, sending the user to an FTP share might slip past unnoticed. In addition, depending on how the proxy settings are being applied, they might not be enforced for explorer.exe visiting a WebDAV share. In that case, you might instruct a target to copy a UNC path and paste it into the file explorer.
您知道大多数浏览器都支持 FTP URL 吗？在我们的示例中，一个极其严格的 Web 代理阻止了 HTTP 和 HTTPS 的下载，将用户发送到 FTP 共享可能会被忽视。此外，根据代理设置的应用方式，访问 WebDAV 共享explorer.exe可能不会强制执行这些设置。在这种情况下，您可以指示目标复制 UNC 路径并将其粘贴到文件资源管理器中。
Bypass 5 — MIME Trickery
绕过 5 — MIME 诡计
Sometimes, we can get the receiving web browser to know the “real” payload type based on its MIME type, and spoof the file extension. A classic example of this is that Internet Explorer treats any file with the MIME type “application/hta” as an HTA file and will prompt the user to execute it. If our example proxy is blocking our “payload.hta” file based on the file extension, we can simply rename the file to “payload.pdf” while still specifying the HTTP header “Content-Type: application/hta” from our server.
有时，我们可以让接收 Web 浏览器根据其 MIME 类型知道“真实”有效负载类型，并欺骗文件扩展名。一个典型的例子是，Internet Explorer 将 MIME 类型为“application/hta”的任何文件视为 HTA 文件，并提示用户执行它。如果我们的示例代理根据文件扩展名阻止我们的“payload.hta”文件，我们可以简单地将文件重命名为“payload.pdf”，同时仍然从我们的服务器指定 HTTP 标头“Content-Type： application/hta”。
Bypass 6 — Change the Extension
绕过 6 — 更改扩展
Let’s say that you want to deliver a PowerShell script to stage your malware, but the proxy blocked PS1 files. What if we just put the script in a TXT file and ask the target user to change the file name for us? Along the same lines, you might add a nonsense extension to the file and then instruct the user that they will need to select an application to open it (e.g., PowerShell). Sure, it’s not quite as convenient as having them just double-click the file, but you might be surprised what additional requests we can tack onto our phishing message if we already have them on the hook.
假设你想要提供 PowerShell 脚本来暂存恶意软件，但代理阻止了 PS1 文件。如果我们只是将脚本放在 TXT 文件中并要求目标用户为我们更改文件名怎么办？同样，您可以向文件添加一个无意义的扩展名，然后指示用户他们需要选择一个应用程序来打开它（例如 PowerShell）。当然，这并不像让他们双击文件那么方便，但您可能会惊讶于如果我们已经将它们挂在钩子上，我们可以在网络钓鱼消息中附加哪些其他请求。
Bypass 7 — Magic Number Stomping
旁路 7 — 幻数踩踏
I’ve seen many cases where I’ve successfully delivered a stager written in Windows scripting utilities like PowerShell, VBA, JScript, etc. and seen a request from my stager to load the full payload, only to have the stager immediately die. What I found in several of these cases is that because I was staging a .NET assembly or other Windows executable, the download for my full payload was being signatured and blocked based on the first two bytes of the file. In this case, the “MZ” header that prepends all Windows EXE and DLL files. To get around this, a quick fix that has turned out to be really effective is just to remove those first two bytes from the file and then programmatically add them back using some logic in my stager.
我见过很多案例，我成功地交付了一个用 Windows 脚本实用程序（如 PowerShell、VBA、JScript 等）编写的暂存器，并看到我的暂存器请求加载完整的有效负载，结果暂存器立即死亡。在其中一些情况下，我发现，由于我正在暂存 .NET 程序集或其他 Windows 可执行文件，因此根据文件的前两个字节对完整有效负载的下载进行签名和阻止。在这种情况下，所有 Windows EXE 和 DLL 文件前面的“MZ”标头。为了解决这个问题，一个被证明非常有效的快速修复方法是从文件中删除前两个字节，然后使用我的 stager 中的一些逻辑以编程方式将它们添加回来。
Bypass 8 — Poison Existing Documents
绕过 8 — 毒害现有文档
Instead of trying to directly deliver payloads with our phishing campaign, what if we use CuddlePhish to first gain access to O365, Gmail, or Okta, and then abuse the target’s access to backdoor files we find on OneDrive, Teams, Google Drive, etc? If you aren’t familiar with CuddlePhish, it’s a tool we can use to bypass multi-factor authentication (MFA) while forcing phishing targets to log into services for us.
如果我们使用 CuddlePhish 首先获得对 O365、Gmail 或 Okta 的访问权限，然后滥用目标对我们在 OneDrive、Teams、Google Drive 等上找到的后门文件的访问权限，而不是尝试通过我们的网络钓鱼活动直接传递有效负载，该怎么办？如果您不熟悉 CuddlePhish，我们可以使用它来绕过多因素身份验证 （MFA），同时强制网络钓鱼目标为我们登录服务。
The point here is that instead of delivering payloads from our phishing site, we target access to the places where we expect our target organization is storing and sharing documents. You could even take this a step further and use access to Outlook webmail and Teams to message other employees at the target organization and prompt them to “review your changes” to your poisoned documents.
这里的重点是，我们不是从我们的网络钓鱼站点提供有效载荷，而是将访问目标组织存储和共享文档的地方作为目标。您甚至可以更进一步，使用对 Outlook 网络邮件和 Teams 的访问权限向目标组织的其他员工发送消息，并提示他们“查看对中毒文档的更改”。
Addressing the Whale in the Boat: A.K.A. Mark of the Web
解决船上的鲸鱼：又名网络标志
Many red teamers get discouraged by the mark of the web (MOTW) and treat it like it’s a death sentence for any payload they wish to deliver during phishing. I have to say that this is simply not the case. I think it’s very rarely the MOTW that is the last nail in the coffin for phishing payloads. For one, I know of at least two MOTW bypasses that still work (sorry, but I’m not sharing those at this time), so I know there are bound to be more. If you dig around, then I’m sure you can find one.
许多红队成员对网络标记 （MOTW） 感到气馁，并将其视为他们希望在网络钓鱼期间交付的任何有效载荷的死刑判决。我不得不说，事实并非如此。我认为 MOTW 很少是网络钓鱼有效载荷棺材上的最后一颗钉子。首先，我知道至少有两个 MOTW 旁路仍然有效（对不起，但我目前不分享这些），所以我知道肯定会有更多。如果你四处挖掘，那么我相信你能找到一个。
Secondly, MOTW doesn’t always mean your payload is belly-up and dead in the water. For many file types, it just adds another annoying prompt or two to make sure the user really wants to “keep” and “open” the sketchy file.
其次，MOTW 并不总是意味着您的有效载荷肚皮朝上并死在水中。对于许多文件类型，它只是添加了另一个或两个烦人的提示，以确保用户真的想要“保留”和“打开”粗略的文件。
Finally, you can always just ask your target to right-click on the file, select “Properties”, and check the “Unblock” button:
最后，您可以随时要求您的目标右键单击文件，选择“属性”，然后选中“取消阻止”按钮：
It really is that easy! Keep in mind that this is the absolute most difficult MOTW bypass out there and it’s not that hard. Most users will be willing and able to perform this bypass for you.
真的就是这么简单！请记住，这绝对是最困难的 MOTW 旁路，而且并不难。大多数用户都愿意并且能够为您执行此旁路。
In Conclusion 综上所述
Proxies, firewalls, and browsers are going to try to block sketchy files and that can really take the wind out of our sails when trying to deliver payloads with phishing. Luckily, we have options, somewhere in the range of dozens to hundreds of options, so it’s unlikely that every single potentially malicious file type is blocked. In addition, most security products only block file types based on attributes that we can control. Therefore, we have several tricks we can use to potentially bypass them. Worst case scenario, we just need a little extra social engineering to get our targets to make a file modification before opening/running our payload.
代理、防火墙和浏览器将尝试阻止粗略的文件，这在尝试通过网络钓鱼传递有效载荷时确实会让我们大吃一惊。幸运的是，我们有数十到数百个选项的选项，因此不太可能阻止每个潜在的恶意文件类型。此外，大多数安全产品仅根据我们可以控制的属性阻止文件类型。因此，我们可以使用一些技巧来潜在地绕过它们。最坏的情况是，我们只需要一些额外的社会工程来让我们的目标在打开/运行我们的有效负载之前进行文件修改。
And remember! Phish are friends, not food…
记住！网络钓鱼是朋友，不是食物……
原文始发于Forrest Kasler：Phish Out of Water
相关文章
