企业官网建设流程全解析

1. 项目概述：Decepticon，一个为专业红队而生的自主黑客智能体

在网络安全领域，尤其是红队测试中，我们常常面临一个困境：攻击面在指数级增长，而人的精力和时间却是线性的。传统的渗透测试工具链虽然强大，但高度依赖操作员的经验、临场判断和大量重复性劳动。从信息收集、漏洞利用到横向移动和权限维持，每一步都需要手动执行、分析结果并决策下一步。这个过程不仅耗时，而且容易因疲劳导致疏漏。与此同时，AI领域的发展催生了一批“AI黑客”工具，它们往往演示起来很酷——比如让大语言模型运行一个nmap扫描——但实际落地到真实的、受规则约束的红队行动中时，就显得力不从心，要么是玩具，要么在合规性上存在巨大风险。

Decepticon的出现，正是为了弥合这道鸿沟。它不是一个简单的“AI调用扫描脚本”的工具，而是一个为专业红队测试设计的自主操作平台。它的核心目标不是降低黑客的门槛，而是将红队专家从繁琐、重复的战术执行中解放出来，让他们能更专注于战略制定、规则审定和那些需要人类直觉与创造力的高级威胁模拟。简单来说，Decepticon试图回答一个问题：如果一个经验丰富的红队成员，拥有无限的耐心、不会犯错的操作记忆、并能以机器速度执行战术，他会怎么做？这个项目就是将这个设想工程化的产物。

2. 核心理念与设计哲学：超越漏洞扫描的自主红队

2.1 红队测试与渗透测试的本质区别

在深入技术细节前，必须厘清一个关键概念：Decepticon定位为“自主红队平台”，而非“自动化渗透测试工具”。这两者有本质区别。渗透测试（Penetration Testing）通常以发现和报告漏洞为目标，过程相对线性，遵循预定义的测试用例清单。而红队测试（Red Team Testing）的目标是模拟特定威胁行为者的完整攻击链，以评估组织的整体检测与响应能力。它更关注“故事”的完整性：攻击者如何突破边界、建立立足点、提升权限、横向移动、达成最终目标（如窃取核心数据），以及在整个过程中是否被蓝队发现。

Decepticon的设计完全遵循红队测试的范式。它不满足于生成一份漏洞报告，而是追求执行一个完整的、有上下文的“攻击行动”。这意味着它需要理解并遵守一系列专业红队行动才有的约束和文档，例如：

• 行动规则（Rules of Engagement, RoE）：明确规定了测试的范围、允许的时间窗口、禁止攻击的系统或服务、使用的源IP范围等。这是合法性的基石，Decepticon的每一个自主决策都必须在此框架内进行。
• 行动概念（Concept of Operations, ConOps）：定义了本次模拟的威胁行为者画像（例如，是出于经济动机的犯罪团伙还是国家背景的APT组织），以及其典型的战术、技术和程序（TTPs）。这决定了Decepticon会优先尝试哪些攻击路径。
• 行动方案（Operations Plan, OPPLAN）：具体的攻击计划，将宏观目标分解为可执行的阶段性任务（Objectives），并映射到MITRE ATT&CK框架的技术编号。

2.2 “进攻即疫苗”的防御进化观

Decepticon项目背后有一个更宏大的愿景，我称之为“进攻即疫苗”（Offense as a Vaccine）。当前大多数“进攻性AI”项目止步于“展示攻击能力”，这就像制造了一种病毒，然后就此打住。而Decepticon的终极目标是成为防御体系进化的催化剂。

其逻辑链条是这样的：首先，构建一个世界级的自主进攻智能体（Step 1）。然后，利用这个智能体对目标环境发起持续、多样化的模拟攻击，产生海量的、真实的攻击数据流（Step 2）。最后，也是最重要的，将这些攻击数据反馈给防御方（蓝队），用于打磨检测规则、优化响应流程、验证安全控制的有效性，从而驱动防御体系不断进化（Step 3）。这就像接种疫苗：将经过处理的“病原体”（模拟攻击）注入系统，刺激其产生“抗体”（更强的防御能力）。因此，Decepticon的价值不仅在于它“能攻”，更在于它通过持续不断的“攻”来锻造更坚固的“防”。

