从一则真实入侵案例：看懂 AI 辅助域侦察攻击的防御新思路|directory|powershell|代码|命令提示符|哈希|文件名|服务器|辅助域

楔子：一个文件名暴露了一切

2026年6月的某个普通工作日，一家企业的Windows服务器悄悄迎来了一位不速之客。

攻击者用一组早已泄露的账号密码，借助VPN悄然滑入企业内网，随即通过远程桌面连接到一台加入域的服务器。落地之后，他没有急着加密文件、没有立刻破坏系统，而是在C:\ProgramData\目录下放下了一个文件。

文件名叫：Untitled1.ps1

这个名字本身就是一个线索。

没有任何经验丰富的渗透测试工程师或恶意软件开发者会用默认文件名保存自己精心打磨的工具。"Untitled1"是文本编辑器在用户来不及命名时自动生成的名字——它意味着，使用者复制了一段代码，打开了编辑器，然后直接按下了保存键。

一个月后，网络安全公司Huntress对这起事件进行了详细披露。当研究人员从日志中重新拼接出这段脚本的完整内容时，他们注意到脚本内部赫然写着一行标题："100% Working AD Information Gathering Script——FULLY FIXED"

"100%可用。已完全修复。"

这不像是一个黑客写的。这像是一个用户在与AI助手反复对话、反复报错、反复要求"帮我修好它"之后，把模型最终给出的版本整体复制下来的产物。

这段不够精致、带着占位符、还顺手生成了一份HTML报告的脚本，成为了2026年网络安全领域最值得警惕的事件之一。

不是因为它有多高明，而是因为它说明了一件事：AI正在成为攻击者的"武器量产机"。

一、进入之后，黑客首先要摸清"地形"

要理解这次事件的意义，需要先理解攻击者拿到一台服务器之后会做什么。

控制一台服务器，并不等于控制了一家企业。

现代企业的内网中，往往存在数百台服务器、数千个员工账号，以及复杂交织的权限体系。攻击者踏入网络的第一步，更像是蒙眼闯入一栋陌生的大楼——他知道自己在里面，却不知道保险柜在哪一层，不知道哪扇门通向核心机房，也不知道哪个账号拥有足够的权限带他去想去的地方。

这时候，Active Directory就是那张地图。

Active Directory是微软Windows域环境的核心身份目录，它记录了域用户、域内计算机、用户组、组织架构、网络子网，以及各域之间的信任关系。

对攻击者而言，能够枚举Active Directory，就相当于拿到了一张企业内部的人员名册和网络地图。

哪些账号是管理员？哪些服务器权限最高？域与域之间存在哪些信任通道？

这些信息将决定攻击者下一步往哪走。

这种行为，在攻击链中被称为"侦察"或"发现"，在MITRE ATT&CK框架中对应"域账号发现"等具体技术分类。它本身并不新鲜——只要攻击者试图横向移动或提升权限，这一步骤就无法绕过。

新鲜的，是这次完成这一步骤的工具从哪里来。

二、AI写的代码，长什么样子

Huntress研究人员通过PowerShell脚本块日志（事件ID 4104）还原了Untitled1.ps1的完整内容。

当他们阅读这段代码时，感受到了一种奇特的违和感。

第一个异样：五层回退机制。

脚本在寻找域控制器时，使用了五种连续的备选方案：先通过DNS查询，失败了就调用nltest，再失败就使用Active Directory PowerShell模块，接着检查系统环境变量，以上全部失败后，代码还准备使用一个硬编码的服务器地址。

五层。

一个熟悉目标环境的开发者，通常会选择一两种最稳定的方法，而不是把所有可能的方案依次堆叠。

但大语言模型不一样——当用户要求"确保一定能找到域控制器""不要让脚本出错"时，模型倾向于把它训练数据中能想到的所有方法全部列出来。这种"把所有可能方案都写进去"的风格，是AI生成代码的典型特征之一。

第二个异样：一个从未被修改的占位符。

