企业官网建设流程全解析

我直接说一句大实话：网上把渗透测试讲得神乎其神的文章一大堆，但真正能让你照着走完一遍完整流程的内容，少得可怜。大部分要么只讲单个工具的花式用法，要么就是堆漏洞名字号称“实战”，结果连先扫端口还是先扒子域名都说不清楚。这篇文章不整虚的，我就按“信息收集→漏洞利用→提权→维持权限→写报告”这条主线，把标准渗透测试里每个阶段要干什么、为什么这么干、容易在哪翻车，掰开了讲清楚。

内容不会像教科书那么端，也不会只丢命令让你自己猜。每一步我会带上判断依据、常见坑点，还有我平时测试时习惯保留的检查项和记录习惯。部分实操命令以常见开源工具和经典场景为例，版本不同的系统结果会有差异，但思路是通用的。先说明一点：整篇文章的前提是你在获得合法授权的前提下开展测试，没有目标书面授权的所谓“测试”，性质就是入侵，别碰。

1. 信息收集：千万别急着上手扫漏洞

很多人做渗透有个毛病，拿到目标就开扫，nmap一把梭，全端口跑完发现没东西就说“目标很安全”。这不是测试，这是碰运气。信息收集是渗透测试的地基，地基没夯实，后面打不打得进去全靠命。

1.1 被动信息收集：不碰目标也能拿到的情报

被动信息收集指的是在整个过程中不直接与目标系统产生交互的情况下获取信息，主要靠搜索引擎、证书透明日志、DNS记录、历史泄露数据库这类公开来源。为什么先做被动？因为它最隐蔽、零风险，还能帮你画出目标的第一张轮廓图。

我自己常用的动作包括这么几项：

• ICP备案查询：国内的目标站点，先查备案主体，能直接关联出同一主体下的其他域名，攻击面一下就扩大了。
• 子域名枚举：用oneforall或者subfinder跑一遍常见子域名字典，再配合证书透明度日志（crt.sh、censys）做交叉验证。很多核心业务的测试入口，往往藏在test.xxx.com或者old.xxx.com这种子域里。
• 端口服务指纹：这一步虽然会直接连目标，但从“是否主动攻击”的角度看仍属于低风险探测。拿nmap做一次基础识别，看看开放了哪些端口、跑的是什么服务，心里先有个底。
• 员工信息收集：github托管的代码、社交平台发布的技术分享、招聘网站的JD，都是信息泄露的高发地。

被动阶段要输出什么？一张目标信息汇总表，域名、IP段、业务系统清单、技术栈、关键联系人，全部梳理成结构化的记录。我习惯用Markdown表格记录，每条信息后面标注来源，方便追溯。

1.2 主动信息收集：开始触碰目标边界

被动阶段做够了，会进入主动探测。这时候流量会直接发到目标系统，一定要控制速率和频率，避免影响业务稳定性。

主动收集的核心动作是两个维度的探测：

第一是全端口扫描。nmap默认只扫1000个常用端口，这远远不够。我的扫描习惯是先做全端口发现，再对开放端口做服务版本识别。用nmap -sS -sV -O -p-可以拿到开放端口、服务版本和操作系统指纹，但全端口扫描耗时长、流量特征明显，建议在授权明确的情况下设定合理速率执行。

第二是Web应用资产梳理。端口探测完，凡是开了80或443的都要做Web层面的信息收集，包括：

• 首页和常见目录的指纹识别（用什么CMS、什么中间件、什么框架）
• 敏感目录和备份文件探测
• 登录接口、API接口、上传功能的梳理

这里我常用dirsearch配合-x参数排除静态资源后缀，再把跑出来的目录结果结合状态码和响应长度过滤一遍。响应长度特别长的页面往往是目录列表或未授权访问点。

1.3 资产测绘阶段最容易忘的三件事

每次带新人做测试，我发现他们信息收集阶段最容易犯三个错误：

