飞星勒索病毒v1.1

菜叶片

上次主程序直接遍历硬盘 也是直接寄了新版本更新

[+] 反射型DLL注入explorer.exe
注入器 VT 70/72未检出 https://www.virustotal.com/gui/f ... a98d56cd4c2ae701542
加密器 DLL VT 68/71未检出 https://www.virustotal.com/gui/f ... 251fe3affcee1595878


微步云沙箱是过不了了 因为加密器 卡巴斯基报毒了 XD

至于1.0版本有人说Indirect Syscall 还有用了sw3
我没有找到比sw3动态解析NtDLL方案更优秀的开源项目 只引用了解析PEB那几个函数 并没有被特征
这个奇怪的Indirect Syscall方案...用户模式绕过肯定没问题了 但是杀软是有内核驱动的呀。。
再怎么完美的Indirect Syscall也没法绕过内核回调的

1.1版本的话...应该也很菜 至少我用BitDefender TotalSecurity测 是 注入立即被杀 哎 还是逃不过行为检测

需要Visual C++分发版运行库
已在Github开源
https://github.com/CNMrSunshine/StarFlyCryptor/

已知BUG（影响程序运行）
当注入器所在NT路径字符串长度>210（MAX_PATH常量）时 会因缓冲区溢出崩溃

已知BUG（不影响程序运行）
程序编译时务必关闭编译器优化 且选择“用于编辑和继续的调试信息库” 并关闭生成调试信息
原因：未知原因导致系统调用后 需要填充的缓冲区地址被改到主程序映像内 若启用编译优化 会在被写入的地址造成执行访问冲突

Fadouse

DI 解压杀

DisaPDB

有没有一种可能间接系统调用和内核回调没半毛钱关系？
你使用的注入函数（内存管理或线程管理）微软已提供的内核回调没有提供监控点
不然你觉得ETW-Ti是用来干什么的……

菜叶片

DisaPDB 发表于 2025-2-2 18:19
有没有一种可能间接系统调用和内核回调没半毛钱关系？
你使用的注入函数（内存管理或线程管理）微软已提供 ...

没有监控点 那怎么检测出间接系统调用的 调用堆栈是
NtDll.dll!Nt*
NtDll.dll!NtQuerySystemTime
Kernel32!GetSystemTime
没有任何可以设置hook的点 执行流被异常处理器重定向后直接指向Syscall所在地址 然后就进入内核模式了呀
Gemini2.0的回复 线程创建和文件操作是有对应的内核回调函数的
内核回调是一种机制，允许驱动程序或其他内核组件在特定事件发生时执行预定义的回调函数。这些事件包括：[color=var(--vscode-foreground)]
[color=var(--vscode-foreground)]



进程创建/终止: 当进程被创建或终止时。[color=var(--vscode-foreground)]
[color=var(--vscode-foreground)]



线程创建/终止: 当线程被创建或终止时。[color=var(--vscode-foreground)]
[color=var(--vscode-foreground)]



模块加载/卸载: 当驱动程序或其他内核模块被加载或卸载时。[color=var(--vscode-foreground)]
[color=var(--vscode-foreground)]



文件操作: 当文件被打开、读取、写入或关闭时。[color=var(--vscode-foreground)]
[color=var(--vscode-foreground)]



注册表操作: 当注册表项被访问或修改时。[color=var(--vscode-foreground)]
[color=var(--vscode-foreground)]



网络操作: 当网络连接被建立或关闭时。[color=var(--vscode-foreground)]
[color=var(--vscode-foreground)]



系统调用: 在系统调用发生之前或之后。

DisaPDB

菜叶片 发表于 2025-2-2 18:24
没有监控点 那怎么检测出间接系统调用的 调用堆栈是
NtDll.dll!Nt*
NtDll.dll!NtQuerySystemTime

你都知道是调用堆栈了那还说什么内核回调……sw3是通过手段让syscall发生的地址在ntdll内部，但是不可能准确定位到真实地址，所以栈回溯依然能够检测出来
还有你在哪里看到的能够监控所有线程管理的回调，不就一个PsSetCreateThreadNotifyRoutineEx吗

lsop1349987

avast双击kill
McAfee寄
HMPA拦截，但只有记录没有全屏警报

菜叶片

DisaPDB 发表于 2025-2-2 18:27
你都知道是调用堆栈了那还说什么内核回调……sw3是通过手段让syscall发生的地址在ntdll内部，但是不可能 ...

我的程序引用了sw3是为了得到每个Nt*函数对应的syscall机器码在ntdll的地址 和系统调用号
当然 这些也可以硬编码 sw3并不重要
我的自定义Nt*函数先调用了GetSystemTime 因此触发在GetSystemTime入口点的硬件断点
被Hook到NtQuerySystemTime 又触发硬件断点
最终被Hook到实际要调用的Nt*函数
调用链很完整
唯一的漏洞可能就是 在返回的时候 未知原因触发了访问异常 随后被异常处理器跳过了

隔山打空气

菜叶片 发表于 2025-2-2 18:24
没有监控点 那怎么检测出间接系统调用的 调用堆栈是
NtDll.dll!Nt*
NtDll.dll!NtQuerySystemTime

这么说吧，你用的操作文件那些API是有内核回调监控点的，所以IDSC对其完全无效，不需要给自己加工作量

你现在要做的就是，把你注入器里面用的那些内存管理函数（比如说NtAllocateVirtualMemory）的调用方式换成IDSC，因为这些函数是没有内核回调监控点的，这样就能有效提高绕过能力

菜叶片

隔山打空气 发表于 2025-2-2 18:33
这么说吧，你用的操作文件那些API是有内核回调监控点的，所以IDSC对其完全无效，不需要给自己加工作量

...

..刚刚才发现导出表有问题
NtCreateFile
NtQueryInformationFile
RtlCaptureContext
RtlInitUnicodeString
RtlLookupFunctionEntry
RtlVirtualUnwind
我的自定义函数得不到返回的NTSTATUS 用来调试换成了真的Nt*函数 忘记换回去了
但是其他Nt*函数都是间接系统调用

DisaPDB

菜叶片 发表于 2025-2-2 18:33
我的程序引用了sw3是为了得到每个Nt*函数对应的syscall机器码在ntdll的地址 和系统调用号
当然 这些也可 ...

本身syscall的目的是为了绕过用户态钩子让edr无法判断ntapi的真实调用方，你这种调用方式已经让系统调用无效化了
顺便提一嘴，未知异常可以自定义VEH来吞 或者你直接Hook VEH也行