用powershell下载文件的姿势你研究过吗？
PowerShell 的最大优势在于以 .NET 框架为基础。 .NET 框架在脚本领域几乎是无所不能，这是一个优点，也有可能成为一个方便黑客攻击的一个强大的便利。
在渗透测试中，在正常的传输通道被禁止时，我们时常会剑走偏锋，通过一些特殊的方法来进行文件的传输。这篇文章将会描述使用 PowerShell 下载文件的三种方法，并评估它们的优缺点。
关于其他在 windows 系统下通过命令行上传文件的姿势，请查看前文：
测试环境
本次测试的目的在于展示执行时间和性能的区别。
测试环境主要是 Windows 10（x64） 的 PowerShell 5 和下载速度约为 3mb/s 的无线网络连接。
我将从我自己的服务器上
http://123.206.200.87/PassWord2.txt
下载一个测试文件 PassWord2.txt ,文件大小为 25.45MB ，服务器公网带宽 1Mbps 。我们会测试脚本 10 次并取平均值作为结果。
让我们开始吧！
1.Invoke-WebRequest
说到使用 PowerShell 下载文件，最先想到的就是 Invoke-WebRequest 命令。可能你有点不熟悉这个名字，它有 3 个别名，分别是 “iwr”、“wget”、“curl”。
平均用时：3分28秒
优点
这个方法非常容易上手。如果你知道文件总的大小的话，结合 Write-Progress 命令你可以很方便得看到脚本的运行进度。Cookie 也可以通过使用 -Session 和 -WebSession 参数在多个请求之间保留。
缺点
使用这个命令下载文件的速度很慢。我观察到 HTTP 响应流先全部缓存到了内存中，一旦文件全部传输完毕，文件就会从内存中一下子转移到磁盘中。如果你要下载一个大文件，那么这种方式会造成巨大的性能问题和内存的损耗。如果有人知道这个命令的具体操作细节，请告诉我！我们可以一起讨论一下。
这种方法的另一个潜在的严重缺点是依赖 Internet Explorer 。比如，这个命令不能运行在 Windows Server core 版本的服务器上，因为它默认不包含 Internet Explorer 二进制文件。在这种情况下，你可以使用 -UseBasicParsing 参数，但它并不是在所有情况下都起作用。另外我在这里给出两个让 Invoke-WebResquest 提速的方法。
第一，使用 $ProgressPreference='silentlycontinue' 语句来隐藏滚动条，减小了资源的占用。
第二，就是使用上面提到的 -UseBasicParsing 参数，这样在 Invoke-WebRequest 请求完数据后，就不会调用 IE 去进行 DOM 树结果的解析，效率会提高不少。
结论
当你需要在多个请求时保留 Cookie（例如下载文件之前的 HTTP 表单验证），那么这个命令会很有用。
这种方法很适合用来下载小文件，但是如果你对下载速度有要求，那肯定会有更好的选择。如果这个脚本要运行在 Windows Server Core 版本的服务器上，那这个命令就不适用了。
2.System.Net.WebClient
.NET 框架中的 System.Net.WebClient 类就是一个用于下载文件的 .NET 类。
平均用时：3分28秒
优点
这个方法用起来也很简单。这种方法的下载速度跟上一种差不多，在整个下载过程中 HTTP 响应流被直接缓存到了磁盘中。
你还可以用 System.Net.WebClient.DownloadFileAsync() 这个函数。可以很方便地在文件并行下载的同时继续运行脚本。
缺点
没有一个下载进度条（或者任何能查询下载进度的东西），也就是说你无法知道到底还要多久才能下载完成，也不知道目前到底下载了多少。并且这个命令是单线程的，所以会造成线程阻塞，只能一个下载任务完成了才能进行下一个任务。
结论
当需要下载文件时，System.Net.WebClient 是我的最佳选择。这个方法也是完全兼容 Windows Server Core 版本的服务器。
3. Start-BitsTransfer
如果你在之前没听说过后台智能传输服务（BITS） 参考文档:
https://msdn.microsoft.com/en-us/library/aa362708.aspx
BITS 主要用于 Windows 系统的升级、自动更新等工作。工作方式为异步下载文件，并且用于同步下载文件时也有十分优异的表现。还有一个BitsAdmin 工具使用的也是这个后台智能传输服务。
平均用时：3分33秒
优点
集成了进度条可以让我们清楚的了解文件的下载进度。-Asynchronous 参数可用于异步传输队列。异步就意味着无需等待上一个任务完成即可执行下一个任务，多个命令可以并行执行。虽然在单任务状态下较慢，但在多任务的情况下能提高效率。
就个人而言，使用这个方法最大的优势是能够在失败的时候进行重试操作并限制可用于传输的带宽量。
缺点
这个方法是我测试到现在最慢的方法！但是和其他两个方法来比慢的也不太多。另外，虽然 BITS 在许多机器上默认可用，但是你不能保证在所有的机器上都可以使用 BITS ，除非你在你的机器上确保已经开启了 BITS 。还有，由于 BITS 主要用于异步传输的特性，如果别的 BITS 任务正在后台运行，那么你的任务就会被加入队列或者在片刻后再执行，这就会阻碍你的脚本的执行。
总结
在你想限制文件下载的带宽或者不太考虑下载时间的情况下，这种方法是最完美的。得益于这种特性，我设置了一种夜间全速下载、白天半速下载的策略。并且 BITS 也易于观察下载的进度。
总得来说
我推荐使用 System.Net.WebClient 这种方法，因为它比较通用，下载速度也比较快。BITS 是我的第二个选择因为它的灵活性和易于管理。
在渗透测试中，利用系统自带的一些工具进行攻击是一种不错的方法。而 PowerShell 就是一把利器，由于它过于强大，很多系统管理员会直接禁用它，并且在 Windows 系统中，也是默认禁止 *.ps1 脚本文件的执行的。所以呢我们需要在执行 ps 脚本的时候绕过一下这个默认的策略。最简单的方法就是执行 powershell.exe 附加需要执行的命令，也可以将要执行的脚本直接复制进 powershell 的窗口。
在执行 ps1 脚本文件的时候加上一个 Bypass 参数就可以很简单地绕过了。例如：
PowerShell.exe -ExecutionPolicy Bypass -File .\t1.ps1
如果你知道其他的方法，请告诉我哦。
个人作品展
作者简介
作者目前位于移动支付之城—杭州。就读于浙江水利水电学院。之前在学校的东旭工作室做的是网站的前端（FE）,后来从工作室出来，和小伙伴一起创办了红枫信安协会，踏上了信息安全之旅。平时偶尔喜欢玩玩游戏，爱 RNG，爱 UZI。
下面呢和大家分享一下我在信安方面的心路历程。
首先呢，带我入门的还是东旭工作室，在工作室里学到了很多基础的东西。比如一个网站的建设过程、整体架构，然后还有编程能力的提升等等。
但是呢，在学的过程中发现了一些安全性的问题。比如在一次工作室的庆祝圣诞活动页面上，有一个留言板。于是想到那时候刚学的 js，就写了一段 js 提交上去，然后所有人的浏览器上都弹了窗... 一段时间以后才知道原来这就是 xss …后来从工作室出来，闲了一段时间，听学姐推荐说去考一个软考，以后毕业找工作多一个证书好找点。然后就去考了中级的信安工程师。
在备考期间发现信息安全好有趣呀，精巧的密码学设计，刺激的中间人攻击，复杂又不失优雅的认证协议…… 还有很多很多有趣的技术。
后来又接触到了 CTF 比赛，跟红枫信安的小伙伴一起去玩玩 CTF，很刺激很开心。最后希望能和有相同爱好的各位在信安之路上越走越远。想跟作者成为朋友吗？那就加群吧！