HackerNews 编译，转载请注明出处： 网络安全研究人员发现了一场攻击活动，该活动利用多个软件漏洞窃取系统数据，并将数据存储在基于云的安全平台中。 研究人员发现，威胁行为者使用 Elastic Cloud 安全信息与事件管理（SIEM）平台的免费试用实例，从数十家机构的受入侵系统中收集和分析数据。 该活动由 Huntress 公司的研究人员发现，他们观察到攻击者利用广泛使用的企业软件中的漏洞，包括 SolarWinds Web Help Desk。 攻击者并未使用传统的命令与控制（C&C）基础设施，而是将受害者数据直接外传到由攻击者控制的 Elastic Cloud 实例中，实际上将一款合法的安全监控工具变成了窃取信息的存储库。 将 Elastic 试用版用作数据中心与 VPN 基础设施 调查显示，攻击者在受入侵系统上执行一段经过编码的 PowerShell 命令，用于收集详细的主机信息。该脚本收集操作系统信息、硬件配置、Active Directory 数据以及已安装补丁信息，然后将其传输到名为 “systeminfo” 的 Elasticsearch 索引中。 研究人员表示，这种战术使攻击者能够使用本应用于防御性安全监控的 SIEM 工具对受害者进行分类，并确定攻击目标优先级。 用于此次攻击的 Elastic Cloud 实例创建于 2026 年 1 月 28 日，并持续运行了数天。遥测数据显示，攻击者通过 Kibana 界面对该环境进行反复操作，在检查传入的受害者数据期间执行了数百次操作。 进一步分析显示，该试用账号使用了一个与 quieresmail.com 域名关联的一次性电子邮件地址注册。调查人员认为，该地址格式与俄罗斯注册的临时邮件网络 firstmail.ltd 有关，该网络运营着数百个一次性域名。 其他证据表明，攻击者在其整个基础设施中重复使用随机的 8 字符标识符，包括电子邮件注册信息以及在 Cloudflare Worker 页面上托管工具所用的子域名。 对该 SIEM 实例的管理员登录行为被追溯到据信来自 SAFING VPN 隐私网络隧道的 IP 地址。 数百台系统受影响 从攻击者的 Elastic 环境中恢复的数据显示，该攻击活动影响了至少 216 台主机，涉及 34 个 Active Directory 域。大部分受入侵设备为服务器，其中最常见的是运行 Windows Server 2019 或 2022 的系统。 受害者遍布多个行业，包括： ·     政府机构 ·     大学及教育机构 ·     金融服务公司 ·     制造业与汽车企业 ·     IT 服务提供商与零售商 部分主机名表明，攻击者还在利用其他企业平台中的漏洞，包括 Microsoft SharePoint。 研究人员已与 Elastic 公司及执法部门协作，通知受影响机构并对相关基础设施展开调查。此次活动中使用的云实例现已被下线。 Huntress 在其博客中表示：“我们已对我们认为在被发现数据中涉及的机构进行了联系与受害者通知，并与 Elastic 展开协作，进一步调查并下线该威胁行为者的基础设施。”   消息来源：infosecurity-magazine.com； 本文由 HackerNews.cc 翻译整理，封面来源于网络； 转载请注明“转自 HackerNews.cc”并附上原文

