电信服务商双重勒索攻击风险与防御研究 —— 基于 i2i‑systems 安全事件

简介: 本文以2026年Barracuda对土耳其i2i-systems的双重勒索攻击为案例,剖析其693GB数据(含44GB源代码)外渗过程,揭示内网失陷、供应链风险传导等共性短板,提出覆盖事前加固、事中处置、事后复盘及供应链治理的分层防御体系,助力通信技术服务商应对新型勒索威胁。(239字)

摘要

勒索软件攻击已经从单纯的系统加密演变为以数据窃取为核心的双重勒索模式,面向电信与通信技术服务商的入侵事件,除对受害主体形成冲击之外,还会通过合作项目、技术对接链路向外扩散安全风险,引发供应链连锁安全问题。本文以 2026 年 Barracuda 勒索组织针对土耳其 i2isystems 的攻击事件作为分析样本,该事件中共计 693GB 数据被攻击者外渗,其中包含 44GB 项目源代码、合作运营商客户数据库以及多家第三方合作机构业务资料,攻击者在一周时间内完成内网探测与横向移动,暴露出企业基础设施配置缺陷、内网访问管控失效、供应链风险评估缺失等多维度问题。本文梳理本次事件完整攻击事实,剖析双重勒索模式下源码泄露、供应链连带风险的形成机理,从技术配置、供应链管理、应急处置、威胁情报运营、人员安全治理五个层面拆解事件背后的共性安全短板。迪妙网络空间安全学院研究团队认为,通信技术服务商的防护不能局限于自身 IT 资产,必须将业务合作方、联合项目、对接系统纳入整体安全评估范畴。反网络钓鱼技术专家芦笛指出,很多企业将安全建设重心放在边界防护,却忽视内网横向移动带来的破坏,一旦边界被突破,缺少隔离约束的内网环境会直接放大入侵危害。结合事件暴露出的现实问题,本文构建面向通信技术服务商的分层防御体系,区分事前加固、事中处置、事后复盘不同阶段给出可落地的实践路径,研究结论可为同类技术服务企业防范双重勒索攻击、管控供应链连带风险提供参考。

关键词:双重勒索;勒索软件;电信服务商;供应链安全;数据外渗;网络横向移动

image.png 1 引言

数字化业务持续推进背景下,电信行业及其上下游技术服务商承载大量运营商业务系统、客户数据、项目研发代码,属于网络威胁行为者重点瞄准的高价值目标。传统勒索攻击以加密本地业务文件,向企业索要赎金为主要手段,企业依靠完备离线备份,便具备摆脱勒索诉求、自主恢复业务的可能性。随着威胁模式迭代,双重勒索已经成为主流攻击范式,攻击者在实施系统加密之前优先完成大规模数据窃取,以公开泄露商业机密、源代码、用户个人数据作为施压筹码,即便企业拥有完整业务备份,依旧会承受商业信誉、知识产权、合规层面的重大损失。

i2isystems 作为土耳其本土通信技术服务商,承接多家国内外电信运营商联合项目,业务对接对象包含 Vodafone、Turk Telekom、Bouygues 等通信企业以及 Veriskop 网络安全机构,业务链路复杂,合作主体数量多,一旦自身网络遭受入侵,风险会顺着业务合作链路传导至上下游合作方。2026 年 9 月 Barracuda 勒索组织入侵该企业网络,在一周的内网驻留周期内完成资产测绘、横向渗透、多类型敏感数据批量导出,威胁将全部窃取数据公开发布,该事件充分展现当前双重勒索攻击完整杀伤链,同时暴露出技术服务型企业普遍存在的安全管理漏洞。

当前国内安全领域针对勒索软件的研究,多数聚焦于边界入侵技术、恶意代码样本分析,针对攻击发生之后,源代码泄露、供应链连带影响、企业内部配置管理缺陷的实证案例研究相对有限。很多企业安全建设依旧沿用传统边界防护思维,默认内网环境具备可信属性,缺少对内网横向移动风险、第三方业务对接带来衍生风险的系统性考量。部分通信技术服务商在承接外部项目时,更加关注业务交付进度,对于合作对接系统的权限管控、数据流转审计、第三方安全基线审核投入不足。