3. 核心架构解析：隔离、交互与状态管理

3.1 双网络隔离架构

安全是红队工具的命脉。一个红队工具如果自身不安全，导致操作员凭证泄露或攻击流量溯源到管理平台，将是灾难性的。Decepticon在架构层面通过严格的网络隔离解决了这个问题。

整个系统运行在两个完全独立的Docker网络中：

• 管理网络（decepticon-net）：承载所有“大脑”部件。包括LLM网关（LiteLLM代理）、智能体API服务器、数据库（用于存储任务状态和结果）、以及Web界面（如果有的话）。这个网络不直接接触目标环境。
• 操作网络（sandbox-net）：一个硬化的Kali Linux沙箱环境。所有对目标的扫描、漏洞利用、后渗透等命令，都在这个沙箱中执行。沙箱内预装了完整的红队工具链，如nmap、Sliver C2客户端、sqlmap、Impacket套件等。

两个网络之间没有直接的网络连通性。智能体（运行在管理网络）对沙箱的控制，是通过Docker守护进程套接字（Docker Socket）实现的。智能体向编排器发送指令，编排器通过Docker API在沙箱容器内创建新的执行会话（使用docker exec），并捕获其输出。这意味着，即使沙箱被攻陷，攻击者也无法通过网络跳板攻击到后端的LLM或数据库。

实操心得：这种基于Docker Socket的控制方式，相比传统的SSH或Agent，提供了更好的隔离性和控制粒度。但在生产部署时，务必确保Docker守护进程本身的安全，因为对Docker Socket的访问等同于主机root权限。建议在专用的红队服务器上运行Decepticon，并严格限制对该服务器的访问。

3.2 基于LangGraph的多智能体协作

Decepticon没有采用单一的、全能的“超级智能体”模型，而是设计了五个各司其职的专家智能体，它们在一个由LangGraph驱动的有状态工作流中协作：

1. Soundwave：负责战前访谈与规划。它像项目经理一样，与操作员交互，生成完整的Engagement Package（包含RoE, ConOps, OPPLAN）。
2. Decepticon（Orchestrator）：总指挥。它读取OPPLAN，决定当前应该执行哪个目标（Objective），并根据目标类型和当前上下文，调用相应的专家智能体。
3. Recon：侦察专家。负责信息收集、端口扫描、服务识别、目录枚举等。
4. Exploit：漏洞利用专家。负责分析侦察结果，寻找并利用漏洞获取初始访问权限。
5. Post-Exploit：后渗透专家。负责在获得立足点后的所有操作，包括权限提升、凭证窃取、横向移动、持久化等。

每个智能体在接到任务时，都会在一个全新的、干净的上下文窗口中启动。这是为了避免在长对话中常见的“上下文污染”或“记忆退化”问题。智能体完成任务后，其产生的“发现”（Findings）会被持久化到文件系统或数据库中，而不是留在智能体的记忆里。然后，该智能体实例被销毁。下一个任务到来时，Orchestrator会重新实例化一个干净的智能体，并将必要的上下文（如RoE、之前的发现）作为提示词的一部分注入。这种设计保证了每个决策都基于最新、最相关的信息，且不会因历史对话的噪音而降低推理质量。

3.3 交互式会话的挑战与解决方案

这是Decepticon与大多数AI安全工具拉开差距的关键一点。真正的红队工具，如Metasploit的msfconsole、Sliver C2的sliver-client、或者WinRM/Psexec会话，都是交互式的。它们提供一个持续的提示符，等待操作员输入一系列命令，并可能根据上一条命令的输出动态调整下一条命令。

大多数AI智能体通过简单的subprocess.run()来执行命令，这适用于单次执行并退出的命令（如nmap -sV 192.168.1.1），但完全无法处理交互式工具。Decepticon通过tmux会话和智能的提示符检测机制解决了这个问题。

其工作流程如下：