HackerNews 编译，转载请注明出处： Iconics Suite SCADA 系统存在一项中危漏洞，攻击者可利用该漏洞在关键工业控制系统上触发拒绝服务状态。 该漏洞编号为 CVE-2025-0921，广泛部署于汽车、能源及制造业的监控与数据采集（SCADA）基础设施。 漏洞详情 CVE-2025-0921 源于三菱电机 Iconics Digital Solutions 的 GENESIS64 软件中，多个服务存在“以不必要权限执行”的安全缺陷。 该漏洞 CVSS 评分为 6.5 分，评级为中危。攻击者成功利用该漏洞后，可滥用特权文件系统操作提升权限、破坏核心系统二进制文件，最终导致系统完整性与可用性受损。 此漏洞由 Unit 42 的研究员 Asher Davila 和 Malav Vyas 在 2024 年初的一次全面安全评估中发现。这是在微软 Windows 平台的 Iconics Suite 10.97.2 及更早版本中发现的 6 项漏洞之一。此前研究人员已披露该 SCADA 平台存在的 5 项相关漏洞，CVE-2025-0921 是后续调查中发现的新增威胁。 根据三菱电机的安全公告，该漏洞影响 GENESIS64、MC Works64 的所有版本以及 GENESIS 11.00 版本。Iconics Suite 在全球超过 100 个国家拥有数十万安装实例，遍布政府设施、军事基地、水处理厂、公共事业及能源供应商等关键基础设施领域。 技术原理与利用途径 该漏洞存在于工业流程监控告警管理系统 AlarmWorX64 MMX 的 Pager Agent 组件中。 具备本地访问权限的攻击者，可通过篡改 C:\ProgramData\ICONICS 目录下 IcoSetup64.ini 文件中存储的 SMSLogFile 路径配置来利用该漏洞。攻击链流程包括：将日志文件存储路径创建为指向目标系统二进制文件的符号链接。当管理员发送测试消息或系统自动触发告警时，日志信息会沿符号链接覆盖核心驱动文件（如为 Windows 系统组件提供加密服务的 cng.sys）。 系统重启后，被破坏的驱动会导致启动失败，设备陷入无限修复循环，最终使工业控制（OT）工程工作站无法运行。 研究人员证实，该漏洞与 CVE-2024-7587 漏洞结合后利用难度会大幅降低；CVE-2024-7587 是此前披露的 GenBroker32 安装程序漏洞，会给 C:\ProgramData\ICONICS 目录赋予过高权限，允许任意本地用户修改核心配置文件。但即便单独利用该漏洞，若日志文件因配置不当、其他漏洞或社会工程学攻击具备可写权限，攻击者仍可成功触发漏洞。 三菱电机已为 GENESIS 11.01 及后续版本发布修复补丁，客户可从 Iconics 社区资源中心下载。针对 GENESIS64 用户，修复版本正在开发中，将于近期发布。厂商明确表示暂无 MC Works64 版本补丁发布计划，相关客户需在此期间落实漏洞缓解措施。 消息来源: cybersecuritynews； 本文由 HackerNews.cc 翻译整理，封面来源于网络； 转载请注明“转自 HackerNews.cc”并附上原文

