企业官网建设流程全解析

1. 项目概述：一次真实的内部网络渗透测试复盘

最近刚结束一个内部网络的安全评估项目，客户是一家中型规模的科技公司，他们对自己的办公网络环境一直挺有信心，觉得有防火墙、杀毒软件就万事大吉了。直到我们拿到授权，进行了一次模拟真实攻击者的渗透测试，才发现从外部到内部核心服务器的路径，远比想象中要脆弱。这次测试代号“实战七”，核心目标不是炫技，而是用最贴近真实攻击者的思路和手法，去验证一个看似坚固的网络边界和内部环境，到底能暴露出多少问题。整个过程下来，感触很深，很多问题其实都源于一些被忽视的“小细节”和“想当然”的配置。

对于安全从业者或者对渗透测试感兴趣的朋友来说，这类实战复盘的价值在于，它跳出了理论框架和靶机环境，直接面对真实网络中的不确定性和复杂性。你会遇到千奇百怪的设备、五花八门的配置、以及各种历史遗留的“技术债”。今天，我就把这次测试的核心思路、关键步骤、遇到的坑以及最终的发现，完整地梳理一遍。无论你是想入门安全测试，还是想加固自己的网络环境，相信都能从中获得一些直接的参考。

2. 前期信息收集与目标锁定

渗透测试的第一步，永远不是直接上工具狂轰滥炸，而是静下心来，像侦探一样收集一切可能的信息。对于外部测试，我们拿到的授权范围是客户提供的几个公网IP段和几个主域名。目标是尽可能发现从互联网可以触及的攻击面。

2.1 被动信息收集：互联网上的“数字脚印”

被动信息收集的核心在于，不直接与目标系统交互，而是从公开渠道搜集信息。这就像在动手前，先通过社交媒体、企业年报、招聘信息去了解一个人。

我们首先从客户的官网、子公司网站入手。在“关于我们”、“团队介绍”、“新闻动态”等页面，仔细寻找技术栈信息。比如，一篇新闻稿里提到“全新上线了基于XX框架的客户管理系统”，这就暗示了可能存在的Web应用技术。通过查看网页源代码，我们发现了多处引用了特定版本的JavaScript库和前端框架，这些信息对于后续寻找已知漏洞非常有帮助。

此外，我们还利用了诸如“钟馗之眼”、“FoFa”这样的网络空间测绘引擎。通过搜索客户公司名、域名关键词，我们发现了几个未被客户主动提及的子域名和IP地址。其中一个dev.api.xxx.com的子域名引起了注意，它很可能是一个开发或测试环境，而这类环境的安全配置往往比较松懈。通过搜索引擎的“site:”语法和“inurl:”语法，我们也找到了一些可能暴露的目录或文件，比如site:target.com inurl:admin，虽然大部分是404，但这也是一种试探。

注意：被动信息收集一定要在法律和授权范围内进行，并且要善用各种搜索语法和工具的组合，避免单一渠道的信息遗漏。很多企业泄露的信息，就藏在GitHub的代码仓库、网盘分享链接甚至是技术论坛的提问帖子里。

2.2 主动信息探测：勾勒网络边界轮廓

在被动收集到一批潜在目标（IP、域名）后，我们开始进行低强度的主动探测。这里的“主动”指的是与目标建立连接，但目的是探测而非攻击。

首先是端口扫描。我们使用Nmap进行扫描，但策略非常谨慎。初始扫描使用-sS(SYN半开扫描) 和-sV(版本探测) 参数，并加上-T2(时序模板，降低速度) 以减少对目标网络的影响和触发安全设备告警的风险。扫描发现了几个关键点：

• 主Web服务器（80/443端口）运行着Nginx，版本较新。
• 一个疑似邮件服务器的IP开放了25(SMTP)、110(POP3)、143(IMAP)端口。
• 最令人意外的是，在一个边缘网络设备的管理IP上，发现了开放着的3389端口(Windows远程桌面) 和22端口(SSH)。这通常意味着可能存在远程管理入口。

在Web应用层面，我们使用Dirb或Gobuster对主站和发现的子域名进行目录枚举。为了避免产生大量无效流量，我们使用了自定义的、针对常见CMS和API接口的字典。在对dev.api.xxx.com的扫描中，我们发现了一个/backup/目录，返回状态码403（禁止访问）。403不代表不存在，反而提示我们这个路径是受保护的，可能是一个潜在的突破口。