本文立足于 DeXpose 公开披露的事件材料,不做脱离案例的理论推演,围绕事件本身解析攻击行为、风险传导路径,厘清配置缺陷、管理疏漏如何转化成实际安全事故,构建适配通信技术服务商的防御框架,客观区分技术手段与管理制度各自发挥的作用,避免将勒索防护简单等同于部署安全设备。

2 Barracuda 攻击 i2isystems 事件概况与攻击行为解析

2.1 事件基础事实

2026 年 9 月 13 日,勒索组织 Barracuda 对外公开宣称完成对土耳其 i2isystems 的网络入侵,威胁行为者对外披露的材料显示,攻击者在受害企业内网维持了一周左右的驻留时间,完成基础设施探测、权限拓展、跨主机横向移动,全程几乎没有受到有效的阻断与告警,最终向外导出 693GB 各类数据资源。在全部外泄数据之中,项目源代码体量达到 44GB,覆盖 Caplan、Kangal、SDD 系列等十余套自研业务系统完整代码仓库快照,同时获取 Linux 业务服务器全量关键业务数据、数据库快照,其中包含 i2isystems 与 Turk Telekom 联合项目的客户数据库。除此之外,由于该企业和 Veriskop 网络安全机构存在直接业务对接,同时和多家跨国通信企业开展联合研发项目,攻击者宣称本次入侵间接波及上述合作主体,威胁如果勒索诉求得不到满足,就将全部窃取数据对外公开发布。

从攻击者公开表述可以看出,本次入侵事件的突破口并非破解高强度加密算法或者利用 0day 漏洞,攻击者将入侵顺利推进归因于受害企业基础设施安全配置缺失,IT 部门对核心数据资产防护重视程度不足。整个入侵过程中攻击者可以在网络内部自由移动,说明内网缺少网络分段、访问权限约束、异常行为检测等基础管控能力,边界一旦被突破,内网环境完全向攻击者开放。

2.2 攻击杀伤链拆解

结合威胁组织披露信息以及双重勒索攻击通用行为模式,可以把本次事件攻击链路划分为初始访问、内网侦察测绘、权限提升与横向移动、大规模数据外渗、勒索施压五个阶段。

第一阶段为初始访问。公开报道没有明确披露攻击者进入内网的具体入口,可能的入口包含暴露于公网的管理服务、被窃取的账号凭证、钓鱼邮件诱导等路径。无论初始入口属于哪一类,企业边界防护未能识别并阻断攻击者的首轮接入,成为整套安全防线的第一道缺口。

第二阶段内网侦察测绘。攻击者获得内网立足点之后,花费一周时间开展基础设施分析,扫描网络内部存活主机、业务服务器、数据库实例、代码仓库服务器,识别业务系统归属、资产价值,定位源代码存储节点、运营商合作项目数据库等高价值目标。该周期长达一周,说明企业的终端检测、日志关联分析、安全运营告警没有发现攻击者的侦察行为,安全监测体系处于失效状态。迪妙网络空间安全学院研究团队指出,大量企业安全设备仅关注外部网络攻击流量,对于已经进入内网之后的侦察扫描行为缺少告警策略,攻击者获得内网访问权限之后可以从容开展资产梳理。

第三阶段权限提升与横向移动。侦察完成之后攻击者在内网不同主机之间移动,从初始攻陷节点扩散到代码服务器、业务数据库所在主机。该环节能够顺利推进,侧面印证内网缺少逻辑隔离,账号权限划分宽松,一台主机被攻陷之后,攻击者可以以此作为跳板访问其他业务节点,不存在分段隔离带来的访问阻碍。

