ZeroAccess恶意软件分析
虽然最近学习了一些关于Rookit的技术，但感觉只是纸上谈兵，需要实际动手分析才能真正掌握。因此，选择了一个比较经典的Rookit恶意软件——ZeroAccess进行分析，提高个人的逆向分析能力。 ZeroAccess恶意软件分析报告
Emotet恶意软件变种分析
本文中，对12月初发现的样本进行分析。 Emotet恶意软件变种分析报告
Sodinokibi勒索病毒详细分析
Sodinokibi勒索病毒详细分析
Wannacry勒索病毒分析
Wannacry又称“永恒之蓝”，该病毒分为蠕虫传播和勒索病毒部分，这里只分析勒索病毒部分。 Wannacry勒索病毒分析报告
Radamant勒索病毒分析
Radamant勒索病毒分析
PHPStudy后门分析
PHPStudy后门分析 由于PHPStudy遭受了供应链攻击, PHPStudy软件安装包中的php_xmlrpc.dll模块隐藏有后门. 其中, 影响的版本包括PHPStudy 20161103和PHPStudy 20180211. 经过分析, 该后门的核心功能模块有两部分: 第一是通过判断特殊的HTTP头执行远程PHP代码; 第二个是通过判断特殊的HTTP头后连接C&C服务器并执行回传的PHP代码. 实验环境: Windows 7(32位) , PHPStudy 20181103 版本 php-5.2.17/ext 扩展文件夹下的php_xmlrpc.dll. 样本信息 名称 php_xmlrpc.dll SHA256 aea021c5d79adbdc8a755d2f56db4f2e71781abbdcce2a2fa6e04aff3c02be75 类型 32位DLL 大小 73,728Byte...
API钩取--API代码修改技术
API代码修改技术原理 当库文件被加载到进程内存后, 在其目录映像中直接修改要钩取的API代码本身, 这就是API代码修改技术 (Code Patch). API代码修改技术将API的前5个字节修改为JMP XXXXXXXX指令来钩取API. 调用执行被钩取的API时, (修改后的)JMP XXXXXXXX指令就会被执行, 转而控制hooking函数, 从而实现API Hook. 例如, 向Process Explorer进程 procexp.exe注入stealth.dll文件后钩取ntdll.ZwQuerySystemInformation(), ntdll.ZwQuerySystemInformation()API 是为了隐藏进程而需要钩取的API.具体的流程如下: 首先把stealth.dll注入目标进程, 钩取ntdll.ZwQuerySystemInformation()API. ntdll.ZwQuerySystemInformation()API起始地址的5个字节代码被修改为JMP 10001120, 10001120是stealth.MyZwQuerySystemInformation()API. procexp.exe某地址处调用ntdll.ZwQuerySystemInformation()(地址7C93D92E). 地址7C93D92E处的 (修改后的)...
API钩取--DLL注入实现IAT钩取
IAT 钩取工作原理 IAT钩取是通过修改IAT中保存的API地址来钩取某个API, 即需要将要钩取的API在用户注入的DLL中重定义, 然后再注入目标进程. 这种方法的缺点是, 如果想要钩取的API不在目标进程的IAT中, 那么就无法使用该技术进行钩取操作. 换言之, 如果要钩取的API是由程序代码动态加载DLL文件而得以使用的, 那么将无法使用这项技术钩取它. 例如, 先向目标进程 (calc.exe) 注入用户DLL (hookiat.dll), 然后在 calc.exe进程的IAT区域SetWindowTextW对应的地址更改为hookiat.dll中用户自定义的Hook函数地址. 这样当 calc.exe调用SetWindowTextW时, 就会跳转至hookiat.dll中的Hook函数, Hook函数执行到最后时调用SetWindowTextWAPI, 即可完成在该API功能正常的情况下监控API的参数和返回结果. 修改 IAT 实现计算器 SetWindowsTextW() API...
API钩取--调试技术
调试技术工作原理 调试进程经过注册后, 每当被调试者发生调试事件 (Debug Event) 时, OS就会暂停其运行, 并向调试器报告相应事件. 调试器对相应事件做适当处理后, 使被调试者继续运行. 一般的异常 (Exception) 也属于调试器. 若相应进程处于非调试, 调试事件会在其自身的异常处理或OS的异常处理机制中被处理. 调试器无法处理或不关心的调试事件最终由OS处理. 调试器必须处理的是 EXCEPTION_BREAKPOINT异常, 汇编指令为 INT3, IA-32指令为0xCC. 调试技术的基本思路: 在 “调试器-被调试者”的状态下, 将被调试者的API起始部分修改为0xCC, 控制权转移到调试器后执行指定操作, 最后使被调试者重新进入运行状态.具体的调试流程如下:...
使用堆绕过SafeSEH机制
SafeSEH 对异常处理的保护原理 在Windows XP SP2 及后续的操作系统中, 微软引入了SEH校验机制SafeSEH.SafeSEH的原理如下: 在程序调用异常处理函数前, 对要调用的异常处理函数进行一系列的有效性校验, 当发现异常处理函数不可靠时将终止异常处理函数的调用. 在VS 2003及后续的版本中, 链接选项中的/SafeSEH选项是默认启用的, 这可以让编译好的程序具备SafeSEH功能. 启用该选项后, 编译器在编译程序的时候将程序所有的异常处理函数地址提取出来, 编入一张安全SEH表, 并将这张表放到程序的映像里面. 当程序调用异常处理函数的时候会将函数地址与安全SEH表进行匹配, 检查调用的异常处理函数是否位于安全SEH表中. 在VS命令提示行, 执行dumpbin /loadconfig filename可以查看程序安全SEH表的情况, 如下图所示: SafeSEH机制首先调用了RtlDispatchException()函数判断: 异常处理链是否位于当前程序栈中;...
绕过GS的栈溢出攻击原理
GS安全编译选项保护原理 针对缓冲区溢出时覆盖函数返回地址这一特征, 微软在 VS 7.0及以后的VS版本中默认启用了GS安全编译选项，其基本原理如下: 在所有函数发生调用时，向栈帧内压入一个额外的随机DWORD, 被称为canary或者Security Cookie Security Cookie位于EBP之前, 系统还会在.data的内存区域存放一个Security Cookie副本 当栈中发生溢出时,Security Cookie将首先被淹没, 之后才是EBP 和返回地址 在函数返回之前, 系统将执行一个额外的安全验证操作, 被称作Security check 在Security check过程中, 系统比较栈帧中原先存放的Security Cookie和.data中副本的值, 如果两者不吻合, 说明栈帧中的Security Cookie 已被破坏, 即栈中发生了溢出 若检测到栈中发生溢出,...
How To Use Markdown
Headers # H1 ## H2 ### H3 #### H4 ##### H5 ###### H6 H1 H2 H3 H4 H5 H6 Text formatting - **Bold** - _Italics_ - ~~Strikethrough~~ - <ins>Underline</ins> -...