GitHub用户Sadpainy上传了一个名为Stuxnet的仓库,自称基于2010年曝光的原始样本逆向重构而成。

代码只能在Windows XP和Windows 7上编译运行,标注用途是研究、教学和防御分析。这不是那只十五年前搅乱工业控制系统的蠕虫复活。它更像一份来源未经证实的教学版复刻——能帮人看懂当年那条攻击链怎么搭起来,却拿不出任何证据证明能复现真实的物理破坏。

对工控安全团队和恶意软件研究人员来说,这份代码值得放进检测规则和隔离实验的素材库。但"能编译"和"能造成破坏"之间隔着一整条工业环境的鸿沟,普通用户、更别提生产现场的PLC,都不该碰它。

复原了什么:仓库自述的六个模块与一条攻击链

仓库文档列出了六个模块:负责初始感染和提权的loader/dropper,劫持西门子Step7通信的S7 hook库,用来隐藏文件与进程的rootkit(mrxcls.sys、mrxnet.sys),以及最终改写PLC逻辑的攻击载荷。

作者给出的攻击链是:先靠USB的LNK漏洞或网络共享传播,站稳脚跟后劫持Step7与PLC之间的通信。等用户往PLC下装工程项目时,把恶意代码塞进OB1/OB35这两个逻辑块,最后让变频器转速异常,造成物理损坏。

仓库自述的攻击链条 USB/网络传播 LNK漏洞·P2P 本地提权 内核驱动 劫持Step7 s7otbxdx.dll 篡改PLC逻辑 OB1/OB35 变频器异常 物理损坏 来源:仓库自述文档,链条真实性未经独立验证

这条链条和2010年安全厂商披露的分析基本对得上。赛门铁克、卡巴斯基、ESET当年的报告都描述过类似的S7劫持和OB块篡改手法,目标涉及Siemens Step7软件和S7-300/400型号PLC。业界也普遍称Stuxnet为"首个已知的网络武器"。仓库作者在致谢里点名引用了这几家的研究。

但仓库文档没有说明哪些模块是完整实现,哪些只是框架占位。漏洞利用代码是否可用、驱动是否需要签名才能加载、有没有真实的C2通信、需要什么具体设备条件才能触发PLC篡改——这些关键缺口,作者都没有交代。

这份代码对工控安全圈意味着什么

这份仓库真正有意思的地方,不是它"复活"了什么,而是暴露了工控安全的一个老问题:从Windows入侵到PLC逻辑篡改,中间隔着IT和OT两套完全不同的防御体系。普通杀毒软件和端点检测很难跨过这条线。如果代码结构清楚、逻辑还原准确,它可以变成YARA规则和检测签名的训练素材。

限制也很明显。这是个人逆向重构,不是原始源码,真实性和完整性都没有经过独立审计。它标注的GPLv3许可证只覆盖Sadpainy自己写的这份代码,不代表原始Stuxnet获得了任何授权,也不意味着攻击能力被"合法化"。

对比项2010年原始StuxnetSadpainy仓库重构版
目标系统Windows XP/7 + Siemens Step7/S7-300/400Windows XP/7(仅编译运行环境)
曝光/发布2010年被赛门铁克等厂商曝光近期上传GitHub,未标注验证时间
传播方式USB LNK漏洞、网络共享、P2P仓库自述复刻同一路径
核心动作劫持Step7通信,篡改OB1/OB35,致离心机转速异常声称复刻同一链条,未见独立验证的运行效果
验证状态多家安全厂商独立分析确认未经第三方审计
许可证无,作者不明仓库自标GPLv3,仅覆盖本仓库代码

现代ICS恶意软件通常依赖更复杂的供应链渗透或远程运维环境作为入口,这份仓库复刻的是十几年前的架构。它宣称只兼容XP/7,乍看是限制,实际未必挡得住误用——不少工控现场的工程站至今没升级过操作系统,XP/7在真实ICS环境里并不罕见。这道门槛提高的是嵌入现代化企业网络的难度,不是彻底堵死运行的可能性。

谁该碰这份代码,接下来看什么

ICS安全团队和恶意软件研究人员,可以把它拿来做静态代码审计,对照历史IOC提取特征,尝试构建YARA规则。前提是全程隔离沙箱、不联网、不导入任何生产PLC的工程文件。

企业安全负责人如果考虑把它纳入内部培训或检测开发,先确认代码能否独立编译通过、模块结构是否与文档一致,再决定要不要进教材。在没有第三方审计之前,不该把它当作"当前活跃威胁样本"写进内部通报,也不该拿它替代对现有ICS资产的补丁排查。

接下来值得盯的,是有没有独立安全机构或知名研究员核实这个仓库的代码结构和可编译性,以及作者后续是否有新的commit或对质疑的回应。目前这些都还看不清。