一是只盯主域名，忽略IP段内其他资产。很多公司主站做得固若金汤，但同网段的shopping.xxx.com是个五年前的老项目，漏洞一堆。二是收集结果没有结构化管理，凭脑子记。等你测到第三个系统，前面发现的信息早就混成一锅粥，写报告时更是找不到依据。三是忘了做技术栈全量梳理。框架、组件、中间件版本不确认清楚，到了漏洞利用阶段就没法精准选POC。

信息收集是唯一值得花整个测试周期40%时间的阶段。前期多花一小时整理资产，后期可能少熬两个通宵。

2. 漏洞利用：从“能连”到“能打”的关键一跳

信息收集做完，手里有一堆资产，下一步是找到突破口。漏洞利用阶段最关键的不是工具跑得多溜，而是能不能准确判断哪个点试起来性价比最高，以及拿到初步权限后该怎么走。

2.1 常见漏洞类型快速复盘

根据我这些年测试的经验，排名靠前的高频入口类型大概是这几种：

• 未授权访问：比如Redis、MongoDB、Elasticsearch这类组件对外开放且无认证。过去有段时间我们做红队项目，只要扫到6379端口开放，没有密码，基本就等于拿到一台主机了。
• 远程代码执行：典型的像Java系反序列化（Fastjson、Shiro、Log4j2）、Struts2系列漏洞、老版本WebLogic的XMLDecoder反序列化等。
• SQL注入：现在纯手工注人越来越少，但参数化的漏网之鱼依然存在，一旦存在往往直接就是高权限数据库连接。
• 文件上传：能传WebShell就能getshell，是攻击链中最直接的一环。
• 越权与逻辑漏洞：水平越权、垂直越权、验证码绕过、支付逻辑漏洞，这类问题在业务系统里出现频率极高。

测试时不要拘泥于某种漏洞类型，要从“这个系统是什么技术栈、什么功能模块、什么网络位置”去倒推该重点测什么方向。

2.2 漏洞利用工具链的选择逻辑

工具选型是整个利用阶段最有意思的部分。巧了，热词里还提到“java反序列化漏洞利用工具v1.7.jar”，这类专用工具网上不少见，但我建议先搞懂底层链路再上工具，否则纯黑盒打，改了payload格式就抓瞎。

我的原则是：能用现成脚本就用现成脚本，但要能读懂脚本在干什么。比如Fastjson的利用过程，本质是反序列化时通过@type指定的类触发getter/setter中的危险调用链，工具只是帮你把这段调用链的构造自动化了。拿到一个目标，要么是已知CVE直接套POC，要么是未知风险靠指纹识别加fuzz。这是两条完全不同的技术路线。

Burp Suite是Web端测试绕不开的枢纽，抓包改包、重放对比、Intruder跑参数，外加各种漏洞插件，几乎能覆盖Web层面所有手工操作的需求。而到了主机层，sqlmap负责自动化注入，蚁剑和冰蝎管WebShell连接。蚁剑怎么提权也是热词里的问题，说实话蚁剑本身的提权能力很弱，它的价值在于帮你把WebShell转换成命令执行通道，真正的提权动作你还是得在终端里手动做。具体怎么做，放到下一章讲。

2.3 漏洞利用成功之后，先别急着高兴

拿到WebShell或者命令执行权限，很多新手第一反应是赶紧开个反弹Shell，生怕权限掉了。但真正的老手会先稳住，保持探测状态，搞清楚三个问题：

• 当前进程的身份是什么？是Web服务账户、普通用户，还是已经是高权限？
• 当前这台机器在目标内网里扮演什么角色？是单点Web服务器，还是连着内部数据库或云元数据接口？
• 有没有杀软/安全防护在监听动作？反弹Shell的流量过不过得了防火墙？

这一步做得好不好，直接决定下一次提权操作会不会还没开始就被拦截。