1. 当智能体需要运行一个可能产生交互式会话的命令（例如，启动sliver-client）时，它会在沙箱容器内创建一个新的tmux会话。
2. 命令在该tmux会话中执行。
3. 一个后台进程持续监控tmux会话的输出，使用正则表达式检测常见的交互式提示符（如sliver >，msf6 exploit(handler) >，PS C:\Users\Victim>）。
4. 一旦检测到提示符，系统会认为上一条命令执行完毕，等待用户（此处是AI智能体）输入。此时，智能体生成的下一句命令会被发送到该tmux会话。
5. 这个过程可以持续进行，模拟人类操作员与工具的交互。系统还能处理控制信号（如Ctrl+C中断、Ctrl+Z挂起）和会话超时。

注意事项：提示符检测的准确性至关重要。如果正则表达式匹配不精确，可能导致智能体在工具还未准备好时就发送下一条命令，造成混乱。Decepticon的代码库中包含了对多种常见红队工具提示符的预定义模式，但在集成新工具时，需要仔细测试和调整。

4. 实战部署与核心功能演练

4.1 环境准备与一键安装

Decepticon极力简化了部署流程，核心依赖只有Docker和Docker Compose V2。这保证了环境的一致性，避免了“在我的机器上能运行”的经典问题。

安装只需一行命令：

curl -fsSL https://decepticon.red/install | bash

这条命令会下载安装脚本，自动拉取所需的Docker镜像，并设置命令行工具。

安装完成后，需要进行关键的一步配置：设置AI模型的API密钥。

decepticon config

执行后会进入一个交互式配置界面。你需要提供至少一个LLM供应商的API密钥，例如Anthropic的Claude或OpenAI的GPT。Decepticon通过LiteLLM支持多模型路由，你可以配置多个备用密钥和模型。

4.2 运行演示：体验完整攻击链

对于新手，最快了解Decepticon能力的方式是运行其内置演示。

decepticon demo

这个演示脚本会自动化完成以下工作：

1. 启动目标：在隔离网络中启动一个Metasploitable 2虚拟机（一个故意包含多种漏洞的Linux靶机）。
2. 加载预置任务：载入一个为演示预构建的Engagement Package，其中包含了RoE、ConOps和OPPLAN。
3. 执行完整攻击链：
   • 侦察：Recon智能体对靶机进行端口扫描，发现开放的21端口（FTP）运行着存在漏洞的vsftpd 2.3.4。
   • 初始访问：Exploit智能体利用vsftpd的后门漏洞，获得一个反向Shell。
   • 命令与控制：Post-Exploit智能体在靶机上部署Sliver C2的植入物（implant），建立稳定的C2通道。
   • 后渗透：通过Sliver会话，在靶机上进行凭证窃取（例如，转储/etc/shadow），并尝试进行内网侦察（如果靶机有多网卡）。
4. 实时观察：所有步骤都会在CLI界面中实时流式输出，你可以看到每个智能体的“思考过程”（推理链）、它打算执行的命令、以及命令的实际输出。

这个演示完美展示了Decepticon如何将多个离散的步骤（扫描、利用、部署C2、横向移动）串联成一个连贯的、自主执行的攻击故事。

4.3 创建自定义任务

真实场景中，你需要针对特定目标创建自己的任务。流程如下：

1. 启动Decepticon：在终端运行decepticon。这会启动所有后台服务并打开交互式CLI。
2. 规划阶段：CLI启动后，Soundwave智能体会主动与你对话，引导你完成Engagement Planning。它会询问一系列问题，例如：
   • 任务名称和描述？
   • 目标IP或域名范围？（必须严格遵守RoE中的授权范围）
   • 模拟的威胁行为者是谁？（例如，金融犯罪团伙、APT29）
   • 有哪些禁止项？（例如，不得对生产数据库执行DROP操作，不得在业务高峰时段扫描）
   • 最终目标是什么？（例如，获取域控权限，窃取指定文件）
