企业渗透综合实验复盘：从默认口令到 Struts2 命令执行

本文记录的是一次授权实验环境中的综合 Web 渗透作业。文中的目标地址统一使用 <target-ip> 脱敏，命令和思路只用于靶场、课程实验或明确授权的测试环境。

这次实验的价值不在于“用了多少工具”，而是把几个很常见的风险点串成一条完整的渗透思路：

阶段	关注点	结果
入口识别	登录页、产品指纹、公开资料	识别到启明星辰天清汉马集中管理中心
初始访问	默认账号密码	使用公开手册中的默认凭据进入后台
后台枚举	技术栈、功能点、系统类型	发现 Java/Tomcat 环境和 Ping 测试功能
漏洞验证	SQL 注入、命令注入、Struts2	SQL 注入存在限制，命令执行与 Struts2 风险更高
复盘修复	暴露面、认证、输入处理、组件版本	默认口令和危险后台功能是核心风险

• 目标识别

首先访问目标 Web 服务，页面风格和标题能看出它属于启明星辰天清汉马集中管理中心。

这一步不要急着上扫描器。后台系统最先要确认三件事：

• 这是什么产品；
• 是否有公开手册、默认账号、历史漏洞；
• 页面路径和返回特征是否暴露技术栈。

针对产品名做资料检索：

启明星辰天清汉马集中管理中心 密码 OR password OR passwd OR pwd

从公开手册中可以找到默认登录凭据：

admin / admin123

这里的关键点不是“默认密码好猜”，而是很多企业后台在交付、测试、内网部署时会保留默认配置。只要后台暴露到可访问网络，默认口令就会直接变成初始访问入口。

默认口令登录

使用默认凭据后，成功进入后台。

进入后台后，不要只盯着“有没有一键 getshell”。更稳的顺序是先做后台功能梳理：

• 系统信息、版本信息；
• 网络诊断、Ping、Traceroute、抓包类功能；
• 文件上传、备份恢复、日志下载；
• 用户管理、权限配置；
• 对外连接配置，比如数据库、LDAP、邮件服务。

这些功能往往比登录页本身更接近真实攻击面。

指纹与技术栈

继续看指纹信息，可以判断目标是 Java Web 环境，运行在 Tomcat 上。

Tomcat 本身不是漏洞结论，它只是告诉我们后续可以重点关注：

• 是否存在 Struts2、Spring、Shiro 等 Java 生态组件；
• URL 是否有 .action、.do、.jsp 等特征；
• 错误页面是否泄露框架、路径、版本；
• 后台功能是否把用户输入交给系统命令或 Java 运行时处理。

信息收集不是为了把工具跑满，而是为了缩小判断范围。这个目标已经明确是一个后台系统，所以优先做手工功能测试更有效。

Ping 功能与命令执行风险

后台中发现 Ping 测试功能。

这类功能天然危险，因为业务上需要把用户输入拼接到系统命令里：

ping 用户输入的地址

如果后端只是简单拼接，没有做白名单校验、参数化处理或命令隔离，就可能出现命令注入。授权测试中可以用低影响命令验证，例如：

127.0.0.1 & whoami
127.0.0.1 & hostname

如果页面返回了系统命令结果，就说明输入已经突破了“IP 地址参数”的边界，进入了系统命令执行层。本次实验中通过回显特征可以判断目标主机是 Windows。

这里真正要记住的是判断方法：

• 正常输入只应该影响 Ping 的目标地址；
• 如果输入里的连接符改变了命令执行结果，就说明后端存在命令拼接；
• 验证时优先使用 whoami、hostname 这类低影响命令，不做破坏性操作。

登录页 SQL 注入

登录页还可以使用万能密码绕过。

这说明登录接口对用户输入处理不充分，可能把用户名或密码直接拼接到了 SQL 查询里。为了进一步确认注入点，可以用 sqlmap 做轻量验证：

