僵尸网络对远程控制工具RustDesk发起攻击 开发团队建议修改安全设置加强保护

2026-02-06 19:58:20 2 1015

僵尸网络对 RustDesk 远程控制工具发起自动化攻击,此次攻击不涉及安全漏洞,开发团队建议用户修改安全设置加强保护。这些僵尸网络全网扫描暴露的 ID 并尝试连接,若用户看到名为 Go Client 的连接请求后不慎点击接受那就会中招,为此建议用户在安全选项里设置强密码,这样即便不慎点击接受按钮也无法连接。

知名的开源远程控制工具 RustDesk 在 2026 年 1 月末遭到僵尸网络发起的自动化攻击,此类攻击不涉及任何安全漏洞,主要是利用自动发起的远程控制请求诱导用户接受。
受到攻击的用户会看到名为 Go Client 的客户端尝试连接,此时看到连接请求后用户可以点击接受或取消,如果用户不慎点击接受那么设备将被僵尸网络控制。
被控制后僵尸网络可能会执行自动化命令用来部署其他恶意软件并实现持久化,由于僵尸网络规模庞大且执行自动化扫描,因此难免有用户会不慎点击接受按钮。

此次攻击具有如下特点:
来自 Go Client 的随机连接请求,具有多个不同的 IP 地址和 ID
采用自动化机制扫描互联网中的 RustDesk ID 并发起连接
属于非定向接入尝试,不需要获得用户的连接密码

针对此类攻击开发团队建议如下:
绝对不要点击任何未知来源的接受连接请求
前往设置的安全选项中,将接受连接请求改成使用密码,这样仅点击接受是无用的
需要设置高强度密码并在连接时输入密码完成验证后才能访问
改成自托管 RustDesk 并且不要暴露自己的服务器 IP 地址和公钥
改成专业版 (自托管),这样会增加额外的 ACL 来保护目标设备安全
启用双因素认证或 IP 白名单,仅接受目标 IP 地址的连接

关于作者

weak_hong44篇文章56篇回复

评论2次

要评论?请先  登录  或  注册
  • 2楼
    2026-2-10 11:29

    结论

    攻击核心在于通过伪造合法连接请求诱导用户交互授权,本质是社会工程学攻击与自动化扫描的结合。防御需切断用户交互环节的"无条件授权"路径,强制引入多阶验证机制。


    分析路径(Source-Sink分析)

    1. 输入源(Source)

      • 攻击源:僵尸网络生成的Go Client伪装连接请求(随机IP/ID组合)
      • 数据流:通过RustDesk协议发送的未验证连接握手包
    2. 危险操作(Sink)

      • 用户误点"接受"按钮 → 触发远程控制授权 → 攻击者获取设备权限
      • 危险函数链:RustDesk UI授权逻辑远程会话建立
    3. 攻击链验证

      攻击流量(伪造ID/IP) → RustDesk服务端/客户端 → 用户交互层 → 授权漏洞(无密码校验) → 设备控制  

    验证步骤

    1. 流量特征分析

      • 检查RustDesk日志中是否存在高频次的未授权连接请求,特征:
        [timestamp] Received connection request from unknown ID: [随机生成ID], IP: [高频变动IP]  
      • 使用tcpdump或Wireshark抓包,过滤RustDesk相关端口(默认33892/33891),分析协议字段异常(如ID是否符合规范格式)。
    2. 用户行为审计

      • 审查日志中"接受连接"操作的记录,统计非业务时段的高风险操作(如深夜异常授权)。
    3. 环境暴露检测

      • 确认是否暴露公钥或服务器IP至公网(nmap扫描目标端口开放性,或检查云平台安全组配置)。

    修复建议

    防御层加固(按优先级)

    1. 强制密码验证(核心修复)

      • 即使用户点击"接受",仍需输入预设密码才能建立连接 → 断开"点击即授权"的直接路径。
      • 配置示例:
        RustDesk客户端设置 → 安全选项 → "需要密码验证" → 设置不少于12位的密码(字母+数字+符号)  
    2. 网络层隔离

      • 自托管方案
        • 配置NAT或代理服务器,仅允许特定IP段访问RustDesk端口。
        • 使用iptables或云防火墙设置白名单:
          iptables -A INPUT -p tcp --dport 33892 -s 192.168.1.0/24 -j ACCEPT  
      • 专业版ACL配置:启用基于角色的访问控制(RBAC),限制设备仅接受特定用户组的连接请求。
    3. 协议级防御

      • 启用双向身份验证:客户端需验证服务端证书,服务端验证客户端指纹。
      • 修改默认端口并关闭未使用的协议(如关闭HTTP管理端口)。
    4. 监控与告警

      • 配置异常连接告警:
        日志监控工具(如ELK) → 规则:同一IP 5分钟内请求超5次 → 触发告警并自动拉黑IP  

    长期防御策略

    • 用户教育:强调拒绝未知连接请求,定期演练社会工程学攻击场景。
    • 协议升级:推动RustDesk开发团队将密码验证设为默认模式,或引入TOTP动态码二次验证。

    缺失信息补充建议

    若需进一步排查,需提供:

    1. 受影响环境的日志片段(连接请求与授权日志)
    2. 当前网络拓扑(是否暴露RustDesk端口至公网)
    3. 客户端版本号(验证是否存在未修复的交互逻辑漏洞)

    最小验证步骤:

    1. 检查客户端设置页面 → 确认"接受连接"是否仍为无密码模式  2. 在非办公时段观察连接日志 → 统计是否存在凌晨时段的异常请求  3. 执行`curl -v <your_rustdesk_server>:33891` → 检查是否返回开放状态码(应为403/404)  

  • 1楼
    2026-2-7 15:30

    僵尸网络 配合 远程控制工具 ,只要有人不小心 ,点了1个接受,那就中招了啊