3. 生成文档：基于你的回答，Soundwave会自动生成RoE、ConOps、Deconfliction Plan和OPPLAN的Markdown文件，保存在项目目录中。你可以随时审阅和修改这些文件。
4. 执行阶段：确认文档无误后，将控制权交给Orchestrator（Decepticon）。它会读取OPPLAN，开始自主执行任务。你可以在CLI中实时监控进度，看到每个目标的完成状态（PENDING, IN_PROGRESS, COMPLETED, BLOCKED）。

4.4 C2集成与后渗透自动化

Decepticon深度集成了Sliver C2框架，这是其区别于很多学术性AI安全项目的另一个亮点。Sliver是一个功能强大的、Go语言编写的跨平台C2框架，支持多种通信协议（HTTP/S, DNS, MTLS）和丰富的后渗透模块。

在Decepticon中，Sliver的团队服务器（Team Server）运行在操作网络（sandbox-net）中。沙箱内的Kali系统预配置了sliver-client，并自动连接到此服务器。当Exploit或Post-Exploit智能体获得一个初始立足点（Shell）后，它们会执行以下操作：

1. 生成植入物：根据目标系统架构（Windows/Linux, x64/x86），智能体会指示Sliver服务器生成相应的植入物。
2. 投递与执行：利用已有的Shell会话，将植入物文件上传到目标并执行。这可能需要借助curl、wget、PowerShell下载或简单的文件复制。
3. 会话管理：植入物成功回调后，会在Sliver控制台建立一个新会话。此后，所有后续操作（文件操作、进程管理、凭证转储、横向移动）都通过这个Sliver会话来执行，这比不稳定的反向Shell可靠得多。
4. 自动化模块执行：智能体可以调用Sliver的内置模块，例如hashdump（转储Windows哈希）、make-token（创建令牌）、portfwd（端口转发）等，将这些操作无缝编织进其自主决策流程中。

5. 技能系统与MITRE ATT&CK映射

5.1 模块化技能库

Decepticon的智能体并非凭空想象攻击手段，它们的行为由一个模块化的“技能库”驱动。每个技能都是一个自包含的文档，通常是一个Markdown文件，描述了在特定情境下应采取的行动。

技能文件的结构包含两部分：

• Frontmatter（元数据）：以YAML格式写在文件开头，定义了技能的属性，如技能ID、名称、描述、适用的攻击阶段（Recon, Initial Access, Execution等）、以及对应的MITRE ATT&CK技术ID。
• 正文内容：详细描述了该技能的执行步骤、常用命令、参数解释以及预期结果。这部分内容只有在智能体决定使用该技能时，才会通过read_file()函数动态加载到其上下文中，这是一种节约上下文长度的优化策略。

例如，一个针对“SMB匿名共享枚举”的技能可能如下：

id: smb_anonymous_enum name: Enumerate SMB Shares (Anonymous) phase: Recon mitre: - T1135 - T1087.002 description: Attempt to list SMB shares on a target using anonymous/null session.

正文部分则会详细说明如何使用smbclient或crackmapexec进行枚举。

5.2 深度ATT&CK集成

MITRE ATT&CK框架是网络安全行业的通用语言。Decepticon将ATT&CK的集成做到了骨子里，而非事后添加的标签。

• 目标映射：OPPLAN中的每一个具体目标（Objective）都会关联一个或多个ATT&CK技术ID。例如，目标“获取初始访问权限”可能关联T1190（利用面向公众的应用程序）。
• 技能映射：每个技能在元数据中声明其对应的ATT&CK技术。当智能体使用该技能时，这个关联会被记录。
• 行为者画像映射：ConOps中定义的威胁行为者，其ttps字段直接使用ATT&CK技术ID列表来描述其惯用技战术。
• 报告生成：任务结束后，生成的活动报告会天然地按照ATT&CK矩阵进行归类，清晰地展示了攻击链在技术层面的覆盖情况，极大方便了与蓝队沟通和报告撰写。

这种深度集成确保了Decepticon的模拟攻击不仅是有效的，而且是符合行业标准、可审计、可追溯的。

6. 多模型路由与成本优化策略