sqlmap -u "http://<target-ip>:8888/MgmtCenter/login.action" \
  --data="username=admin&password=admin123" \
  -p "username" \
  --technique=B \
  --level=1 --risk=1 \
  --string="Manager" \
  --delay=3 \
  --random-agent \
  --batch

参数选择思路：

参数	作用
-p username	指定只测试username 参数，减少无关请求
--technique=B	只做布尔盲注，适合没有明显回显的登录接口
--level=1 --risk=1	降低测试强度，避免把后台打挂
--string="Manager"	用登录后页面中的稳定字符串判断真假条件
--delay=3	给每次请求增加间隔，降低锁定和 502 风险

不过这条路在实际利用上价值有限：登录失败次数会触发系统锁定，自动化测试很容易把自己挡在门外。

所以这里的复盘结论是：SQL 注入是一个风险点，但不是本次最优利用路径。后台默认口令和命令执行点更直接，Struts2 组件风险也更值得优先验证。

Struts2 指纹与漏洞检测

登录失败后的 URL 中出现了 login.action。

.action 不是 Struts2 的绝对证明，但它是 Java Web 中非常典型的 Struts 风格路径。结合 Tomcat 指纹，可以把 Struts2 历史漏洞纳入检查范围。

使用 Struts2 漏洞检测工具时，填入目标 URL，选择 POST 提交方式，并配置对应参数。

检测结果指向 S2-046 方向的命令执行风险。原理上，这类漏洞通常与 Struts2 对特殊请求头、文件上传异常处理、OGNL 表达式解析等机制有关。真正利用时不要只看工具的“存在漏洞”提示，还要至少确认三件事：

• 请求是否真的打到了目标 Struts2 Action；
• 命令是否有稳定回显或可观测副作用；
• 目标版本、补丁状态和检测结果是否一致。

这一步的重点是把“URL 特征”变成“可验证结论”。.action 只能提示方向，不能替代漏洞验证。

攻击链复盘

这次实验的攻击链可以整理为：

识别后台产品
  -> 检索公开手册和默认凭据
  -> 默认口令进入后台
  -> 后台功能枚举
  -> 发现 Ping 测试命令执行风险
  -> 发现登录页 SQL 注入但利用受限
  -> 根据 .action 与 Tomcat 指纹验证 Struts2 风险

它说明了几个很现实的问题：

• 默认口令仍然是高频入口；
• 后台系统一旦暴露，危险功能会被直接放大；
• SQL 注入不一定总是最优路径，利用价值取决于回显、锁定、权限和业务逻辑；
• 框架指纹只能提供方向，最终还是要靠低影响、可复现的验证闭环；
• Web 渗透不是工具列表，而是“入口、权限、功能、组件、影响面”的连续判断。

修复建议

面向防守侧，这类系统至少要做以下处理：

1. 修改所有默认账号密码，禁用不必要的默认账户。
2. 后台只允许管理网段或 VPN 访问，不直接暴露到公网或不受控内网。
3. 登录接口使用参数化查询，禁止字符串拼接 SQL。
4. 对 Ping 这类网络诊断功能做严格白名单，只允许合法 IP 或域名格式。
5. 后端避免直接拼接系统命令，必须执行时使用隔离账户和最小权限。
6. 升级 Struts2 等 Java 组件，排查历史 RCE 漏洞影响范围。
7. 增加登录失败告警，但不要让锁定机制变成唯一防线。
8. 记录后台关键操作日志，便于事后溯源。

小结

这篇复盘最值得记住的是顺序感。

先确认产品，再找公开资料；先拿到后台，再做功能枚举；先用低影响命令验证，再判断漏洞价值。渗透不是看到一个点就猛打，而是不断判断哪条路径更稳定、更低噪声、更接近真实风险。

默认口令、命令注入、Struts2 这些漏洞本身都不新，但它们组合到一个后台系统里，就会形成一条很典型的企业 Web 风险链。