Anthropic-Cybersecurity-Skills 实战Stuxnet 风格攻击检测指南——基于 PLC 逻辑完整性监控与物理过程异常检测【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI 20 platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills本文以 detecting-stuxnet-style-attacks 技能为核心面向需要在 ICS/SCADA 环境中为高价值 OT 目标核设施、化工、关键基础设施构建纵深防御的安全团队与 AI Agent。读完本文你将掌握Stuxnet 五阶段攻击链的检测机会映射、PLC 程序逻辑的已知基线完整性监控、基于物理模型的传感器欺骗异常检测以及覆盖 S7comm/Modbus 协议与工程工作站 IOC 的落地检测手段。适用范围与前置条件何时使用该技能在以下场景中应激活该技能原文档 SKILL.md 明确列出的触发条件为高价值 OT 目标核设施、化工、关键基础设施实施高级威胁检测构建针对 PLC 逻辑与过程操纵类 APT 攻击的检测能力建立 PLC 逻辑完整性监控以发现未授权的程序修改调查疑似物理过程异常的线索判断是否属于网络物理攻击cyber-physical attack设计针对国家级 OT 威胁的纵深防御策略。不适用场景基础的 OT 入侵检测应转向 detecting-attacks-on-scada-systemsStuxnet 样本的恶意软件逆向分析应交给仓库中的逆向工程类技能PLC 编程与逻辑开发不在本技能范围内。前置条件深入理解 Stuxnet 攻击链与 MITRE ATTCK for ICS 框架拥有 PLC 逻辑备份仓库保存所有 PLC 程序的已知良好基线known-good baseline工程工作站具备 OT 感知能力的 EDR 监控为受控物理过程建立基于物理原理的过程模型具备工业协议流量的网络监控能力。Step 1理解 Stuxnet 攻击链逐阶段规划检测点Stuxnet 式攻击的关键在于跨越多阶段的组合手法从 USB 摆渡突破隔离网到内网横向移动、攻陷工程工作站、注入 PLC 逻辑最后在篡改物理过程的同时伪造传感器读数。原文档将攻击链拆为五个阶段并逐一给出 MITRE ICS 技术与检测要点完整映射如下# Stuxnet-Style Attack Chain and Detection Points attack_chain: stage_1_initial_access: technique: USB-borne malware targeting air-gapped network mitre_ics: T0847 - Replication Through Removable Media detection: - USB device connection logging on engineering workstations - Removable media scanning with OT-approved AV - Application allowlisting blocking unauthorized executables - Windows autorun disabled via Group Policy indicators: - New USB device connections to engineering workstations - Execution of unsigned binaries from removable media - LNK file exploitation patterns stage_2_lateral_movement: technique: Exploitation of Windows vulnerabilities for network propagation mitre_ics: T0866 - Exploitation of Remote Services detection: - Network IDS detecting exploit traffic (MS08-067, MS10-061) - Unusual SMB traffic between engineering workstations - Windows event logs showing privilege escalation - New scheduled tasks or services created indicators: - Lateral movement between Level 3-4 Windows systems - WMI/PsExec execution from unexpected sources - Pass-the-hash authentication patterns stage_3_ews_compromise: technique: Compromise of engineering workstation with PLC programming software mitre_ics: T0862 - Supply Chain Compromise (Step-7 hooking) detection: - File integrity monitoring on Step-7/TIA Portal directories - DLL injection detection in PLC programming software - Monitoring s7otbxdx.dll for Stuxnet-specific hook - Unexpected modifications to PLC project files indicators: - Modified DLLs in Siemens STEP 7 installation directory - Rootkit hiding files on engineering workstation - PLC programming software behaving abnormally stage_4_plc_logic_modification: technique: Injecting malicious OB/FC blocks into PLC program mitre_ics: T0839 - Module Firmware / T0833 - Modify Control Logic detection: - PLC logic integrity comparison against known-good baseline - S7comm upload/download traffic from unauthorized sources - New OB/FC/FB blocks appearing in PLC program - Modification of OB1 (main scan) or OB35 (cyclic interrupt) indicators: - PLC program block count changes - PLC program size changes - Upload of unknown program blocks stage_5_process_manipulation: technique: Manipulating physical process while spoofing sensor readings mitre_ics: T0836 - Modify Parameter / T0856 - Spoof Reporting Message detection: - Physics-based anomaly detection (process model deviation) - Cross-validation of independent sensors - Vibration analysis and mechanical signature monitoring - Comparison of PLC-reported values vs independent measurements indicators: - Motor/pump operating outside normal parameters - Sensor readings diverging from physics model predictions - Process efficiency metrics deviating unexpectedly该技能在仓库中的 MITRE 映射情况已在 ATTACK_COVERAGE.md 中登记覆盖 T0833修改控制逻辑、T0836修改参数、T0839模块固件、T0847通过可移动介质复制、T0856伪造报告消息、T0862供应链入侵、T0866远程服务利用共 7 个 ICS 技术覆盖了从初始访问到过程操纵的完整杀伤链。Step 2实现 PLC 逻辑完整性监控攻击者注入恶意 OB/FC/FB 块后PLC 程序与已知基线之间必然产生差异。完整性监控的核心思路是周期性采集 PLC 程序块信息类型、编号、大小、校验和与基线比对识别新增块、删除块、块内容被篡改与块数量变化四类异常。原文档提供了可直接运行的监控器骨架#!/usr/bin/env python3 PLC Logic Integrity Monitor. Periodically retrieves PLC program block information and compares against known-good baselines to detect unauthorized modifications (Stuxnet-style logic injection). import hashlib import json import sys import time from dataclasses import dataclass, field, asdict from datetime import datetime dataclass class PLCBlock: Represents a PLC program block. block_type: str # OB, FC, FB, DB block_number: int name: str size_bytes: int checksum: str last_modified: str author: str dataclass class IntegrityAlert: alert_id: str timestamp: str severity: str plc_name: str plc_ip: str alert_type: str description: str baseline_value: str current_value: str mitre_technique: str class PLCIntegrityMonitor: Monitors PLC program integrity against baselines. def __init__(self): self.baselines {} # plc_name - list of PLCBlock self.alerts [] self.alert_counter 1 def load_baseline(self, plc_name, baseline_file): Load known-good PLC program baseline. with open(baseline_file) as f: data json.load(f) blocks [PLCBlock(**b) for b in data.get(blocks, [])] self.baselines[plc_name] { blocks: {f{b.block_type}{b.block_number}: b for b in blocks}, total_blocks: len(blocks), loaded_at: datetime.now().isoformat(), } print(f[*] Loaded baseline for {plc_name}: {len(blocks)} blocks) def check_integrity(self, plc_name, plc_ip, current_blocks): Compare current PLC program against baseline. baseline self.baselines.get(plc_name) if not baseline: print(f[WARN] No baseline for {plc_name}) return baseline_blocks baseline[blocks] current_block_map {f{b.block_type}{b.block_number}: b for b in current_blocks} # Check 1: New blocks added (potential logic injection) for key, block in current_block_map.items(): if key not in baseline_blocks: self.alerts.append(IntegrityAlert( alert_idfINT-{self.alert_counter:04d}, timestampdatetime.now().isoformat(), severitycritical, plc_nameplc_name, plc_ipplc_ip, alert_typeNEW_BLOCK_DETECTED, description( fNew program block {key} ({block.name}) found in PLC fthat does not exist in baseline. Size: {block.size_bytes} bytes. ), baseline_valueBlock does not exist in baseline, current_valuef{key}: {block.size_bytes} bytes, checksum {block.checksum}, mitre_techniqueT0839 - Module Firmware / T0833 - Modify Control Logic, )) self.alert_counter 1 # Check 2: Blocks removed for key in baseline_blocks: if key not in current_block_map: self.alerts.append(IntegrityAlert( alert_idfINT-{self.alert_counter:04d}, timestampdatetime.now().isoformat(), severityhigh, plc_nameplc_name, plc_ipplc_ip, alert_typeBLOCK_REMOVED, descriptionfProgram block {key} removed from PLC, baseline_valuef{key}: {baseline_blocks[key].size_bytes} bytes, current_valueBlock not found, mitre_techniqueT0833 - Modify Control Logic, )) self.alert_counter 1 # Check 3: Block content modified (checksum mismatch) for key in baseline_blocks: if key in current_block_map: baseline_block baseline_blocks[key] current_block current_block_map[key] if baseline_block.checksum ! current_block.checksum: self.alerts.append(IntegrityAlert( alert_idfINT-{self.alert_counter:04d}, timestampdatetime.now().isoformat(), severitycritical, plc_nameplc_name, plc_ipplc_ip, alert_typeBLOCK_MODIFIED, description( fProgram block {key} checksum mismatch. fLogic has been modified since baseline was established. ), baseline_valuefChecksum: {baseline_block.checksum}, Size: {baseline_block.size_bytes}, current_valuefChecksum: {current_block.checksum}, Size: {current_block.size_bytes}, mitre_techniqueT0833 - Modify Control Logic, )) self.alert_counter 1 # Check 4: Block count change if len(current_blocks) ! baseline[total_blocks]: self.alerts.append(IntegrityAlert( alert_idfINT-{self.alert_counter:04d}, timestampdatetime.now().isoformat(), severityhigh, plc_nameplc_name, plc_ipplc_ip, alert_typeBLOCK_COUNT_CHANGE, descriptionfTotal block count changed from {baseline[total_blocks]} to {len(current_blocks)}, baseline_valuestr(baseline[total_blocks]), current_valuestr(len(current_blocks)), mitre_techniqueT0833 - Modify Control Logic, )) self.alert_counter 1 def generate_report(self): Generate integrity monitoring report. print(f\n{*70}) print(PLC LOGIC INTEGRITY MONITORING REPORT) print(f{*70}) print(fBaselines loaded: {len(self.baselines)}) print(fAlerts: {len(self.alerts)}) for a in self.alerts: print(f\n [{a.severity.upper()}] {a.alert_type}) print(f PLC: {a.plc_name} ({a.plc_ip})) print(f {a.description}) print(f Baseline: {a.baseline_value}) print(f Current: {a.current_value}) print(f MITRE: {a.mitre_technique}) if __name__ __main__: monitor PLCIntegrityMonitor() print(PLC Logic Integrity Monitor) print(Load baselines and call check_integrity() periodically)监控器设计要点解析块标识键以block_type block_number如OB1、OB35、FC100作为主键。参考文档 references/api-reference.md 中列出的 Siemens STEP 7 项目结构OB1 是主程序扫描循环、OB35 是 100ms 周期中断、OB100 是启动组织块——Stuxnet 正是通过篡改 OB1/OB35 实现周期性的恶意逻辑触发因此这些块必须被重点保护。四类检测逻辑NEW_BLOCK_DETECTED新增块指向逻辑注入映射 T0839/T0833、BLOCK_REMOVED块被删除、BLOCK_MODIFIED校验和不匹配映射 T0833、BLOCK_COUNT_CHANGE块数量变化。基线管理load_baseline()从 JSON 文件加载已知良好程序快照并缓存在生产环境应配合版本管理任何基线变更都必须走变更审批流程。从协议层验证逻辑完整性S7comm 流量监控PLC 程序的上传/下载、启动/停止都发生在 S7comm 协议层。参考文档 references/api-reference.md 给出了关键参数功能码可直接用于 Wireshark/tshark 过滤器S7 参数功能码名称检测含义0x04Read Variable常规读操作0x05Write Variable变量写入需关注来源0x1ARequest Download请求下载程序块高危0x1BDownload Block实际下载块内容高危0x1CDownload Ended下载结束0x28PLC Control (Start/Stop)远程启停 PLC高危对应的 tshark 检测命令# S7comm block downloads tshark -r capture.pcap -Y s7comm.param.func 0x1a || s7comm.param.func 0x1b # S7comm PLC stop/start tshark -r capture.pcap -Y s7comm.param.func 0x28若网络中存在 Modbus 设备则需关注写功能码参考文档同时给出了 Modbus TCP 帧结构与风险等级功能码名称风险5Write Single Coil中6Write Single Register中15Write Multiple Coils高16Write Multiple Registers高22Mask Write Register高# Modbus write operations tshark -r capture.pcap -Y modbus.func_code 5 modbus.func_code 16在 SIEM/IDS 侧参考文档还提供了可直接落地的 Snort/Suricata 规则用于在 502 端口Modbus TCP上识别多寄存器写入alert tcp any any - any 502 (msg:Modbus Write Multiple Registers; content:|00 00|; offset:2; depth:2; byte_test:1,,16,7; sid:1000001;)需要深入 S7comm 协议安全分析的读者可进一步参考仓库中的 performing-s7comm-protocol-security-analysis 技能。Step 3部署基于物理模型的过程异常检测逻辑完整性监控解决程序被改的问题但 Stuxnet 的精髓在于物理过程被操纵的同时传感器读数被伪造——操作员看到的是一切正常的假象。为此需要引入基于物理原理的异常检测用物理定律预测传感器应有的取值一旦上报值与物理预测值背离说明要么设备故障要么传感器被欺骗cyber-physical attack。原文档给出了一个以离心机为对象的可运行检测器#!/usr/bin/env python3 Physics-Based Cyber-Physical Attack Detector. Uses simplified physics models to detect process manipulation attacks where the attacker modifies the physical process while spoofing sensor readings (the core Stuxnet attack pattern). import math from dataclasses import dataclass from datetime import datetime dataclass class PhysicsAlert: timestamp: str severity: str alert_type: str sensor_tag: str reported_value: float predicted_value: float deviation_percent: float description: str class CentrifugePhysicsModel: Physics model for a centrifuge system (Stuxnet target analog). Detects manipulation by cross-correlating: - Motor frequency (Hz) vs reported RPM - RPM vs vibration signature - Power consumption vs rotational speed def __init__(self, rated_rpm1200, rated_frequency50, rated_power_kw75): self.rated_rpm rated_rpm self.rated_frequency rated_frequency self.rated_power_kw rated_power_kw self.alerts [] def check_frequency_rpm_correlation(self, frequency_hz, reported_rpm): Verify motor frequency matches reported RPM. For an induction motor: RPM 120 * frequency / poles If RPM is being spoofed, it wont match the actual frequency. # Assuming 4-pole motor with typical 3% slip expected_rpm (120 * frequency_hz / 4) * 0.97 deviation abs(reported_rpm - expected_rpm) / expected_rpm * 100 if deviation 5.0: self.alerts.append(PhysicsAlert( timestampdatetime.now().isoformat(), severitycritical, alert_typeFREQUENCY_RPM_MISMATCH, sensor_tagMOTOR.RPM vs VFD.FREQ, reported_valuereported_rpm, predicted_valueround(expected_rpm, 1), deviation_percentround(deviation, 1), description( fMotor RPM ({reported_rpm}) does not match VFD frequency f({frequency_hz} Hz). Expected ~{expected_rpm:.0f} RPM. fPossible RPM sensor spoofing while frequency is manipulated. ), )) def check_power_speed_correlation(self, rpm, power_kw): Verify power consumption matches rotational speed. Power scales approximately with RPM^3 for centrifugal loads. speed_ratio rpm / self.rated_rpm expected_power self.rated_power_kw * (speed_ratio ** 3) deviation abs(power_kw - expected_power) / max(expected_power, 0.1) * 100 if deviation 15.0: self.alerts.append(PhysicsAlert( timestampdatetime.now().isoformat(), severityhigh, alert_typePOWER_SPEED_MISMATCH, sensor_tagMOTOR.POWER vs MOTOR.RPM, reported_valuepower_kw, predicted_valueround(expected_power, 1), deviation_percentround(deviation, 1), description( fPower consumption ({power_kw} kW) inconsistent with RPM ({rpm}). fExpected ~{expected_power:.1f} kW. May indicate hidden speed changes. ), )) def check_vibration_anomaly(self, rpm, vibration_mm_s): Check if vibration signature is consistent with operating speed. Abnormal vibration at reported normal speed may indicate actual speed is different from what sensors report. # Normal vibration increases linearly with speed for balanced rotor speed_ratio rpm / self.rated_rpm expected_vibration 2.0 * speed_ratio # mm/s baseline deviation abs(vibration_mm_s - expected_vibration) / max(expected_vibration, 0.1) * 100 if vibration_mm_s 7.0: # ISO 10816 alert threshold self.alerts.append(PhysicsAlert( timestampdatetime.now().isoformat(), severitycritical, alert_typeABNORMAL_VIBRATION, sensor_tagMOTOR.VIBRATION, reported_valuevibration_mm_s, predicted_valueround(expected_vibration, 1), deviation_percentround(deviation, 1), description( fVibration ({vibration_mm_s} mm/s) at ISO alert level while fRPM reports normal ({rpm}). Actual speed may differ from reported. ), )) def report(self): if self.alerts: print(f\n{*60}) print(PHYSICS-BASED ANOMALY DETECTION ALERTS) print(f{*60}) for a in self.alerts: print(f\n [{a.severity.upper()}] {a.alert_type}) print(f {a.description}) print(f Reported: {a.reported_value} | Predicted: {a.predicted_value}) print(f Deviation: {a.deviation_percent}%) if __name__ __main__: model CentrifugePhysicsModel(rated_rpm1200, rated_frequency50, rated_power_kw75) # Normal operation - no alerts expected model.check_frequency_rpm_correlation(50.0, 1164) model.check_power_speed_correlation(1164, 72.0) # Stuxnet-style attack: frequency increased but RPM spoofed as normal model.check_frequency_rpm_correlation(84.0, 1164) # freq up, RPM spoofed model.check_power_speed_correlation(1164, 180.0) # power reveals true speed model.report()三条物理关联规则的原理频率-转速关联FREQUENCY_RPM_MISMATCH异步电机转速约等于120 × 频率 / 磁极对数考虑典型 3% 转差率。示例中 50Hz 对应约 1164 RPM若攻击者将频率提升到 84Hz 却把 RPM 伪造成正常值两者必然背离偏差超过 5% 即触发critical告警。功率-转速关联POWER_SPEED_MISMATCH离心类负载功率近似与转速的三次方成正比P ∝ RPM³。当攻击者试图通过变频器暗中提速时功率消耗会出卖真实转速——即使 RPM 传感器被欺骗功率曲线也会暴露实际运行状态。阈值设为 15%。振动-转速关联ABNORMAL_VIBRATION振动特征应与运行速度一致。代码以 ISO 10816 标准 7.0 mm/s 作为警报阈值若在报告正常的转速下出现超限振动说明真实转速与上报值不符机械处于异常工况。这三个检查正是交叉验证独立传感器思想的具体实现攻击者可以欺骗单一传感器但难以同时欺骗物理上相互耦合的多个测量通道。运行__main__中的示例即可直观看到正常工况无告警而频率提升 RPM 伪造的攻击场景同时触发频率-转速与功率-转速两条告警。工程工作站侧检测IOC 扫描与 STEP 7 项目审计Stuxnet 的第三阶段发生在工程工作站DLL 注入 PLC 编程软件、rootkit 隐藏文件。仓库中的辅助脚本 scripts/agent.py 提供了一个可直接运行的命令行检测 Agent它将上述检测思想整合为三类检查1. 主机 IOC 扫描--check-host内置了真实 Stuxnet 风格的 IOC 集合包括rootkit 驱动文件mrxcls.sys、mrxnet.sys扫描C:\Windows\System32\drivers与C:\Windows\inf注册表项HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\MS-DOS Emulation、HKLM\SYSTEM\CurrentControlSet\Services\MRxCls、HKLM\SYSTEM\CurrentControlSet\Services\MRxNet仅 Windows 平台执行reg query互斥体名与文件哈希。2. PLC 流量分析--pcap调用 tshark 从 PCAP 提取 Modbus/S7comm 流量统计写操作功能码当写操作超过 100 次时标记为CRITICALExcessive PLC write operations。这与上文 Step 2 的协议监控思路一一对应是把流量分析自动化的参考实现。3. STEP 7 项目审计--step7-project递归扫描 Siemens STEP 7 项目目录列出所有以ob开头且扩展名为.awl语句表源文件或.mc7编译后机器码的组织块文件及其大小、修改时间供人工核对完整性。参考文档 references/api-reference.md 中给出的文件类型含义.awl为 STL 源、.mc7为编译机器码、.s7p为项目文件可辅助判断哪些文件值得重点比对。运行方式示例在目标主机或分析机上# 扫描主机 IOCrootkit 驱动 注册表 python agent.py --check-host # 分析 ICS 流量 PCAP python agent.py --pcap capture.pcap # 审计 STEP 7 项目中的组织块 python agent.py --step7-project /path/to/step7/project # 输出 JSON 报告 python agent.py --pcap capture.pcap --check-host -o report.json脚本最终汇总各检查项数量并计算风险等级CRITICAL≥3 条发现、HIGH≥1 条、LOW0 条。该脚本位于 scripts/agent.py可作为 Agent 自动执行的参考实现直接复用。关键概念术语定义网络物理攻击Cyber-Physical Attack同时操纵网络系统PLC 逻辑、传感器读数与物理过程的攻击逻辑注入Logic Injection向 PLC 程序插入恶意代码块以改变物理过程行为传感器欺骗Sensor Spoofing重放或伪造传感器读数使操作员无法察觉过程被操纵基于物理的检测Physics-Based Detection用物理过程的数学模型识别上报传感器值与真实物理规律不一致的情况PLC 逻辑基线PLC Logic Baseline用于完整性比对的已知良好 PLC 程序块OB、FC、FB、DB副本摆渡攻击Air-Gap Bridging通过 USB 等介质跨越隔离网络的技术即 Stuxnet 的初始访问方式工具与平台原文档列出的典型落地工具组合Claroty xDome持续 PLC 逻辑监控支持基线比对与变更检测SIGA OT Solutions在电气层进行物理信号监控用于检测过程操纵Nozomi GuardianOT 监控平台具备 PLC 程序变更检测能力Siemens SINEMA Remote Connect安全远程访问支持 PLC 项目版本跟踪。这些平台与本技能的架构思想一致先建立已知良好基线再持续比对运行状态与物理规律最后将异常转化为带 MITRE 映射的告警。输出格式检测报告模板原文档给出了结构化的报告输出模板便于将检测结果沉淀为可审计的交付物Stuxnet-Style Attack Detection Report Monitored PLCs: [N] Monitoring Period: YYYY-MM-DD to YYYY-MM-DD PLC INTEGRITY: Baselines verified: [N]/[N] Logic modifications detected: [N] New blocks detected: [N] PHYSICS ANOMALIES: Sensor correlation violations: [N] Process model deviations: [N] ENGINEERING WORKSTATION: Unauthorized modifications: [N] USB connections: [N]建议将报告中的每一项发现与上文攻击链阶段一一对应例如New blocks detected对应 Stage 4 的 T0833/T0839Sensor correlation violations对应 Stage 5 的 T0856使输出天然衔接 MITRE ATTCK for ICS 框架。框架映射与仓库定位本技能在仓库中被标记为subdomain: ot-ics-securityOT/ICS 安全子域属于 29 个安全域中 OT/ICS 安全的 28 项技能之一见 README.md。其 YAML frontmatter 完成了双框架映射NIST CSF 2.0PR.IR-01事件响应计划的改进、DE.CM-01网络与活动监控、ID.AM-05资源优先级、GV.OC-02运营连续性与通信MITRE ATTCK for ICST0853未经授权的 PLC 固件/程序修改、T0831操纵报告、T0809数据销毁、T0807命令注入——这一组合覆盖了改程序、骗传感器、毁证据的完整攻击套路。这体现了该仓库一个技能多框架映射的设计理念Agent 通过 frontmatter 的description与tags在约 30 token 的扫描成本内命中本技能再完整加载 Workflow 逐步执行详见 README.md 的Skill anatomy与How AI agents use these skills章节。落地建议与边界先建基线再谈检测PLC 完整性监控的有效性完全取决于已知良好基线的质量务必在系统上线前采集基线并纳入版本管理多层交叉验证不要只依赖单一检测手段——逻辑完整性、协议层写操作、物理模型关联、主机 IOC 四者互为补充任一层被绕过时其余层仍可兜底合法使用边界本技能包含攻击链与检测技术细节仅可用于已获授权的渗透测试、安全研究、防御建设与培训场景对隔离网络与生产 OT 环境的任何探测、流量捕获和基线采集都必须事先获得书面授权并遵守适用的法律与运行规则参考 SECURITY.md 与 CODE_OF_CONDUCT.md。综合而言本技能将 Stuxnet 拆解为可检测的阶段化模型并给出了逻辑完整性 物理模型 协议流量 主机 IOC四层可落地的检测实现是 AI Agent 在 ICS/SCADA 环境中执行 APT 级威胁狩猎的完整操作手册。【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI 20 platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考