同时，我们通过浏览器和命令行工具，仔细检查了每个Web应用的HTTP响应头。在主站的响应头中，我们发现Server: nginx/1.18.0和X-Powered-By: PHP/7.4.33，这精确地给出了中间件和语言的版本信息，为后续寻找版本漏洞提供了依据。

3. 漏洞挖掘与初期突破

信息收集阶段为我们绘制了一张粗略的“攻击地图”。接下来，就是在这张地图上寻找最薄弱的环节，尝试撕开第一道口子。

3.1 Web入口的常规测试与意外发现

我们首先对主站和几个子站进行了常规的Web漏洞扫描，使用Burp Suite作为代理，手动测试与自动化工具（如Nuclei）结合。测试了SQL注入、XSS、文件上传、逻辑漏洞等。主站防护相对完善，常规注入点都被WAF拦截。

然而，在测试一个“忘记密码”功能时，我们发现了逻辑漏洞。该功能在提交手机号后，会向用户发送短信验证码。我们通过Burp Suite拦截请求，发现响应包中直接返回了短信验证码（用于前端显示倒计时）。这意味着，攻击者无需接收短信，即可直接获取验证码，从而重置任意用户的密码。这是一个典型的信息泄露类逻辑漏洞。

但我们没有立即利用这个漏洞，因为我们的目标是内网，而这是一个面向外部用户的系统。我们将其记录为高危漏洞，并继续寻找更直接的入口。

3.2 薄弱服务的利用：从SSH弱口令到突破口

我们将注意力转向了之前发现的开放22和3389端口的那个边缘设备IP。首先尝试SSH爆破。我们准备了一个精简的、针对网络设备和常见服务账号的字典（如 admin, root, user, test 等用户名，配合 top100 弱口令）。使用Hydra进行爆破：

hydra -L user_list.txt -P pass_list.txt ssh://目标IP -t 4 -vV

-t 4控制线程数避免过于暴力，-vV显示详细尝试过程。经过一段时间，爆破成功！用户名是admin，密码是Admin@123。这是一个非常典型的弱口令，可能是设备初始化后从未修改。

成功登录SSH后，我们发现自己在一台Linux主机上，权限不高。通过执行id,uname -a,ifconfig等命令，确认这是一台用于网络管理的跳板机，双网卡配置，一块网卡连接互联网（我们进来的路径），另一块网卡连接着内部办公网络（10.10.x.x段）。我们找到了梦寐以求的内部网络立足点。

实操心得：对于SSH/RDP等服务的爆破，字典的质量远比数量重要。结合目标属性（是网络设备、服务器还是个人PC？）来定制用户名和密码字典，能极大提高成功率并减少日志量。例如，针对网络设备，admin/Cisco123,admin/Huawei@123这类组合就值得尝试。

4. 内网横向移动与权限提升

拿到内部网络的一台跳板机后，真正的“内网漫游”才刚刚开始。目标是从这台权限受限的跳板机，向网络深处更有价值的系统（如域控制器、文件服务器、数据库服务器）移动。

4.1 内网信息再收集

在跳板机上，我们首先进行内网信息收集：

1. 网络拓扑探测：使用netstat -antp查看当前主机的网络连接，发现它到内网地址10.10.10.20有频繁的通信。使用arp -a查看ARP缓存，获取同一网段的其他主机IP和MAC地址。
2. 主机发现：由于跳板机上没有安装nmap，我们使用ping命令配合bash脚本进行简单的存活主机扫描，针对10.10.10.0/24网段。

   for i in {1..254}; do ping -c 1 -W 1 10.10.10.$i | grep "bytes from" & done

   发现了约50台存活主机。
3. 凭证搜集：检查当前用户的家目录历史文件（.bash_history）、配置文件（如.ssh/config，可能包含连接其他服务器的密钥路径）、以及任何可能记录密码的文本文件或脚本。在这台跳板机上，我们在一个名为network_scripts的目录下，发现了一个connect_to_db.sh的脚本，里面硬编码了连接某台数据库的账号密码：db_user/DbP@ssw0rd!。

4.2 利用收集的凭证进行横向移动

我们尝试用发现的数据库密码，去测试内网中其他服务的登录。首先，我们探测了内网中哪些主机开放了数据库端口（如MySQL的3306，MSSQL的1433）。使用跳板机上的nc(netcat) 进行快速端口探测：