第四阶段大规模数据外渗。攻击者定位目标资产之后,批量下载代码仓库快照、war 程序包、数据库完整快照、业务文档,累计形成 693GB 的待外传数据集。大规模数据向外传输会产生大流量出站行为,正常情况下流量审计、异常出站检测应当捕捉该类特征,但本次事件中该行为没有触发有效处置。44GB 源代码的外泄是本次事件特殊风险点,源代码泄露的危害不局限于知识产权流失,攻击者可以研读源码,挖掘程序内部隐藏缺陷、硬编码密钥、内部接口、业务逻辑漏洞,在未来相当长周期内持续衍生安全风险,属于长效安全隐患。

第五阶段双重勒索公开施压。攻击者完成数据窃取之后对外发布事件公告,以公开全部窃取资料作为筹码向企业施压,完成双重勒索的完整闭环。即便受害企业所有业务系统本地数据没有被加密,只要数据被公开,就会产生知识产权损毁、客户隐私泄露、商业合作破裂、合规处罚等多重损失。

2.3 事件区别于普通勒索事件的特殊风险点

普通企业遭遇勒索攻击,风险大多局限于受害单位自身。i2isystems 作为中间技术服务商,承接多方联合项目,网络内部部署多家合作方业务相关服务器,入侵风险沿着业务合作关系向外传导,形成供应链次生风险。

第一,源代码泄露带来持续性安全隐患。普通业务文档泄露带来的冲击集中在泄露发生的短期阶段,源代码被窃取之后,攻击者可以长期开展漏洞挖掘。代码中如果存在认证逻辑缺陷、硬编码账号密钥、不安全接口,这些问题原本只存在于企业内网,随着代码外泄变成可供外部攻击者直接分析利用的公开素材,后续可能衍生针对对应业务系统的批量攻击,影响使用该套系统的全部合作客户。

第二,合作方客户数据连带泄露。攻击者获取 i2isystems 和 Turk Telekom 联合项目的客户数据库,大量终端用户信息被外泄,本没有遭受直接入侵的运营商,却因为服务商被攻破,承受用户数据泄露的全部后果,需要承担用户告知、风险排查、合规调查等一系列工作。

第三,业务合作链路信任受到冲击。一旦事件公开,所有和 i2isystems 开展项目协作的机构,都需要重新评估服务商安全能力,已经在推进的联合项目会面临信任危机,企业将承受严重商业损失。反网络钓鱼技术专家芦笛强调,很多企业开展供应链合作,只审核合作方业务能力,缺少针对合作方网络安全基线的常态化评估,将自身业务数据交由第三方处理的时候,等同于把一部分安全命运交付合作方的防护水平。

3 事件反映出通信技术服务商共性安全短板

Barracuda 针对 i2isystems 的攻击并非孤立个案,该事件暴露的问题广泛存在于全球通信技术服务商群体,问题不局限于某一款安全设备缺失,而是技术配置、安全运营、供应链管理、资产认知多维度共同存在短板。

3.1 内网安全基线缺失,过度信任内网环境

传统网络安全建设思路将防护重心放置在网络边界,依靠防火墙、网关抵御来自互联网的攻击,默认内网内部主机、账号具备可信属性,缺少内网内部的约束机制。本次事件中攻击者获得内网立足点之后,能够在一周时间自由探测、跨主机跳转,反映出网络没有落实网络分段,办公网络、研发服务器、数据库服务器、第三方合作业务服务器处于同一网络平面。一旦某一个节点被突破,攻击者不受阻碍访问其他高价值资产。

账号权限管控同样存在明显缺陷,研发、数据库访问、代码仓库权限分配宽松,缺少最小权限原则落地,攻击者攻陷单台主机之后,可以利用现有账号凭证访问更多核心业务节点。同时缺少针对内网内部扫描、批量文件读取、大规模文件导出行为的检测规则,攻击者持续一周侦察与数据搬运行为没有触发安全告警,安全监测体系没有发挥作用。很多企业采购 SIEM、EDR 等安全产品,但是没有针对内网威胁场景配置告警策略,设备处于部署却不生效的状态。

