Skip to content

2025

IoM v0.1.0 代替CobaltStrike的最后四块碎片

经过几个月的时间,带来了四大全新组件, 以及十几个较大的功能性更新与数百个修复与优化。

与之前一样,在更新公告中的内容都将会在community版本中提供

四大新组件:

  • 基于vscode extension的GUI客户端
  • 基于lua脚本语言的插件系统以及迁移了数百个插件的基础插件生态
  • 基于rem实现的代理/隧道功能组
  • 类似BeaconGate的动态函数调用和Ollvm

当然目前与CobaltStrike对比不免有些不自量力(因缺少大量实战测试修复各种bug)。但这也代表IoM主体功能的阶段性成果。IoM不再是一个实验室中的demo, 而是能初步用于实战的工具。

CobaltStrike最大的护城河是丝滑的GUI客户端, 稳定的beacon,以及丰富的插件生态。以至于抹平其OPSEC上的劣势。 而现在CobaltStrike的二开止步4.6, 破解版本停滞在4.10, 主流的CobaltStrike的使用者逐渐远离了其最新版本。 这让IoM有机会成为CS的备选品(我们承认距离代替CS还有不小的距离)。

攻防场景中的网络侧对抗革命 (上) rem

前言

有一个笑话,"中国人的网络水平特别好". 事实上也确实如此, 绝大部分代理相关的工具都和中国开发者有关.

我们已经有了很多好用的代理工具,如下面提到的这部分:

  • frp 最常使用, 最稳定的反向代理工具. 配置相对麻烦, 有一些强特征已被主流防护设备识别, 类似的还有nps, ngrok, rathole, spp. 不支持反向端口转发
  • gost 一款强大的正向代理工具, v2版本不支持反向代理, v3开始支持更多种多样的流量操作方式, 未来可期.
  • iox 轻量但稳定的端口转发工具, 但是通讯不加密
  • stowaway 多级代理工具, 支持正反向代理, 但是进支持TCP/HTTP/WS协议通讯. 类似的工具还有lcx,termite,earthworm.

从使用场景覆盖来说, 这些工具加起来确实覆盖了关于 proxy/tunnel 的90%以上场景, 但如frp,gost, iox 这些工具设计上并不是给攻防场景使用的, 现在的NDR设备可以轻松捕获他们的特征. 并且往往是单个工具只解决了部分场景的需求, 不能覆盖所有场景。

IoM GUI 内测招募

Intro

IoM 的v0.1.0 的开发工作还需要一段时间, 但GUI已经开启了抢先测试. 测试不限名额, 发布在 https://github.com/chainreactors/malice-network/releases/tag/nightly

可以参考下面的安装流程安装GUI.

IoM-GUI采用vscode extension的形式实现, 不是传统的GUI client, 也不是WEB GUI。 我们尝试了一种前所未有的C2 GUI形式, 原因有很多:

  • vscode 已经是目前现代化,兼容最多场景的IDE, 它提供的基座让我们能自然而然的实现跨屏与各类场景覆盖
  • vscode 集成了文件浏览,终端,远程开发,代理等等功能, 而C2也有这些功能,可以直接接入到vscode实现无缝的交互
  • vscode本身就是IDE, 可以进行二次开发, 插件开发等, 可以让开发与后渗透无缝进行
  • vscode 提供了最优秀的AI集成,后续会尝试将AI接入到GUI的工作流中
  • ......

要从零实现一个GUI大概率会很平庸, 但是我们计划最大程度利用vscode的各种特性,打造一个最好用的C2-GUI。

警告:

目前提供的版本是早期测试版,每天都会自动基于最新的commit打包,是极不稳定的状态

拓展golang代理的边界 proxyclient

前言

本文是rem发布前的前菜, 是在实现rem过程中的附带产物,但因其可以被使用在大量其他组件中, 故将其抽象出来作为独立的库使用。

TLNR:

repo: https://github.com/chainreactors/proxyclient

wiki: https://chainreactors.github.io/wiki/libs/proxyclient/

golang 代理的背景知识

众所周知, golang上有着远超其他任意语言的网络相关的生态库。 各种应用也层出不穷,从安全领域常用的iox,frp,nps 到网络代理gost, xray, v2ray, 以及相对底层的网络协议实现库如kcp,quic, rawpacket, 还有最重要的标准库提供的密码学库(crypto和tls)及其优雅的抽象。

越来越多的扫描器也都基于golang实现,这也包括了我在多年前编写的扫描器gogo。 在gogo开发的早期我对使用代理去扫描是有偏见的,这源于我对网络协议和golang设计上的了解不够深入,还有一个重要原因是标准库库中的proxy提供了很好的抽象, 但是在具体实现上略显混乱。 这也导致了很长一段时间gogo的代理扫描实际上是误用了,让我一直以为只有socks5协议能代理socket。

IoM进阶系列(1) PELoader&RDI的TLS之殇

从一个崩溃开始的 PE Loader 救赎之旅

本系列文章虽然叫做IoM进阶系列, 但实际与IoM关系不大,只是在开发IoM的过程中遇到的。进阶系列均为解决前无古人的问题、创新等, 本文将从最常用的技术 PE-Loader开始。

如果读者已经熟知PE加载, 那么本文的内容将不会有非常大的革新, 但各位阅读完本文可能也会看到一些新鲜玩意, 聊以慰籍 :)

今年8月, 我们推出了下一代 C2 计划 -- Internal of Malice , 旨在实现一套 post-exploit 基础设施, 在implant的语言选用中, 我们尝试了这两年最火热的红队语言:Rust, 也因为这个选择,在实现过程中遇到了和解决了非常多有意思的问题。

在推出stager 版本之后, 交流群的一位同学贴出了Writing a PE Loader for the Xbox in 2024 这篇文章, 用一种非常粗暴的方式解决了 Rust在使用MSVC编译时引入了TLS(thread-local storage) , 而只常见的PELoader 简单调用 tls callback 无法正常加载 PE 文件的问题, 遂成文。