在最后一层回退代码中，硬编码的服务器地址是：Server1.HR.local

这显然不是受害企业真实使用的服务器名称。它更像是AI为了演示代码结构而随手填写的示例域名——一个应当被使用者替换掉的占位符。

但攻击者没有修改它。

他把整段代码原封不动地复制了过来，直接投入使用。这说明他可能并没有逐行理解这段脚本，只是确认它"能运行"，便将其付诸实践。

第三个异样：一份没有必要的HTML报告。

完成信息收集后，脚本自动生成了一份名为AD_Report.html的网页报告。

对于一个只需要窃取数据的攻击者而言，这完全多余。最直接的做法是把CSV文件压缩后带走，生成HTML报告只会增加磁盘写入、延长执行时间，并制造更多可被检测的痕迹。

然而，对于一个被要求"生成一个完整的Active Directory信息收集工具"的AI来说，附上可视化报告、进度颜色输出和汇总统计，是一种体现"助手价值"的自然冲动。

模型加上了。攻击者没有删掉它。整段代码就这样带着HTML报告和错误占位符，完成了一次真实的企业内网侦察。

三、笨拙，但有效

脚本最终收集的信息，覆盖范围相当完整。

它枚举并导出了域用户、域计算机、用户组、组织单位、网络子网、域信任关系，以及筛选出带有电子邮件地址的用户列表，结果分别保存为AD_Users.csv、AD_Computers.csv、AD_Groups.csv等多个文件，统一存放在一个带有时间戳的目录中。完成收集后，脚本自动将整个目录压缩成ZIP包，为后续数据转移做好准备。

在MITRE ATT&CK框架中，将收集结果集中存放在本地临时目录属于"本地数据暂存"，将其压缩属于"归档已收集数据"。

大约半小时后，攻击者部署了s5cmd.exe——一款用于Amazon S3对象存储操作的合法高性能命令行工具。紧接着，SharpShares.exe被启动，继续搜索网络中的共享目录。

整条攻击链清晰呈现：凭据入侵→远程桌面控制→AI脚本侦察→数据整理压缩→合法工具外传。

这段代码不够优雅，有冗余，有占位符，还携带了一份无意义的HTML报告。

但它完成了任务。

四、AI真正改变的，是攻击者的"生产能力"

围绕AI与网络攻击的讨论，很容易滑向两个极端：要么认为AI即将催生出人类从未见过的超级武器，让一切防御体系瞬间失效；要么认为AI生成的代码漏洞百出，真正有实力的攻击者根本不需要它，不值得过度渲染。

这次事件提供了一个更现实的视角。

AI可能没有帮助攻击者发明新的漏洞利用技术，也没有让这次攻击达到高级持续性威胁行动的复杂程度，但它做到了一件关键的事：让一个原本编程能力有限的人，在短时间内制作出符合具体需求的定制化工具。

这就是所谓的"氛围编程"（Vibe Coding）。

使用者不需要逐行理解代码结构，只需用自然语言描述目标，让AI生成程序，然后根据运行结果和错误信息不断调整提示词，直到程序"差不多能用"。这种模式在正常业务场景中可以加速原型开发，在攻击场景中，则同样可以降低恶意工具的生产门槛。

过去，一个能力有限的攻击者只能下载公开脚本或购买成熟攻击框架。由于大量攻击者重复使用相同工具，安全厂商可以提前提取文件哈希、代码特征和网络指纹，构建稳定的检测规则。

现在，攻击者可以对AI说"帮我写一个枚举Active Directory的脚本，确保能运行"。模型生成的脚本，可能只用于这一次攻击，用完即删。下一个攻击者即使提出完全相同的需求，模型给出的变量名、函数结构、错误处理逻辑和输出格式也会有所不同。

恶意工具，由此从"批量生产的标准武器"，逐渐转向"现场临时组装的一次性工具"。

五、传统特征检测为何越来越力不从心

传统安全检测的逻辑，建立在一个重要前提之上：恶意代码会被反复使用。