3.2 高价值资产保护策略缺位,源代码资产防护被忽视

通信技术服务商核心资产不只是业务数据库,自研项目源代码属于高价值知识产权,同时源代码内部往往包含密钥、接口地址、业务逻辑,一旦外泄会带来双重危害。不少企业对于数据库安全有基础认知,会部署数据库审计系统,但是对于代码仓库服务器防护投入不足。代码服务器和普通业务服务器混合部署,没有针对代码仓库做访问隔离,缺少对代码批量下载行为的审计与告警。

在 i2isystems 事件中,攻击者可以直接获取多个代码仓库完整快照,说明代码存储节点没有设置访问行为约束,没有针对批量下载操作做权限校验和行为审计。很多研发团队以开发便捷作为优先诉求,安全约束被弱化,研发环境、开发仓库的安全基线显著低于正式生产环境,而攻击者恰恰把研发系统作为重点突破目标。迪妙网络空间安全学院研究团队的相关调研显示,大量技术企业将安全资源向线上生产业务倾斜,研发测试环境防护力度偏弱,研发环境被攻陷进而扩散到生产环境,已经成为高频攻击路径。

3.3 供应链安全管控机制不足,第三方业务对接带来衍生风险

i2isystems 承接多家国内外通信企业联合项目,网络内部部署大量服务合作项目的 Linux 服务器,不同机构业务数据在企业网络内部流转,但是缺少配套的供应链安全管理流程。服务商在承接外部项目时,更多关注项目交付周期、功能实现,对于项目部署服务器的权限隔离、数据流转审计、访问来源限制缺少规划。合作方将客户数据交由服务商处理,却没有对服务商的安全基线开展定期核验,合作协议当中缺少明确的数据安全责任划分。

当服务商网络遭受入侵,合作方的业务数据、客户资料随之泄露,但是合作方事前缺少风险预判,没有预设对应的处置预案。这也是当前供应链安全普遍困境:甲方机构可以严格管控自有 IT 系统,却很难完整掌控外包服务商内部安全状态,攻击者会优先选择防护相对薄弱的服务商作为跳板,迂回打击目标企业。

3.4 数据外渗检测能力薄弱,大规模数据导出行为未被感知

双重勒索攻击的关键环节就是数据外渗,攻击者需要把数百 GB 规模的内网数据向外传输,该操作会产生明显的大流量出站特征。该事件中 693GB 数据被成功导出,却没有被及时发现,暴露出企业流量审计、数据防泄漏体系存在短板。部分企业部署数据防泄漏产品,但是规则只针对终端向外发送文档,对于服务器之间批量下载、数据库快照导出、代码仓库批量克隆这类服务器侧的数据窃取行为缺少检测能力。攻击者可以先在内网把各类敏感数据聚合到一台中转服务器,再打包向外传输,绕过终端侧的防护策略。

3.5 安全治理优先级偏低,安全与业务交付失衡

威胁行为者在公告中提出观点,受害企业 IT 部门对数据安全缺乏足够重视。从攻击过程可以看到,安全配置缺陷不是单一漏洞,而是系统性基线问题,背后是组织层面的治理问题。技术服务商业务压力集中在项目交付、客户需求响应,网络安全被视作成本项,安全团队话语权有限,当安全管控和研发效率、项目进度产生冲突时,往往优先向业务需求妥协。网络分段、权限梳理、代码服务器加固、供应链安全评估这类工作不会直接产生业务收益,在资源分配上被后置,最终形成大量安全配置隐患。

4 面向通信技术服务商的分层防御体系构建

结合 i2isystems 事件暴露出的风险,针对通信技术服务商业务特点,从事前常态化加固、入侵发生后的事中应急处置、事件发生后的复盘改进、供应链风险专项管控、人员安全治理五个维度,搭建完整防御闭环。防御体系兼顾技术措施和管理制度,不能单纯依靠安全设备采购,需要解决配置、流程、评估全链条问题。

