1.APT案例分析：一个基于Meterpreter和Windows代理的取源取hp请求攻击事件

APT案例分析：一个基于Meterpreter和Windows代理的攻击事件

       前言

       在深入研究此APT攻击案例前，需先了解测试环境。码获我对其进行了定制化的取源取hp请求模拟APT攻击，发现可以上传HTTPS返回类型的码获Meterpreter后门至只可通过代理访问的公司Windows网络中。最初，取源取hp请求我并未确定此情况是码获偷相册网站源码否存在漏洞或对APT攻击的影响。因此，取源取hp请求我需要确保代理环境的码获正确性。

       在详细分析后，取源取hp请求我们使用的码获Meterpreter模块（windows/meterpreter/reverse_https）并未成功。以下介绍攻击过程分析：

       攻击过程分析

       为解决此问题，取源取hp请求我修改了Meterpreter攻击载荷代码，码获并在被攻击靶机中测试。取源取hp请求此过程需要产生HTTPS类型或使用其他Meterpreter后门源码。码获例如，取源取hp请求可通过shellter或任何受信任软件如putty.exe生成简单后门，或使用powershell生成web协议模块的Meterpreter后门。

       靶机中执行后门软件并监听后门程序，观察连接情况。下图展示了攻击机中在端口执行的侦听，连接后未执行命令。网站攻击地图源码

       攻击机已反向连接回我们的侦听机器，获得一个Meterpreter shell。然而，此shell无法执行任何命令，会话随即结束。从高层次来看，后门成功执行第一阶段，通过代理反弹至攻击者机器，但在第二阶段注入过程中可能出错，导致命令执行失败及会话中断。mycat 源码 目录结构

       我手动创建PEM证书，配置监听器，比较浏览器上观察的指纹与创建的证书指纹，确认证书传输过程未被替换。这促使我继续寻找问题所在。

       嗅探网络流量以了解第二阶段发生的情况。下图展示了靶机与代理服务器间的TCP流量通信。

       流量显示靶机（.x.x.）与代理服务器（.x.x.:）间的通信，包括靶机发送至攻击机（.x.x.x:）的安全连接请求。NTLM身份验证与响应表明握手成功。2017最新icloud源码

       在部署Meterpreter第一部分无误后，问题出在第二部分，即攻击载荷与msf侦听之间的通信。继续分析网络流量以找到答案。

       下图展示了第一阶段攻击载荷与msf侦听之间的通信，以及靶机不使用代理直接与攻击机进行通信的情况。

       分析显示，在使用代理时，Meterpreter会话中断，原因在于第二阶段的html转pdf源码后门载荷无法返回到msf的侦听中。下载Meterpreter源代码，查找问题根本原因。

       在Meterpreter源代码中，存在使用WinHTTP Windows API的逻辑实现。调试源代码，修改DEBUGTRACE预处理常量，以便在运行过程中提供调试信息。

       通过运行后门并在靶机上运行DebugView工具，获取调试信息。信息显示，后门尝试使用AutoDetect代理设置，但未获得代理地址，请求发送失败。

       分析源代码后发现，问题出在处理Windows代理设置的代码块。修改代码以考虑通过DHCP或DNS获取代理。重新运行后门，发现使用Auto detect时，Meterpreter能执行命令。

       总结与建议

       在某些情况下，我们可能遇到工具无法正常工作的问题。解决方法包括使用其他方法进行攻击或修复问题。修复了生成的dll代码后，我们可以在特定企业环境中进行攻击。然而，修复代码是否被msf采纳尚不可知，但此经验适用于遇到类似问题时的修复方法。

       我们了解到Windows代理配置有特定顺序，一旦获取代理设置，无论其是否有效，系统都会使用它。此外，IE与火狐浏览器在系统代理设置下表现出不同行为。在某些情况下，即使代理无法工作，也不会使用其他配置。

       编写代码测试代理配置是否允许进入网络，可以增加APT攻击成功的机会。然而，应考虑到特殊环境的限制，管理员通常不会在测试环境中使用此类设置。

       最终结论是，确保APT攻击方案的连接成功可能性与IE相似，即可在大多数环境中成功执行攻击。如果IE能访问网络，APT攻击同样能成功。