HackerNews 编译，转载请注明出处： 俄罗斯媒体The Bell发布了一篇深度报道，揭秘今年 7 月俄罗斯国家航空公司俄罗斯国际航空公司（俄航，Aeroflot）遭遇的重大黑客攻击事件，证实该公司当时整个基础设施曾濒临崩溃边缘。 早在 7 月，两个亲乌黑客组织 ——“沉默乌鸦（Silent Crow）” 和 “白俄罗斯网络游击队（Belarusian Cyber-Partisans）” 就已宣称对这起针对俄航的攻击负责。 黑客们不仅瘫痪了 7000 台服务器、窃取了乘客及员工数据，还控制了包括高管在内的员工个人电脑。他们透露，此次行动是一场耗时一年的俄航网络渗透计划。 不过，当时现场的实际情况究竟如何？据The Bell报道，与其他多起规模较小的同类攻击不同，俄航遇袭事件根本无法被俄罗斯官方掩盖：数百架航班延误或取消，数千名乘客滞留于大大小小的机场。 尽管如此，俄航仍试图隐瞒。The Bell指出，该航空公司甚至未告知内部员工公司正遭受黑客攻击，反而将事件定性为 “信息系统故障”。但事实上，攻击者当时已险些摧毁其全部基础设施。 紧急切断全楼电源 这场攻击始于 7 月 28 日凌晨 5 时，彼时俄航技术支持群内开始上报紧急情况：系统瘫痪、电脑反复重启且无法恢复。 两小时后，在确认黑客正实时擦除员工办公电脑数据后，俄航下达了 “全面停机” 的指令。 《The Bell》的消息源透露，当时切断总部所有楼层的电源，是阻止攻击者彻底摧毁公司全部网络基础设施的唯一办法。 这是因为，正如黑客后续所言，且有匿名俄航官员向《The Bell》证实的那样，他们已获取了航空公司整个企业网络的管理员权限。 随后，攻击者在俄航企业网络中推送了一项组策略，触发了工作站的定时数据擦除程序。局势一度濒临全面失控 —— 不过俄航团队的应对其实十分迅速。 一位接近仍在进行中的调查的消息人士解释道：“他们切断了与俄罗斯电信公司（Rostelecom）的通信，中断了与机票数据库的连接，还断开了和谢列梅捷沃机场的链路，以至于工作人员只能靠 Excel 表格重建所有数据，在大幅纸上重新绘制全部航线。” “这无疑对公司声誉造成了损害。但如果当时没有如此迅速地行动，公司的基础设施恐怕会荡然无存。” 事发当天，俄航共取消 108 架次航班，仅在其枢纽机场谢列梅捷沃机场，就有超 80 架次航班延误。该航空公司称，此次航班取消造成的损失至少达 2.6 亿卢布（约合 334 万美元）—— 但这个数字其实并不算多。 薄弱环节：合作承包商 尽管直接经济损失有限，此次攻击造成的整体危害却极大。《The Bell》指出，被窃取的数据中，“非商业航班” 相关信息或为最敏感的内容。 原因在于，攻击发生后，黑客公布了一份由俄国防部代表签署的文件，文件中国防部要求将其设备接入俄航内部网络，以 “高效规划军事空运任务”。 一位俄航消息人士指出：“这对俄航是沉重一击。该公司一直将自身定位为纯民用航空公司，过去几年也一直在刻意与战事保持距离，而这份文件却将一切白纸黑字地摆到了台面上。” 该人士认为，这或许正是此次网络攻击的核心目的。 此次攻击的初始入口，似乎是一家名为巴卡软件（Bakka Soft）的小型 IT 公司。该公司负责为俄航开发移动及网页应用，且在攻击发生前一个月，还刚宣布推出了俄航新版 iOS 网页应用。 《The Bell》称，早在 2025 年 1 月，也就是攻击发生前 6 个月，为俄航提供技术支持的 IT 专家就已在俄航及巴卡软件的网络中监测到了可疑活动。 巴卡软件从未公开披露其系统遭黑客入侵的消息，但种种迹象表明入侵确实发生过。 白俄罗斯网络游击队的代表尤利娅娜・舍梅托维茨（Yuliana Shemetovets）指出，俄航管理层使用的是简单且极易被破解的密码。 网络安全专家虽已将入侵者逐出俄航系统，但消息人士称，他们并未彻底清理巴卡软件的基础设施，这使得攻击者得以着手筹备后续的网络攻击。 《The Bell》的一位消息人士惋惜道：“这类事件中，承包商往往是薄弱环节：他们难以及时取得联系、会抗拒配合调查、不允许访问其基础设施，而且基础设施的清理工作也做得一塌糊涂。” 该媒体还联系到白俄罗斯网络游击队代表尤利娅娜・舍梅托维茨，她也指出俄航管理层存在使用简易密码的问题。   消息来源：cybernews； 本文由 HackerNews.cc 翻译整理，封面来源于网络； 转载请注明“转自 HackerNews.cc”并附上原文