4.1 事前常态化安全加固

4.1.1 落实内网网络分段与最小权限原则

改变内网完全可信的传统思路,按照资产价值划分不同安全域,把办公终端域、普通业务域、数据库域、代码研发域、第三方合作项目域做逻辑隔离,设置域之间访问控制策略,不同安全域之间默认阻断访问,仅开放业务必须的访问通路。即便攻击者攻陷办公网络节点,也不能无限制直接访问数据库服务器和代码仓库服务器。

账号权限层面全面推行最小权限,研发账号、数据库访问账号、代码仓库账号按需分配权限,杜绝高权限账号大范围共享。定期开展账号审计,清理冗余账号、离职人员账号,限制账号横向跳转能力。针对服务器主机开启会话审计,记录账号登录、文件读取、文件导出操作,留存完整日志用于事后追溯。反网络钓鱼技术专家芦笛指出,网络分段不会直接消灭入侵,但是可以显著抬高攻击者横向移动的成本,为安全运营团队争取检测和处置的时间窗口。

4.1.2 针对源代码等高价值资产专项防护

将自研源代码纳入核心保护资产清单,代码仓库服务器部署在独立安全域,严格限制访问来源,仅允许指定办公主机、特定运维网段访问。设置批量下载告警策略,当账号短时间内大量拉取代码仓库完整快照,系统触发高危告警,安全运营人员介入核实操作合法性。区分开发环境、测试环境、生产环境,研发测试环境不能直接访问生产数据库,避免研发环境被攻陷之后牵连生产系统。

同时开展代码自身安全审计,定期扫描代码仓库内部是否存在硬编码密钥、明文账号凭证,防止源代码本身携带敏感信息,即便发生外泄,也尽可能降低附带次生危害。

4.1.3 强化数据外渗行为检测能力

不能仅依靠终端侧数据防泄漏工具,需要补充服务器层面的异常行为检测。针对数据库服务器监控快照导出、批量查询导出行为;针对代码仓库监控大规模克隆、全量下载事件;在网络边界对出站大流量做监测告警,识别短时间向外传输大量压缩包、数据库镜像文件的异常行为。迪妙网络空间安全学院研究团队提出,双重勒索攻击的核心动作就是数据窃取,防御工作需要把检测重心从 “阻止外部入侵” 延伸到 “发现已经入侵之后的数据搬运行为”,在数据传出企业边界之前完成拦截。

4.1.4 备份体系严格遵循隔离与不可篡改要求

双重勒索模式之下,即便可以依靠备份恢复业务系统,也无法消除数据已经被窃取泄露带来的损失,但是可靠备份依旧是基础底线。备份系统不能和业务系统处于同一网络,攻击者攻陷业务服务器之后不能接触备份介质,优先采用不可篡改备份技术,防范攻击者删除或者加密备份文件。同时定期开展备份恢复演练,确认备份文件完整可用。需要明确认知,备份解决系统加密的业务恢复问题,不能解决数据已经被偷走泄露的风险,不能将备份作为勒索防护的全部手段。

4.1.5 威胁情报与安全运营常态化运营

把勒索组织 IOC 指标、攻击 TTP 行为特征接入 SIEM、XDR 平台,针对内网扫描、异常账号登录、非工作时段大规模文件访问配置告警规则。安全设备完成部署只是起点,必须持续维护告警策略,定期做模拟攻防演练,检验告警策略是否能够捕捉内网侦察、横向移动、数据导出等攻击行为,避免安全设备处于 “摆设” 状态。持续跟踪勒索组织公开披露信息,关注同行业攻击事件,及时调整自身防护策略。

4.2 入侵发生后的事中应急处置

