企业官网建设流程全解析

▌概述

开放目录常被当作受害方的配置失误，但安全测试人员乃至高级持续性威胁（APT）攻击者，同样可能因为一次临时文件服务的疏忽而暴露作业痕迹。这对防御方而言，便是绝佳的低成本反制溯源入口。在近期的研究中，我们从一台暴露在公网的攻击者文件服务器中，发现了较完整的攻击过程和受控资产清单，并据此还原出一个威胁泰国财政部、TRIPLE T 宽带公众有限公司等多个单位的攻击活动簇，将其命名为AyutMesh。从泄露文件看，该活动簇呈现出明显的 AI 辅助攻击特征。这反映出当前攻击活动正在从"人工编排"转向"AI 自动化迭代"，攻击者即使不依赖 0day，也能借助 AI 快速生成、改写和扩展渗透脚本，在更低成本下扩大攻击覆盖面。

▌临时文件服务器为何反复暴露

被低估的开放目录

开放目录从来不是低价值信息源，它只是经常被开启它的人低估。从近一年公网资产测绘数据看，存在目录索引暴露的服务器 IP 已超过一百万，覆盖绝大多数国家。它们并不都与渗透测试有关，但这类暴露形态本身足够常见，也足够值得关注。

图 1：开放目录类页面的公网分布概览

这类暴露并不只出现在小型 VPS 或个人项目中。2026 年 6 月披露的 FortiBleed 事件中，安全研究员 Bob Diachenko 在例行扫描中发现了一个俄语犯罪团伙暴露在公网的开放目录，其中存放着他们的攻击战果——一份覆盖194 个国家、约7.5 万台FortiGate 防火墙的凭证数据库。正是攻击者自身基础设施的疏忽暴露，才让这起波及全球近半数互联网 Fortinet 设备的入侵活动被揭开。

在临时搭建的文件服务器中，一个看似普通的目录页，可能保存着配置文件、压缩包、扫描脚本和结果报告。对使用者来说，这只是一次临时文件投递；但对外部观察者来说，文件名、目录结构、时间戳和工具痕迹，足以还原一段完整的作业链路，并进一步指向目标、基础设施和攻击手法。

红队作业中的临时文件服务器

在渗透测试和红队作业中，临时文件服务器本身就是一类常见基础设施。原因通常集中在三点：

• 文件下发：目标环境需要下载验证脚本、工具包或依赖文件，HTTP 是最直接、兼容性最好的方式。
• 团队中转：团队成员之间需要同步截图、扫描结果和复现材料，临时文件目录比反复传压缩包更方便。
• 结果查看：扫描器生成的 HTML、CSV、JSON 报告需要快速查看，直接挂到 Web 目录下最省事。

相比网盘、SFTP、Git 仓库或协作平台，HTTP 对环境要求最低，浏览器、curl、wget都能直接访问。很多文件服务器并不是为了"公开分享"，而是为了把文件更快送到该去的地方。

一行 Python 带来的便利和风险

这也是python -m http.server长期常见的原因。Python 在大量服务器和测试环境中默认存在，http.server属于 Python 标准库，不需要额外安装第三方依赖。

python3 -m http.server 8000

进入目录后执行这一行命令，当前目录就会立刻变成一个 HTTP 文件服务。进入目录、执行命令、马上可用。

风险也来自这个启动方式：如果在项目目录里直接启动服务，暴露的就不只是一个文件，而是整个工作目录。

project/ ├── config.ini ├── tools.zip ├── scan_result.html ├── target.txt └── report_draft.docx

当启动成本低到几乎可以忽略时，访问控制、目录边界和关闭动作就很容易被忽略。一次"临时传个文件"，可能变成一个长期暴露在公网的工作目录。

这种风险并不只出现在安全测试人员一侧。攻击者同样需要中转工具、分发脚本、保存结果、同步配置，也同样会因为方便而临时开放文件服务器。临时目录往往没有经过整理，文件名、目录结构、时间戳、配置残留和命令回显会保留更多原始痕迹。

当暴露的文件服务器属于攻击者时，公开目录就不再只是泄露面，而可能成为攻击链入口。这些痕迹连起来，一个普通目录页就可能通向基础设施、远控体系和受害范围分析。

▌利用文件服务器发掘威胁情报实例

在对该文件服务器的持续追踪中，我们发现其指向的活动暂未与公开已知 APT 情报匹配。为便于后续描述，暂以AyutMesh 活动簇对其进行跟踪。该命名来自两个相对稳定的线索：MeshCentral C2 域名ayut****.com，以及攻击者使用 MeshCentral 进行远控持久化和资产管理的行为。