for ip in 10.10.10.{1..254}; do timeout 1 nc -zv $ip 3306 2>&1 | grep succeeded; done

发现10.10.10.50开放了3306端口。我们尝试用db_user/DbP@ssw0rd!进行连接。幸运的是，密码复用！我们成功登录了这台MySQL数据库服务器。

登录数据库后，我们不仅查看了数据库内容（其中包含了一些内部应用的用户数据），更重要的是，我们尝试检查MySQL的运行配置和权限。通过执行select user, host from mysql.user;，我们发现root用户允许从本地登录。我们进一步尝试利用MySQL的UDF（用户自定义函数）提权或者写入Webshell，但这需要一定的条件。我们转而寻找其他路径。

4.3 权限提升与域环境探测

在数据库服务器上，我们通过select @@version;发现它运行在Windows系统上（MySQL for Windows）。这意味着我们可能通过数据库的“系统命令执行”功能来获取一个Windows shell。我们检查了MySQL的权限，运行show variables like '%secure_file_priv%';，发现该值为空，这意味着可以从MySQL向任意目录写文件。

我们尝试使用into outfile语句写入一个简单的PHP Webshell到Web目录（前提是我们需要知道Web目录路径）。通过查询一些数据库中的配置表，我们推测出了Web路径。写入成功后，通过访问该Webshell，我们获得了数据库服务器上一个Web服务进程的权限（通常是IIS_USRS或NETWORK SERVICE）。

接下来是本地提权。我们上传了WinPEAS或PowerUp.ps1等Windows本地提权检查脚本，通过Webshell执行。检查发现，该服务器上安装了一款老版本的杀毒软件，且其服务配置存在权限问题。更关键的是，我们在服务器的补丁列表中，发现缺少一个关键的本地提权漏洞补丁（例如CVE-2021-36934等）。我们使用了一个公开的、针对该漏洞的提权EXP，成功将权限从普通用户提升到了NT AUTHORITY\SYSTEM，即Windows最高权限。

获得系统权限后，我们运行whoami /all和net user等命令，确认这台服务器并非域控制器，但它加入了公司的域（Domain）。运行net group "Domain Admins" /domain命令（需要先通过net use等方式与域控建立连接或在本机缓存中查找），我们未能直接获取到域管理员列表，但这确认了域环境的存在。我们转而在本机抓取密码哈希，使用mimikatz或更隐蔽的方式（如dump lsass进程内存）。成功抓取到了多个域用户的哈希值，包括一个属于“IT支持”组的用户。

5. 核心资产突破与权限维持

拿到域用户凭证（哈希值）后，我们的目标转向域控制器和核心数据服务器。

5.1 利用哈希传递攻击渗透域控

我们拥有的是一个NTLM哈希，而非明文密码。在内网中，这通常足够了。我们使用CrackMapExec或Impacket套件中的psexec.py，进行哈希传递攻击。

python3 psexec.py 域/用户@域控制器IP -hashes :<NTLM哈希值>

这里的关键是，Windows网络认证中，如果启用了NTLM认证，且没有限制（如NTLMv1已禁用，但NTLMv2仍可能被利用），就可以使用哈希而非明文密码进行认证。我们使用抓取到的IT支持组成员的哈希，成功在域控制器上获得了一个System权限的交互式Shell。

5.2 域控上的信息收割与权限巩固

在域控制器上，我们可以进行终极的信息收割：

1. 导出所有域用户哈希：使用ntdsutil或vssadmin等工具创建卷影副本，然后从NTDS.dit文件中导出所有域用户的哈希值。这是攻击者的“皇冠宝石”，意味着整个域都在掌控之中。
2. 查看域策略：通过gpresult /h report.html或查看组策略管理控制台，了解域内的安全策略、软件部署、登录脚本等，这些信息有助于发现更多攻击路径或配置弱点。
3. 定位核心服务器：通过分析域控上的DNS记录、DHCP租约信息，或者直接查询活动目录中服务器的SPN（服务主体名称），我们可以快速定位数据库服务器、文件服务器、邮件服务器、ERP系统服务器等核心资产。

为了维持访问权限，防止被发现后清除，我们建立了多个持久化后门：