大语言模型的API调用是持续运行Decepticon的主要成本。不同的任务对模型能力的需求不同：制定复杂计划需要最强的推理能力（如Claude 3 Opus），而执行一个简单的端口扫描命令则可以用更轻量、更便宜的模型（如Claude 3 Haiku）。

Decepticon通过LiteLLM代理和预定义的模型配置档（Profile）来实现智能路由和成本优化：

其工作流程是：当智能体需要调用LLM时，请求会发送给LiteLLM网关。网关根据当前激活的配置档和智能体类型，将请求路由到指定的模型。此外，网关还实现了自动故障转移机制。如果首选模型因配额不足或服务中断而失败，请求会自动降级路由到备用模型（例如，从Opus降级到GPT-4）。这一切对智能体是透明的，保证了任务的连续性。

实操心得：在长期使用中，eco配置档是平衡效果与成本的最佳选择。让Orchestrator使用最强的Opus模型来做出关键路径决策，让Sonnet处理复杂的漏洞利用逻辑，而让Hauki处理大量相对简单的侦察命令。这样可以将单次任务的成本降低30%-50%，而不明显影响成功率。

7. 常见问题与故障排查实录

在实际部署和运行Decepticon的过程中，你可能会遇到一些典型问题。以下是我在多次测试中积累的排查经验。

7.1 模型API调用失败

现象：智能体停止响应，CLI日志显示“API Error”或“Rate Limit Exceeded”。

排查步骤：

1. 检查配置：运行decepticon config确认API密钥填写正确，且没有多余的空格或换行。
2. 检查额度：登录你的OpenAI或Anthropic账户控制台，确认API额度或余额是否充足。
3. 检查网络：确保运行Decepticon的服务器可以正常访问外部LLM API（例如，能curl通https://api.anthropic.com）。
4. 查看详细日志：Decepticon的Docker Compose日志通常能提供更详细的错误信息。运行docker compose logs litellm来查看LiteLLM网关的日志。
5. 切换配置档：尝试在decepticon config中切换到test配置档（使用Haiku），以排除是否是特定模型的问题。

7.2 沙箱内命令执行超时或无响应

现象：任务卡在“Executing command…”状态，长时间没有进展。

排查步骤：

1. 检查目标连通性：首先确认目标主机是否存活，并且从沙箱容器内是否可以ping通或访问到目标端口。可以进入沙箱容器手动测试：docker compose exec sandbox bash，然后在容器内尝试nc -zv <target_ip> <port>。
2. 检查tmux会话：智能体的交互式命令在tmux中运行。可以列出沙箱内的tmux会话：docker compose exec sandbox tmux list-sessions。如果发现会话状态异常（Attached但无输出），可以尝试附着上去查看：docker compose exec sandbox tmux attach -t <session_name>。
3. 检查提示符检测：某些非标准或自定义的工具提示符可能未被正确识别。你需要检查该技能文件的描述，或手动在沙箱中运行该命令，观察其准确的提示符格式，并考虑向项目贡献新的提示符检测规则。
4. 资源限制：检查宿主机和Docker容器的CPU/内存使用情况。复杂的漏洞利用或大型扫描可能消耗大量资源，导致进程卡死。

7.3 Sliver C2会话建立失败

现象：Exploit阶段成功获得了Shell，但尝试部署Sliver植入物时失败，无法建立C2会话。

排查步骤：

1. 确认Sliver服务器状态：运行docker compose logs c2-sliver查看Sliver团队服务器的日志，确认其已正常启动并在监听。
2. 检查网络策略：确保目标主机（靶机）能够访问到Sliver服务器所在的IP和端口。由于它们同在sandbox-net中，理论上应能互通。检查靶机防火墙是否出站。
3. 检查植入物生成：在Sliver控制台（可通过docker compose exec c2-sliver ./sliver-server进入）使用implants命令查看生成的植入物列表，确认生成成功且架构匹配。
4. 检查投递与执行：查看智能体在靶机Shell中执行的具体命令。有时因为权限问题，上传文件或执行文件会失败。可能需要智能体先进行提权操作。

7.4 智能体陷入循环或做出错误决策

