在渗透测试过程中，我们可以通过插件识别类型后，使用漏洞脚本对特定系统进行模糊。在

这里，笔者将与大家分享漏洞POC验证系统的设计和研究思路。在系统开发之初，选用了分布

式平台设计架构。后来因为考虑到与分布式资产扫描平台兼容的接口，最后理解了耦合，彻底

变成了单机版。

 

 

首先我们可以看到这个地方没有单独设计web管理端，只能通过命令行调度。但是，在设计中

，守护进程restapi是保留的，它可以接受来自第三方平台的调度请求。插件模块调用方面，主

要有三个模块:流行的漏洞插件，主要用于重现常见的手工测试方法和一些团队发现的内部漏

洞。密码漏洞插件:主要包括端口、中间件、未授权应用和弱密码漏洞，包括弱密码字典。第

三方漏洞插件:主要用于访问互联网上的一些开源和泄露的插件，用于结果集成和性能调优。

 

 

获取目标信息时，主要有以下几种形式:Api调度:第三方平台通过rpc传输目标信息来调度系统

的api。命令行调度:通过命令行参数传递目标信息，直接进行调度。资产导入调度:通过访问

接口调度并扫描第三方平台api给出的数据。在分布式资产扫描平台本身，有一个cms类别和

应用程序类型信息的存储库。然而，为了考虑内部网的情况，分别提取了两个子模块:Cms认

证插件:主要是对目标的cms类型进行认证。如果目标与本地指纹数据库匹配，它将被标记，

否则它将访问internet查询界面。应用识别插件:主要是补充cms类型，识别服务和应用的类

型，标注为第二梯队。当然，除了这些模块，还有一些小效果优化插件，这里就不多说了。

 

 

最后简单说一下扫描结果落入数据库的问题。这里选用日志打印存储+数据库返回的分布

式资产扫描平台，可以关闭返回选项，保证了本系统在恶劣环境下的兼容性。当扫描内部

网系统或带有敏感防火墙的系统时，我们可以支持访问多种类型的代理。速率控制，检测

敏感服务器时，第三方插件可能带来的密码认证爆破机制会比较粗糙。要么是单线程转，

要么是大范围的线程池，很容易让服务器失效，或者让IDS很快发现。因此，对于这个块

的控制，我们需要进行详细的优化，选用动态速率控制的策略，而不是硬编码来配置和分

配任务。

 

 

对于第三方插件，我们在统一调度机制和库文件上花了不少功夫，还有一个关键点就是

掉包库的格式。在各种插件的上报过程中，我们会尽量为第三方插件挂接数据上报层，

统一格式后上报。但是，并不是每种插件都有一个统一的将记录放入库中的过程，可能

需要为这种插件重写函数。目前我们的插件都是点击式的。为了符合法律法规层面的制

度，我们没有深挖漏洞，需要手工使用和审核。