举个例子，拿到WebShell后用whoami看身份是www-data，再用ipconfig或ifconfig看网卡信息，发现机器连着内网网段，这时候正确的选择是先做内网探测，确认找得到数据库或域控再考虑提权，而不是先折腾本地权限。如果目标机器只是DMZ区的一台孤零零的Web服务器，提权到root之后能做的事其实也有限，倒不如把权限保留住，换条路径打进内网核心区。

3. 提权：从普通用户到管理员的距离

提权是整个渗透测试里最考验功力的阶段，因为漏洞利用往往有公开可利用的路径可循，而提权更多依赖对目标系统配置的熟悉程度和临场判断。

3.1 Windows提权的主流思路

Windows提权，核心可以分成两条线：一是想办法借系统自身机制漏洞，做本地权限提升；二是翻找目标机器上的敏感信息，拿到管理员凭据。

内核漏洞提权是思路之一。常见的有PrintNightmare、JuicyPotato（针对Windows服务账户的SeImpersonate权限）、土豆家族后续变种，以及各种补丁没打齐的老系统。这类利用方式通常需要上传利用程序到目标机器执行，所以能不能成功，防火墙和杀软的态度占一半。我倾向于先用systeminfo拉取系统版本和补丁列表，再对照公开提权EXP清单筛选能被当前系统命中的漏洞，而不是每个漏洞都跑一遍。

服务配置错误也是一条容易走的路。重点检查注册表AlwaysInstallElevated项是否开启，开启后会以高权限执行任意MSI安装包；检查服务路径是否被第三方用户可以写入；检查计划任务是否有替换执行文件的可能。

在翻找信息方面，管理员经常会把密码存在脚本文件、配置文件、数据库连接串里。遍历一遍桌面、文档目录、IIS目录、备份文件夹，往往比跑内核漏洞更省力。PowerShell的Get-ChildItem搭配findstr做关键字递归查询，效率非常高。

3.2 Linux提权的几条经典路径

Linux提权常规动作里，SUID提权是绕不开的。系统上存在设置了SUID位的可执行文件时，普通用户运行它会暂时获得文件属主的权限。用find / -perm -4000 -type f 2>/dev/null能把这类文件列出来，然后挨个检查是否有已知提权利用方式。比较经典的比如自带的find命令可以直接通过-exec参数执行命令，Python、Perl等解释器带着SUID位更是直接可以起一个高权限shell。

sudo配置错误是另一条高频路径。测试第一件事永远是看当前用户能不能执行sudo -l，很多时候管理员图省事，给某位用户所有命令免密sudo权限，又或者sudo条目里写了python、vim这类可以逃逸到shell的命令。

内核漏洞提权也不是没有，脏牛（Dirty COW）系列以及各种竞态条件提权漏洞，网上有大把已编译好的利用程序。但内核提权风险大，容易搞挂系统，我的建议是“非必要不尝试”，优先找配置问题，实在没招了，备份好现场再动。

还有一个容易被忽略的：内网渗透的常见跳板——Docker组。当前用户如果属于docker组，直接挂载宿主机根目录到容器里，然后修改/etc/passwd或者读ssh私钥，宿主机权限基本就到手了。很多人目标机器上没找到突破口，是因为只盯着“如何直接拿root”，而忘了通过sudo、docker组这些旁路跳过去。

3.3 提权失败之后的备选方案

提权不一定一次成功，也别死磕同一台机器。我的经验是，如果这台机器上花了半小时还没有实质进展，先放一放，回到信息收集阶段，寻找同网段其他目标。有时候你在这台机器上是个普通用户，但在同一内网的另一台机器上，你有写入或重启权限，通过计划任务就能完美实现权限跨越。

备选方案通常还包括：