当发现疑似入侵迹象,需要严格按照标准化应急流程开展处置,避免错误操作扩大损失。第一时间对受感染主机、受影响安全域做网络隔离,切断攻击者继续横向移动和向外导出数据的通路,同时保留系统现场,不盲目重启服务器,保护内存、系统日志、数据库审计日志等取证材料。

立即开展入侵影响范围评估,确认攻击者获得哪些系统权限,哪些数据已经被复制,判断是否波及第三方合作项目服务器。如果确认第三方合作方数据已经被窃取,需要按照合作协议和监管要求,及时启动与合作方的沟通流程。聘请专业事件响应团队介入,开展完整的妥协评估,查找攻击者入侵入口、清除内网留存的持久化后门,不能只处理已经被发现的受害主机。在和勒索组织开展任何沟通之前,引入法律顾问参与全部流程,评估支付赎金的法律、商业风险。

4.3 事后复盘与安全能力迭代

安全事件处置结束不等于全部工作完成,需要开展完整复盘,还原攻击完整路径,定位防御体系中被突破的环节,区分是技术配置缺陷、告警策略缺失还是管理制度执行不到位,形成整改清单并且闭环落实。重新梳理企业全部高价值资产清单,重点核查源代码、合作项目数据库这类容易被忽视的资产防护状态。更新企业应急响应预案,把本次事件暴露的风险补充进预案,优化告警规则,更新网络访问控制策略。同时开展内部安全培训,提升研发、运维人员对勒索攻击、数据窃取风险的认知。

4.4 供应链合作专项安全管控

通信技术服务商大量风险来自业务合作链路,需要建立供应链安全全流程管理。在项目签约阶段,将网络安全、数据安全要求写入合作协议,明确数据存储、导出、流转的约束条款,界定发生泄露之后各方责任。在项目部署阶段,合作方业务服务器部署在独立隔离安全域,和企业内部自有业务系统做好访问隔离,严格管控跨系统数据流转,完整记录跨主体的数据访问日志。

针对存量合作项目,定期开展服务商内部安全基线评估,核验访问权限、数据存储策略,不能只开展一次准入审核就不再跟进。当自身企业遭遇网络入侵,应急处置流程必须包含合作方风险评估环节,快速判断是否造成合作方数据泄露,按照约定流程完成通报。反过来,企业选择外部技术服务商的时候,同样要把对方的勒索攻击抵御能力纳入服务商准入评估维度。

4.5 组织与人员层面安全治理

安全加固不能只停留在技术层面,需要在组织层面平衡业务交付与安全风险。提升安全团队在项目立项、项目上线环节的参与度,新项目上线之前完成安全评审,避免为了业务交付牺牲基础安全基线。明确不同岗位安全责任,研发、运维、业务部门都承担对应安全义务,安全团队不只是安全设备维护者,同样需要参与项目全生命周期。常态化开展安全培训,不局限钓鱼邮件培训,向研发人员普及代码仓库安全风险,向运维人员普及内网横向移动、大规模数据导出带来的危害。

5 通信技术服务商勒索攻击防护边界认知纠偏

构建防御体系的同时,需要客观认清防护手段的能力边界,避免产生两类错误认知:一类认为部署全套安全设备就可以实现绝对免疫;另一类认为勒索攻击无法防御,只能被动等待事件发生。

首先,没有任何一套防护体系可以做到百分之百阻挡全部入侵。外部攻击者永远可以寻找新的漏洞、利用社会工程学手段寻找突破口。防护体系的核心目标不是保证绝对不会被入侵,而是做到:尽量抬高入侵门槛;即便攻击者取得初步立足点,也能够限制其横向移动范围;在攻击者完成大规模数据窃取向外传出之前检测到异常行为,及时阻断危害扩散。i2isystems 事件中最致命的不是攻击者拿到初始访问权限,而是整整一周时间攻击者可以不受约束完成侦察、横向移动、大批量数据导出,整套防御体系完全失去检测与约束能力。