AyutMesh 值得关注的地方，不在于使用了多么罕见的 0day。恰恰相反，从泄露文件看，它更多依赖已知漏洞、常见企业应用入口和远控平台，并通过 AI 辅助和自动化脚本快速迭代。泄露的 MeshCentral 导出数据中，已经出现多个国家、多类行业的受控/纳管服务器，涉及 3BB、泰国财政部、春武里府学习促进办公室等单位，以及教育机构和制造业相关资产。

这不是低水平自动化脚本偶然碰撞出来的结果。更准确地说，它体现的是具备一定能力的攻击者叠加 AI 自动化后的放大效应，攻击门槛被降低，迭代速度被拉高，攻击者即使不依赖 0day，也能在较低成本下扩大控制面。与此同时，当作业节奏加快、临时基础设施频繁创建和丢弃，文件服务器忘记关闭这类低级疏忽也更容易出现。

图 2：文件服务器目录页截图

AyutMesh 活动时间线

这批文件的关键不在单个脚本，而在于文件时间和动作类型能够互相印证。按时间顺序看，AyutMesh 的主要动作大致如下。

从 6 月 2 日下午的文件看，攻击者并不是停留在外部探测阶段。本地提权、WebShell、MeshAgent 配置与清理脚本已经同时出现，说明其至少在某个 3BB 相关主机上进入主机侧操作。后续文件也不再只是从零开始的扫描记录，而是围绕已有落点继续扩展的作业痕迹。

6 月 3 日与 6 月 9 日的区别在于目标面发生了变化。6 月 3 日的文件集中围绕***.3bb.co.th、***.3bb.co.th:10443以及相关 Web 入口展开，更偏公网业务系统和边界设备验证；6 月 9 日开始，大量10.11.*地址、数据库服务、phpMyAdmin、Pentaho/Kettle、Tomcat/Ghostcat 出现，目标面转向内部地址段和企业组件。

6 月 10 日泄露的devices.json将视角从单台主机拉到攻击者控制台。64 个受控/纳管节点被按组织和区域分组，其中 3BB 相关资产单独归入TH-3bb；除此之外，还能看到泰国、印度方向的其他组织资产池。这意味着该文件服务器暴露的不只是一次针对 3BB 的作业痕迹，也暴露了攻击者更大的远控资产面。

从脚本到远控的攻击链

文件中并没有一条单一的利用链，而是多条路径同时推进。可见的方向包括：

• 公网应用枚举：SQL 报错、业务路径枚举、CodeIgniter 会话相关尝试。
• 边界设备验证：FortiGate SSL-VPNCVE-2024-21762的验证与利用尝试。
• 历史漏洞方向：F5 BIG-IP TMUICVE-2020-5902探测、Tomcat AJP GhostcatCVE-2020-1938方向脚本。
• 本地提权方向：Dirty COWCVE-2016-5195、PwnKitCVE-2021-4034相关文件。
• 企业应用利用尝试：phpMyAdmin、MySQL 写文件、Pentaho/Kettle、Tomcat/JSP 等。
• 持久化与远控：WebShell 痕迹、MeshCentral Agent 投放。
• 控制台资产管理：devices.json泄露 64 个受控/纳管节点。

确认度最高的线索集中在 WebShell、MeshAgent 配置、清理脚本、devices.json和got63.txt。FortiGate、F5、Ghostcat 等方向更多体现为验证和利用尝试。整体看，攻击者一边围绕公网入口和边界设备寻找突破口，一边在已进入的环境内提权、落地并接入远控。

MeshCentral 控制面

这批文件中多次出现 MeshCentral 相关痕迹，包括 Agent 配置、安装脚本、清理脚本、控制台导出数据和命令回显。结合这些文件可以看到，攻击者通过 MeshCentral 接入主机、维持远控，并管理已经纳管的资产。

攻击者并不是只靠一次性脚本执行，而是将部分主机接入可持续使用的远控面板。

文件中还出现了隐藏 PHP 后门及清理脚本痕迹，说明攻击者并非只停留在探测阶段，而是存在主机侧落地和痕迹清理行为。

受影响范围

受影响资产中，3BB 相关主机的证据最完整。3BB 全称为泰国 TRIPLE T 宽带公众有限公司（TRIPLE T BROAD BAND PUBLIC COMPANY LIMITED），文件服务器中存在大量围绕 3BB 的攻击过程文件，MeshCentral 中也可以看到相关主机上线。导出的devices.json共包含64 个受控/纳管节点，除 3BB 相关资产外，还能看到泰国、印度方向的多类资产线索。

下表只列出其中单位归属特征较明显的部分：