• 横向移动：用当前账户凭据尝试登录同一凭据复用的其他主机，很多企业内网一套密码走遍天下。
• 收集凭据再战：抓取内存中明文密码或哈希，本地密码库导出，WiFi密码，浏览器保存的密码，这些都是提权的有效原料。
• 改变打法：这台机器是Windows，也许提权难度大，但这台Web应用连接的后端数据库可能是Linux主机，先通过数据库拿Linux权限，再反过来通过共享存储或管理通道绕回Windows。

“提权”阶段真正考验的不是技巧，而是耐心和系统性思考。

4. 维持权限与痕迹清理：测试周期内的高质量立足点

很多初学者一听“维持权限”就以为是留后门、种木马。在这里必须强调：在标准、合规的渗透测试项目里，稳定的立足点是为了完成测试周期内的内网横向、数据验证和报告复现，测试结束后所有驻留手段必须清除，系统配置恢复到初始状态。

4.1 稳定的权限维持手段

在测试周期内维持权限，需要考虑的是两点：一是权限别掉，二是动作别被安全设备盯上。

最基本最常用的方式包括：

• WebShell维持：上传加密流量的WebShell，比如蚁剑的php木马混淆变种、冰蝎的二进制传输，配合自定义UA头或动态密钥，在Web层面的隐蔽性会好很多。
• SSH公钥植入：只要能往目标Linux系统的~/.ssh/authorized_keys里写入自己的公钥，后续就可以通过SSH直接登录，相对稳定且不易被杀软查杀。
• 计划任务定时回连：在Linux的crontab里写一个定时任务，定期从C2服务器拉取指令；Windows同理，设置计划任务，以系统权限运行。
• 端口转发与隧道：拿到一台边界机器权限后，用frp、nps、ssh隧道之类的工具打通内网通道，方便后续访问内网横向区域。

4.2 穿行内网时怎么少留痕迹

在目标内网横向移动时，系统日志、登录日志、文件访问记录都可能留下痕迹。合规视角下我们并不刻意对抗防御方的审计，但项目中常见的实际情况是，测试团队不希望因自己被蓝队溯源成功而中断授权测试。所以，规范的团队通常会选择高频操作的“低频化”处理：减少扫描频率、把批量爆破限制在严谨阈值内、使用加密隧道传输数据。

我自己的习惯是，只清除因测试动作产生的日志条目，不破坏原始日志，以免影响客户追溯真实攻击。比如Windows的登录成功事件、PowerShell执行脚本的日志，Linux的/var/log/auth.log和/var/log/lastlog，都尽量保留原始，最多在测试结束后统一交给客户由他们自行处理。

4.3 维持权限阶段必须想清楚的事

维持权限不是目的，是手段。你要时刻问自己一个问题：我留这个权限，后续要做什么？如果答案只是为了证明“我可以留后门”，那这个动作毫无价值，反而增加了责任风险。正确的逻辑是，比如你通过它拿到了域管哈希，后续要验证的是域管哈希能不能通杀全网段主机；或者你通过它访问到财务系统数据库，后续要验证的是财务分库的隔离是否有效。权限存在的意义在于帮助你完成这些验证，而不是表演“我能在这里待很久”。

还有一个原则：能用稳定通道不用高危通道，能用加密流量不用明文。SSH隧道能解决的，绝不额外开放端口；C2通信能用HTTPS就不要自定义协议，否则在流量审计里一眼就被识别出异常。

5. 写报告：测试做得好，不如报告写得清

报告是整个渗透测试项目的最终交付物。但我见过太多团队，前面测试做得漂漂亮亮，报告却是把漏洞扫描器的结果直接导出附上，客户看完一头雾水。这种报告没有任何价值，甚至会让客户质疑你整个测试的专业度。

5.1 一份高质量渗透测试报告的结构

我习惯用这样一个结构来组织渗透测试报告：