据观察，一个名为 “Twelve ”的黑客组织使用大量公开工具对俄罗斯目标实施破坏性网络攻击。 卡巴斯基在周五的分析中表示：与要求赎金解密数据不同，该组织更倾向于加密受害者的数据，然后使用擦除器破坏他们的基础设施，以防止恢复。 这表明，他们希望对目标组织造成最大程度的损害，而不是直接获得经济利益。 据悉，该黑客组织是在2023年4月俄乌战争爆发后成立的，曾发起过多次网络攻击事件、窃取敏感信息，然后通过其Telegram频道分享这些信息。 卡巴斯基称，Twelve 与一个名为 DARKSTAR（又名 COMET 或 Shadow）的勒索软件组织在基础架构和战术上有重合之处，因此这两个黑客组织很可能相互关联，或者是同一活动集群的一部分。 俄罗斯网络安全厂商说：Twelve 的行动明显具有黑客活动的性质，而 DARKSTAR 则坚持典型的双重勒索模式。集团内部目标的这种变化凸显了现代网络威胁的复杂性和多样性。 攻击链首先通过滥用有效的本地或域账户获得初始访问权限，然后使用远程桌面协议（RDP）进行横向移动。其中一些攻击还通过受害者的承包商实施。 卡巴斯基指出：为此，他们获得了承包商基础设施的访问权限，然后使用其证书连接到客户的 VPN。在获得访问权限后，对手可以通过远程桌面协议（RDP）连接到客户的系统，然后侵入客户的基础设施。 Twelve 使用的其他工具包括 Cobalt Strike、Mimikatz、Chisel、BloodHound、PowerView、adPEAS、CrackMapExec、Advanced IP Scanner 和 PsExec，用于窃取凭证、发现、网络映射和权限升级。与系统的恶意 RDP 连接通过 ngrok 传输。 此外，还部署了具有执行任意命令、移动文件或发送电子邮件功能的 PHP web shell。这些程序（如 WSO web shell）在 GitHub 上随时可用。 在此前的一起事件中，卡巴斯基称威胁分子利用了VMware vCenter中的已知安全漏洞（如CVE-2021-21972和CVE-2021-22005），提供了一个web shell，然后利用这个web shell投放了一个名为FaceFish的后门。 攻击者使用 PowerShell 添加域用户和组，并修改 Active Directory 对象的 ACL（访问控制列表）。而为了避免被发现，攻击者将恶意软件和任务伪装成现有产品或服务的名称。攻击者通过使用包括 “Update Microsoft”、“Yandex”、“YandexUpdate ”和 “intel.exe”等名称伪装成英特尔、微软和 Yandex 的程序来逃避检测。 这些攻击的另一个特点是使用 PowerShell 脚本（“Sophos_kill_local.ps1”）来终止受攻击主机上与 Sophos 安全软件相关的进程。 最后阶段需要使用 Windows 任务调度程序来启动勒索软件和清除器有效载荷，但在此之前要通过名为 DropMeFiles 的文件共享服务以 ZIP 压缩文件的形式收集和渗出受害者的敏感信息。 卡巴斯基研究人员说：攻击者使用了一个流行的 LockBit 3.0 勒索软件版本，该版本由公开源代码编译而成，用于加密数据。在开始工作之前，勒索软件会终止可能干扰单个文件加密的进程。 与Shamoon恶意软件相同的擦除器会重写所连接驱动器上的主引导记录（MBR），并用随机生成的字节覆盖所有文件内容，从而有效防止系统恢复。 卡巴斯基研究人员指出：该组织坚持使用公开的、人们熟悉的恶意软件工具，这也表明它没有自制的工具，那么大家就还是有机会能及时发现并阻止 Twelve 的攻击。     转自Freebuf，原文链接：https://www.freebuf.com/news/411472.html 封面来源于网络，如有侵权请联系删除

近期的一些教训提醒了美国五角大楼官员，使用商业云时需要采取额外的安全措施。为此，他们决定自己亲自动手进行查验。 五角大楼代理正职的副首席信息官大卫·麦考恩（David McKeown）在上周三AFCEA TechNet网络会议的小组讨论中表示，“近期发生的一系列事件表明，我们可能需要解决某些可见性问题，也许应该从外部视角来观察服务商为我们建造的云环境。” 美国国防部采购的云服务商会使用“一套严格的检查”，包括建立持续监控，并定期向国防部上报检查结果。 但泄露事件仍时有发生。为了防患于未然，国防部希望能够定期检查服务商代表客户运营的云基础设施。 麦考恩向外媒Defense One表示，“我们希望能了解基础设施周边发生了什么，甚至以内部的红队角度开展深入研究。” “因为一旦有人侵入云服务的管理程序…就相当于掌握了打开王国大门的钥匙。我们想确保服务商所拥有的一切都安全可靠，并且随着时间推移始终保持稳定。” 这个概念本身并不新鲜。2023年国防授权法案中的一项条款就授权五角大楼对保存机密级数据的云基础设施开展威胁评估。麦考恩表示，国防部一直在与云服务商合作，为定制的（而非商用的）云系统探索安全路径，并且迄今为止“还没有遇到过太大的阻力”。 麦考恩还提到，新的检查将采取“主动防御”形式，例如扫描IP地址以查找各类系统上的漏洞。 “我们可以开展外部扫描，看看有什么被暴露在了互联网上。如果确实易受攻击而且我们发现了问题，就会提醒供应商立即着手处理。在云端，我们也会采取同样的措施。” 近年来，五角大楼经历了多起数据泄露事件，包括今年2月美国特种作战司令部服务器的敏感邮件暴露事件，该服务器没有设置保护密码。 麦考恩在小组讨论中指出，“每当看到事件发生，都会出现我们把所有鸡蛋都放进云服务这个篮子里的批评声音。但我想用亲身经历向大家证明：我们也曾在部门之内构建并保护过各种系统，其实际水平远无法与云服务商的方案相提并论。” 总之，“我们双方必须在网络安全领域取得成功，这样才能携手并进、共赴未来。”     转自 安全内参，原文链接：https://www.secrss.com/articles/54472 封面来源于网络，如有侵权请联系删除