FortiGate 防火墙资产是另一个明显关注点。失陷或纳管 IP 中可以看到多个 FortiGate 相关资产，文件服务器中也保留了 FortiGate SSL-VPNCVE-2024-21762的验证与利用尝试。当前文件未发现明显 0day 武器化特征，整体表现为围绕已知漏洞、历史漏洞和常见企业应用入口的高频迭代测试。结合前文提到的 FortiBleed 事件可以看到，FortiGate 设备正在成为多个不同攻击群体的共同关注点——无论是大规模凭证收割还是定向渗透，边界防火墙都是首选入口。

AI自动化痕迹

这批文件里更突出的不是某个高级漏洞，而是自动化迭代密度。短时间内大量脚本围绕不同组件连续生成，命名、输出和注释风格高度一致。

这些脚本并不只是单纯发送请求，而是在脚本内嵌入"预期行为、测试阶段、判断结论、风险评估"等文本输出，呈现出明显的报告化和模板化特征。部分脚本还保留了失败原因和下一步尝试，这种写法不像一次性手写脚本，更接近批量生成后的结果。

当前文件中没有出现明确的 AI 产品、模型名称或生成记录，不能确认具体工具来源。但短时间批量生成、推理式注释、跨组件 checklist 式枚举，以及脚本中"测试 - 判断 - 总结"的报告化风格叠在一起，可以判断该活动簇高概率使用了 AI 辅助攻击。

恶意域名真实IP

泄露文件中出现的 MeshCentral C2 域名为www.ayut***.com。使用 FOFA 以host="ayut***.com"检索，可以观察到该域名在 2026 年 1 月曾关联到泰国 IP157.85.*.*。虽然当前域名已经经过 Cloudflare，但该 IP 仍可直接访问，并且证书信息仍显示为www.ayut***.com。

图 3：通过 FOFA 关联域名历史解析记录，可见该域名曾指向157.85.**.***

图 4：直接访问该 IP 时，证书仍显示为www.ayut***.com

利用 FOFA 数据成功找到该 C2 CDN 后的真实 IP157.85.**.***。

IOC

AyutMesh 并不只是单点漏洞验证，而是围绕边界设备、常见企业应用和远控平台持续迭代。其对 FortiGate 防火墙资产关注度较高，文件服务器中未发现明显的 0day 武器化痕迹，呈现出借助AI 自动化提高渗透迭代效率的特征。

▌降低暴露风险的低成本做法

同样的暴露风险也存在于安全测试人员一侧。python -m http.server之所以被广泛使用，核心原因是足够方便：标准库自带，无需安装，一行命令即可启动。但它没有任何内置的认证或访问控制机制，启动后任何人都可以访问目录内容。常见的应对思路有两种，但各有代价：

两种方案都能解决问题，但都牺牲了"进入目录、一行启动"的便利性。对临时文件投递来说，任何多出来的步骤都会降低使用概率，这也是http.server难以被彻底替代的原因。如何在保持这种便利的同时获得基本的安全性？可以利用http.server自身的一个行为：访问目录时它会优先查找index.html，存在则返回该文件，不存在才生成目录列表。

echo 404 > index.html python3 -m http.server 8000

根路径就不会再自动列出目录。访问者打开http://ip:8000/时，看到的是index.html的内容，而不是当前目录下的所有文件。

图 5：根目录放置index.html后，访问根路径不再展示目录索引

如果愿意再多做一步，可以把真实文件放到一个不易猜到的子目录中，例如：

webroot/ ├── index.html └── f8a3c142de99860/ ├── exploit.py ├── report.md ├── result/ ├── src.zip └── target.txt

然后通过--directory指向这个临时 Web 根目录：

python3 -m http.server 8000 --directory ./webroot

这时访问根路径只会命中webroot/index.html，而知道路径的人访问/f8a3c142de99860/，仍然可以正常看到共享目录。相当于用路径充当简易访问口令。

图 6：访问指定路径后，仍然可以正常浏览共享文件

上述分析路径——从发现公开目录，到还原工具链，再到关联基础设施——即是将一次暴露转化为可用情报的过程。但这类目录往往存活时间有限，手工追踪难以为继。

我们的情报狩猎平台将这一过程系统化：依托 FOFA 在资产测绘领域的能力，持续监控文件服务器资产变更，通过 AI 摘要快速标定高价值内容，并将提取的 IOC 纳入关联分析流程，让公开目录从一次性发现变为可持续运营的情报来源。如有感兴趣的研究者欢迎联系交流。

图 7：IOC 平台中的文件服务器分析视图

公开目录是攻击者的疏忽，也是防御者的窗口。