其次,源代码泄露的次生风险具备长期性,即便入侵事件处置完毕,已经流出的代码会长期存在于网络空间,企业需要建立长期应对预案。迪妙网络空间安全学院研究团队指出,源代码泄露之后不能当作事件已经结束,企业应当安排安全研究人员对泄露代码开展自查,挖掘其中潜藏的漏洞,尽快完成全部相关系统补丁修复,防范其他攻击者利用外泄代码挖掘缺陷发起后续攻击。

再次,供应链风险具备传导属性,风险不会停留在网络边界。通信技术服务商处在产业链中间位置,上游对接运营商、安全机构,下游承接各类项目,自身安全缺陷会传导给业务伙伴。企业不能只关注自身 IT 资产安全,需要将供应链风险纳入整体安全规划。反网络钓鱼技术专家芦笛强调,很多企业做安全建设的视角局限于 “我的系统、我的数据”,数字化业务合作背景之下,数据流转跨越企业边界,安全风险同样随之跨越边界。

6 结论

Barracuda 勒索组织针对土耳其 i2isystems 的双重勒索攻击事件,是通信技术服务商面临勒索威胁的典型样本。攻击者并非依靠超高难度的漏洞突破,而是利用企业基础设施配置缺陷、内网缺少隔离管控、安全运营失效、供应链管控缺失等一系列短板,在一周内网驻留周期完成 693GB 数据外渗,其中 44GB 源代码泄露带来长期安全隐患,风险顺着业务合作链路传导至多家第三方合作机构,展现出现阶段双重勒索攻击的完整杀伤链与多重危害。

勒索软件防护已经不再局限于防止业务系统被加密,更核心的挑战在于防范大规模敏感数据被窃取外泄。通信技术服务商承载大量合作项目、源代码、合作方客户数据,风险传导效应相比普通企业更加突出。单纯依靠边界防火墙、杀毒软件无法应对该类威胁,必须从内网安全基线加固、高价值源代码资产专项防护、服务器侧数据外渗检测、备份底线保障、安全运营优化、供应链全流程管控、组织人员安全治理多个维度构建分层防御闭环。整套防御体系追求的不是绝对不被入侵,而是在入侵发生之后限制攻击者活动范围,在数据泄露出企业网络之前及时发现处置,降低事件造成的损失。

事件的应急处置和事后复盘同样是防御闭环不可或缺的部分,标准化的应急流程可以避免人为失误放大危害,复盘整改可以持续修补防御短板。面向未来,双重勒索攻击还会持续演化,针对供应链中间服务商的攻击活动会进一步增多。技术服务商需要改变重业务交付、轻安全基线的固有模式,正视内网横向移动、供应链传导风险,把安全评估嵌入项目从立项到运维的全生命周期。安全从业者也需要持续跟踪勒索组织攻击手法,完善针对内网侦察、横向移动、服务器端数据窃取场景的检测策略,帮助同类企业提升对抗双重勒索攻击的实际能力。

编辑:芦笛(公共互联网反网络钓鱼工作组)

来源:迪妙网络空间安全学院