• 黄金票据：利用从域控导出的krbtgt用户的哈希，我们可以伪造任意用户的Kerberos票据（TGT），从而随时以域内任何用户（包括域管理员）的身份访问任何服务。这是最强大的持久化手段之一。
• 隐蔽的Webshell：在域控或核心Web服务器上，植入经过免杀处理的、内存马形态的Webshell，不落盘，更难被检测。
• 计划任务：在多个核心服务器上创建计划任务，定期连接我们的外部C2服务器，确保通道畅通。
• 域控上的SSH公钥：如果域控也开启了SSH（某些混合环境可能存在），我们会在authorized_keys文件中添加我们的公钥。

重要提示：权限维持阶段的所有操作都必须极其谨慎，避免触发安全告警。例如，创建计划任务时，任务名要模仿系统任务；文件路径选择隐蔽目录；时间设置为非工作时间等。同时，这些后门仅在渗透测试授权范围内部署，并在测试结束后由测试方彻底清理。

6. 测试总结与暴露的深层问题

整个渗透路径可以概括为：公网边缘设备弱口令 -> 跳板机 -> 内网密码复用/数据库服务器 -> Windows本地提权 -> 抓取域用户哈希 -> 哈希传递攻击域控 -> 获取全域控制权。

回顾全程，客户网络暴露出的核心问题并非高深莫测的0day漏洞，而是一系列基础安全措施的缺失和不良习惯的累积：

1. 边界防护片面：过度依赖防火墙拦截外部攻击，却忽视了暴露在公网的运维接口（SSH、RDP）使用弱口令这个“简单粗暴”的入口。
2. 内网无隔离：跳板机一旦失陷，攻击者可以直接访问核心办公网段，缺乏网络分段、VLAN隔离或严格的访问控制策略。
3. 密码管理灾难：
   • 弱口令：边缘设备使用默认或简单密码。
   • 密码复用：数据库密码被硬编码在脚本中，且该密码可能被用于其他系统。
   • 凭据存储不当：密码明文写在脚本中。
4. 补丁管理滞后：内部服务器操作系统或应用存在已知高危漏洞且未及时打补丁，为权限提升打开了方便之门。
5. 域安全配置缺陷：允许使用NTLM哈希进行身份验证（未强制要求Kerberos认证），且未对敏感账户（如IT支持组）的登录行为进行严格监控和限制，使得哈希传递攻击得以成功。
6. 安全监控缺失：从外部爆破到内网横向移动，再到域控被入侵，全程未触发有效的安全告警。日志可能记录了异常，但无人分析或告警规则未覆盖这些行为。

7. 给防御者的实用建议

基于这次测试的发现，如果要从防御角度加固企业网络，我建议优先做以下几件事，它们的投入产出比最高：

1. 收紧网络边界：
   • 严格审查并最小化公网暴露面。非必要的管理接口（SSH、RDP、数据库端口）绝不对外开放，必须开放的，应部署在VPN或零信任网关之后。
   • 对必须开放的公网服务，启用强密码策略+多因素认证，并配置基于IP的访问限制。
2. 推行网络分段：根据业务功能和安全等级，将网络划分为不同区域（如办公网、服务器区、DMZ区），区域之间通过防火墙实施严格的访问控制，遵循最小权限原则。确保即使一个区域被突破，攻击者也无法直接访问其他区域。
3. 加强身份与访问管理：
   • 强制使用复杂且唯一的密码，并定期更换。严禁密码复用。
   • 在Windows域环境中，尽可能禁用NTLM认证，强制使用Kerberos。对域管理员等高权限账户启用“受保护用户”组策略，并限制其登录范围。
   • 实施特权访问管理，对IT管理员的日常操作使用跳板机，并进行会话审计。
4. 建立有效的补丁管理流程：不仅针对操作系统，也要涵盖办公软件、中间件、数据库、网络设备固件等所有资产。建立资产清单，定期扫描漏洞，并设定不同风险等级漏洞的修复时限。
5. 部署并调优安全监测体系：
   • 在关键网络节点和核心服务器上部署EDR或主机安全agent。
   • 收集全网的流量日志、安全设备日志、主机日志，并接入SIEM平台。
   • 请安全专家或通过红队演练，帮助梳理和优化告警规则，确保能发现爆破、横向移动、哈希传递、敏感数据访问等关键攻击行为。告警不在于多，而在于准和及时。

安全是一个持续的过程，而非一劳永逸的状态。真正的安全不在于购买了多么先进的设备，而在于是否将这些基础的安全实践扎实地落地，并持续运营和改进。这次“实战七”就像一次体检，查出的都是“基础病”，但恰恰是这些“基础病”，最容易在真实的攻击中导致全线崩溃。