现象：智能体反复执行同一个操作，或选择了一个明显无效的攻击路径。

排查步骤：

1. 审查RoE和OPPLAN：智能体的行动严格受RoE约束。检查是否RoE中的限制过于严格，导致智能体没有其他可行的路径。同时，检查OPPLAN中的目标定义是否清晰、无歧义。
2. 检查上下文：回忆一下，每个智能体实例都是全新的。如果它做出错误决策，很可能是提供给它的“上下文”（即提示词中的历史发现和当前状态）不准确或不充分。查看该任务轮次的完整日志，分析智能体接收到的提示词。
3. 模型温度参数：过高的“温度”（temperature）设置可能导致模型输出随机性太大。在decepticon config中，可以尝试调低相关模型的温度参数（例如从0.7调到0.3），使其输出更确定、更可预测。
4. 技能库不足：如果当前场景非常特殊，而技能库中没有匹配的技能，智能体可能会尝试用不合适的通用技能去套用，导致失败。这时需要你作为操作员进行人工干预，或者事后为该场景贡献一个新的技能文档。

8. 开发与贡献指南

Decepticon是一个开源项目，其演进依赖于社区贡献。如果你是一名安全研究员或开发者，想要为其添砖加瓦，以下是参与路径。

8.1 开发环境搭建

项目使用make命令来管理开发流程，非常便捷。

git clone https://github.com/PurpleAILAB/Decepticon.git cd Decepticon make dev # 构建镜像并以开发模式启动（支持代码热重载）

在另一个终端中，运行make cli即可打开交互式CLI进行测试。make dev命令利用了Docker Compose的watch功能，当你修改本地源代码时，改动会自动同步到容器内，无需手动重建镜像，极大提升了开发效率。

8.2 主要贡献方向

1. 扩充技能库：这是最直接、也最宝贵的贡献。将你的红队经验转化为结构化的技能文档。参考skills/目录下的现有文件格式，确保包含清晰的元数据（MITRE ID、攻击阶段）和详细的、可操作的步骤说明。
2. 集成新工具：如果你擅长某个未被集成的红队工具（例如，Cobalt Strike, Covenant, Mythic等），可以为其编写适配层。这包括：确保该工具能安装在Kali沙箱中、编写对应的Dockerfile修改、以及最重要的，为其交互式提示符编写检测逻辑。
3. 改进智能体提示词：智能体的核心能力很大程度上受其系统提示词（System Prompt）影响。如果你有提示工程的经验，可以尝试优化agents/目录下各个智能体的提示词，使其决策更精准、更符合红队思维。
4. 修复Bug与改进UI：提交Issue报告你遇到的问题，或者直接修复代码中的Bug。CLI界面（基于Ink）的体验优化也是很好的贡献点。

8.3 测试与代码规范

在提交Pull Request前，请确保你的代码通过基础检查。

make test # 在容器内运行pytest测试套件 make lint # 在本地运行代码格式化和类型检查（需要先运行 `uv sync --dev` 安装开发依赖）

项目遵循基本的Python代码规范（如Black, isort）。清晰的提交信息（Commit Message）和关联的Issue编号会让你的PR更容易被合并。

从我个人的使用和测试经验来看，Decepticon代表了AI在实战安全领域一个非常务实且前景广阔的方向。它没有沉迷于生成炫酷的漏洞利用代码（这目前仍超出LLM的可靠能力），而是将AI定位为“战术执行自动化引擎”和“决策辅助大脑”，将人类专家从重复劳动中解放出来，去处理更高级别的策略问题。它的双网络架构、基于tmux的交互式会话处理、以及对红队专业流程（RoE, OPPLAN）的尊重，都显示出这是一个由深度行业认知驱动的项目，而非简单的技术拼凑。当然，它仍处于活跃开发阶段，在处理极其复杂、需要大量上下文推理的漏洞链时可能会遇到挑战，但这正是社区贡献和模型本身进化所能解决的问题。对于任何严肃的红队团队而言，将Decepticon纳入工具链进行探索和定制，无疑是提前布局未来工作模式的一步好棋。