• 项目概述：说明测试范围、测试周期、授权依据、测试方式（黑盒/白盒/灰盒）、整体安全态势摘要。
• 漏洞统计汇总：按漏洞等级、漏洞类型、涉及系统/模块三个维度做汇总统计，先给管理者一个全局视角。
• 漏洞详情：每个漏洞独立成节，包含基本信息（等级、类型、位置、漏洞地址）、漏洞描述（说明该漏洞的本质和成因）、复现步骤（一步步怎么触发，附带关键请求包和响应包）、影响范围（这个漏洞能被利用到哪一步、能拿什么权限）、修复建议（分短期临时处置和长期根治方案）。
• 加固建议汇总：按“高危优先，低危可选”的原则，把漏洞修复建议和提升整体安全性的加固项列成表单。
• 复测计划：说明修复完成后的复测时间范围和方法。

5.2 漏洞定级怎么做才不会背锅

漏洞定级不是拍脑袋，行业内普遍参考CVSS（通用漏洞评分系统）的三项大维度、若干子维度做量化打分，常见的定级标准包括：

• 高危：可远程未授权直接拿到系统权限或核心数据，比如RCE、SQL注入直连数据库、任意文件上传getshell。
• 中危：可利用但前置条件较多，或者能拿到部分敏感信息，比如注入需登录、越权只能访问普通用户数据。
• 低危：暴露的信息敏感度低，或利用条件苛刻，比如目录枚举、版本信息泄露。

具体等级划分要结合业务场景，同一个漏洞在不同行业定级可能天差地别。比如用户枚举漏洞，在电商平台可能算低危，但在政务系统可能就是中危甚至高危，因为它会成为撞库和社工攻击的帮凶。

5.3 写报告时的重点误区

第一个误区是只列漏洞不写危害。很多新手写“发现SQL注入”，然后就没了。但客户真正关心的是“我的数据库会不会被脱走”。写清楚这条注入能被脱哪几张表、里面有没有身份证手机号、能不能进后台，比堆十个漏洞都管用。

第二个误区是复现步骤描述不够细。我要求报告的复现步骤必须是“换个新人照着步骤能100%复现”，包括使用的工具及版本、构造的请求包原文、返回的响应特征。代码和流量截图必不可少，有条件的还要贴上抓包导出的请求文件。

第三个误区是修复建议写得很虚。像“加强访问控制”“升级组件”这种叫废话。要写就写具体方案：这条Redis未授权访问，修复的第一步是在配置文件中将protected-mode设置为yes，第二步是bind内网地址并设置requirepass强密码，第三步是在防火墙层限制6379端口的访问源IP；不能设置密码的，还要建议改用Unix socket验证方案。这种程度才算一次能落地的修复建议。

6. 关于整个流程，最后说几句真心话

这些年在授权测试这个圈子里，从一线打工人做到带团队，最大的一个感受是：渗透测试不是炫技的擂台，而是一场带着“已知目标”打“未知路径”的解题游戏。你能走通一条从信息收集到写报告的完整链路，才算是真正理解了这台设备、这套网络和这家企业的安全短板究竟长在哪。

很多新人刚入行时，眼里只盯着一夜打穿大厂的传奇故事，却不愿意花时间做最基础的资产梳理，不愿意记录每条操作日志，不重视报告排版和表达。但恰恰是这些“不酷”的动作，决定了一个安全工程师能走多远。这里没有捷径，也没有一劳永逸的工具，花在底层原理上的时间，会在某个毫无头绪的深夜里变成你脑中的灵光一闪。

如果你正打算往这个方向深入学习，我的建议是先在靶场把流程跑通十遍以上。Vulhub、DC系列靶机、HackTheBox、内网靶场环境，怎么折腾都不过分。等你在靶场里能把信息收集的节奏、提权的判断逻辑、报告的结构都内化成肌肉记忆，再去找合法的众测项目练手，你会发现自己突然就“开窍”了。

最后再送大家一条实操习惯：每次测试结束，把自己这次踩过的坑和快速成功的路径更新到自己的笔记里。一年之后回头看，那本笔记的价值，远超你收藏夹里吃灰的几百份教程。