目录
相关文章
|
7天前
|
人工智能 API 内存技术
刚刚 DeepSeek V4.1 Flash 开启内测,1 分钟教你用上!
刚刚 DeepSeek 内测群发布了 DeepSeek V4.1 Flash 中间版本内测的消息,这次的模型采用了新的结构,原生支持多模态、能力更强、速度更快、且成本更低。
1797 10
|
12天前
|
人工智能 运维 BI
阿里云千问办公QwenWork深度解析:基于Qwen3.8,六大核心能力重构企业全自动化工作流与计费选型指南
传统AI办公工具大多停留在对话问答、文档摘要、简单文案生成层面,只能完成单点碎片化任务,无法自主拆解复杂业务流程,很难串联多工具、多文档、外部业务系统完成端到端完整工作交付。很多企业在落地AI办公的时候,需要组合多款不同工具,来回切换界面,手动复制粘贴中间结果,智能化改造落地门槛居高不下。千问办公QwenWork是整合多款智能体产品能力打造的一体化企业办公智能体平台,底层基座依托Qwen3.8大模型,打通桌面端Agent、云端Agent、企业协同Agent三种运行形态,不再局限简单问答,接收业务目标之后自主拆解任务步骤,调用各类工具,处理文档、表格、浏览器自动化、数据查询,直接输出可交付的办公
1644 3
|
12天前
|
网络协议 Linux iOS开发
【2026实测】Wireshark下载+安装+汉化+使用教程(图文版,巨详细)
Wireshark 是一款免费开源的网络协议分析工具,可实时捕获、解析并可视化数据包,助你诊断网络故障、分析通信协议(如HTTP、DNS、TCP等)。支持Windows/macOS/Linux,含中文界面,新手入门便捷。(239字)
|
8天前
|
SQL 人工智能 前端开发
QoderWake 1.0 正式发布:从桌面里的 Agent,到工作现场的数字员工
QoderWake v1.0正式发布:企业级数字员工团队平台。支持“一句话建岗”,预置10类特训岗位;Waker常驻钉钉/飞书群,@即响应、自动协作、跨任务记忆;具备定时/事件/API多触发方式与统一任务看板;已沉淀27.6万条记忆、12.3万项技能,助力组织实现人机协同增效。
783 2
|
6天前
|
缓存 测试技术 API
DeepSeek V4.1 Flash 内测接入:改个模型名即可调用(附代码)
DeepSeek V4.1 Flash 内测不用申请,base_url 不变、改个模型名就能调,9/10 到期。本文讲清接入、计费限流与多模态注意点。
808 0
DeepSeek V4.1 Flash 内测接入:改个模型名即可调用(附代码)
|
20天前
|
人工智能 自然语言处理 安全
阿里云千问办公、Qoder Teams、Qoder CN区别与选择指南:模型能力、适用场景与最新活动参考
本文聚焦阿里云2026年推出的三款自研AI办公产品,清晰拆解千问办公、Qoder Teams、Qoder CN的差异化定位与能力边界:千问办公主打职场全场景提效,支持自然语言指令一键完成PPT生成、数据分析等高频办公任务;Qoder Teams面向程序员团队,深度整合AI代码生成、团队协同与企业知识库能力;Qoder CN则专为金融、政务等强合规场景打造,实现数据不出境与VPC私有化部署。文章同步给出分场景选型指南与最新活动定价,帮助不同类型的企业按需组合产品,实现业务岗、研发岗与强合规场景的AI能力全覆盖。
3974 5
阿里云千问办公、Qoder Teams、Qoder CN区别与选择指南:模型能力、适用场景与最新活动参考
|
11天前
|
人工智能 自然语言处理 安全
阿里云AI数智鉴密:AI 生成内容如何拿到一张"防篡改的身份证"
隐形水印 + C2PA签名:让AI生成内容“持证上岗”。
1156 0
|
13天前
|
缓存 数据可视化 开发工具
DeepSeek Harness 怎么更新?dsh 更新完整指南:更新本体(npx、npm、源码)与更新插件两种方式
DeepSeek Harness 的更新分两层:本体更新(npx 自动最新、npm update -g、源码 git pull)与插件更新(插件市场点更新、命令行覆盖安装)。本文按「准备 → 更新本体 → 更新插件 → 更新后检查」四步走,覆盖新手常见疑问。
1549 1
DeepSeek Harness 怎么更新?dsh 更新完整指南:更新本体(npx、npm、源码)与更新插件两种方式
|
6天前
|
人工智能
千问办公官网入口:阿里AI办公QwenWork产品页和免费网页端链接
千问办公官网含两大入口:一是网页端(qwenwork.cn),即开即用,支持浏览器直接访问;二是阿里云产品页 https://t.aliyun.com/U/JNKJuO 提供免费/付费版详情、功能介绍及使用指南。

热门文章

最新文章