同一款工具，被越多攻击者使用，安全厂商就越有机会提取其文件哈希、字符串特征和行为模式，并将其纳入检测库。BloodHound、Mimikatz、Cobalt Strike之所以能被大多数安全产品识别，正是因为它们被研究和分析的次数足够多。

但Untitled1.ps1此前从未出现过。

它是根据当次需求临时生成的脚本，在完成此次攻击后，可能永远不会以完全相同的形式再次出现。

安全产品无法提前获得它的文件哈希，无法将其归入任何已知恶意软件家族，也无法靠传统标签体系识别它的危险性。

攻击者甚至不需要刻意使用混淆技术。只要对AI说"帮我换一种写法"或"修改变量名称"，就可能产生大量静态特征各异、但功能高度相似的脚本变体。

这也意味着，试图建立一套"AI生成恶意代码特征库"，并不是最可靠的应对方向。代码中的注释风格、函数命名习惯和冗余结构可以提供分析线索，却无法成为确定性证据。更重要的是，企业开发人员同样会使用生成式AI编写PowerShell运维脚本——区分"AI生成的运维代码"和"AI生成的攻击代码"，并不能简单依靠代码风格判断。

真正应该检测的，不是代码由谁编写，而是代码在系统中做了什么。

六、代码可以千变万化，行为却无法消失

这是此次事件对防守方最重要的启示。

AI可以改变脚本的文件名、变量名称、函数结构和输出格式，却无法绕过完成攻击目标必须执行的基本动作。

攻击者想了解域环境，就必须查询域控制器、用户、计算机和信任关系；想发现可窃取数据，就必须枚举磁盘目录和网络共享；想集中整理信息，就需要创建暂存目录并持续写入文件；想方便传输，就可能压缩数据；想把数据带走，就必须连接外部服务或云存储。

这些动作都会留下痕迹。

Huntress正是通过Microsoft-Windows-PowerShell/Operational日志中的4104事件（PowerShell脚本块日志），将攻击者运行的完整脚本重新拼接还原。这说明，即使攻击者使用的是从未出现过的一次性脚本，只要企业保留了足够完整的终端执行日志，安全团队仍然有机会发现并还原整个攻击过程。

这也意味着，防御体系的建设重心，需要从"识别某个文件"向"理解某段行为"进一步迁移。

七、不要把注意力全放在"是不是AI写的"

这次事件很容易被包装成一个耸人听闻的标题——AI已经开始自动制造恶意软件。

但从网络安全治理的角度看，过度聚焦于"这段代码是不是AI写的"，意义十分有限。

未来，AI辅助编程将会无处不在，人类编写、AI生成与人机协作之间的边界会越来越模糊。即使能够判断某段代码来自大语言模型，也不能直接帮助企业阻断攻击。真正影响安全结果的问题是：账号为什么被盗？远程访问为什么没有受限？域侦察为什么未被及时发现？数据为什么能够被集中压缩？外传工具为什么可以自由运行？

过度强调"AI恶意软件"还可能带来一个危险的副作用：企业误以为需要购买一套专门识别AI代码的新产品，却因此忽略身份安全、日志审计、终端监控和行为分析这些更基础、更有效的防御能力建设。

AI在这起事件中扮演的角色，更像是一台攻击工具的生产加速器。

它没有重新定义入侵流程，没有创造新的侦察需求，也没有消除攻击痕迹，但它提高了攻击者制作定制工具的效率，让缺乏专业开发能力的人也能够快速获得"够用的"自动化攻击脚本，并增加了恶意代码在静态特征上的多样性。

尾声：看清行为，才是真正的防线

Huntress披露的这段PowerShell脚本并不高明。

它有冗余代码，有明显占位符，有夸张标题，还顺手生成了一份对攻击毫无必要的漂亮HTML报告。它看起来更像是一个水平有限的使用者，在AI帮助下反复试错后拼凑出来的程序。

但它完成了Active Directory侦察，整理了用户、计算机、组、域信任和网络信息，并把结果压缩成便于转移的文件包。