文章来源：奇安信攻防社区
链接：https://forum.butian.net/share/3696
前言（概述） Agent Tesla 是一款自2014年就存在的密码窃取间谍软件，它通过记录按键和用户交互来收集有关受害者行为的信息。Agent Tesla使用.Net软件框架（大多数窃密恶意软件都是基于.NET框...
前言（概述）
Agent Tesla 是一款自2014年就存在的密码窃取间谍软件，它通过记录按键和用户交互来收集有关受害者行为的信息。
Agent Tesla使用.Net软件框架（大多数窃密恶意软件都是基于.NET框架开发的），其目的是窃取个人数据并将其传输回C2服务器，该恶意软件能够从Web浏览器、电子邮件客户端和FTP服务器访问信息。
此外，Agent Tesla恶意软件还能够捕获屏幕截图和视频，记录剪贴板信息和表单值。除了窃密行为外，该恶意软件还配备了多种持久性操作和规避技术。例如在系统重启后自动恢复运行，关闭Windows进程以保持隐藏。
Agent Tesla的传播主要通过垃圾邮件活动，通常是经过恶意文档或恶意网络链传递给受害者，访问这些maldocs或url后，有效负载将自动下载倒受害者的系统上，一般间谍软件会将自身保存在
%temp%
文件夹中，然后自动执行。
IOC
|
Hash
|
Value
|
|
SHA256
|
7512be2746137d9694e3ec3a83e8ab4c6e4d826798a04381de53d4c6973d519f
|
|
SHA1
|
0ccbe92478dca12afc4256bbfa0cefa95eed98d0
|
|
MD5
|
3a8596945040461302d54f41d5fa9fb9
|
样本下载地址（沙箱链接）：https://bazaar.abuse.ch/sample/7512be2746137d9694e3ec3a83e8ab4c6e4d826798a04381de53d4c6973d519f/?ref=embeeresearch.io
DIE分析
首先使用DIE查看一下该文件
一个**Nullsoft Scriptable Install System（NSIS）**打包的exe安装程序，NSIS会将一个
.nsi
脚本和其他程序打包起来,本质上是个压缩包,可以直接使用7-zip解压。
解压后可以得到三个文件，（理论上是还有一个nsi脚本的，但不知道为啥我解压出来没有）
cwlkewfbz.exe
对三个文件依次DIE分析
cwlkewfbz.exe
是一个32位的程序，（意外的居然不是.NET框架构建的）看上去没有混淆保护，查看一下信息熵：
没有高而平坦的区域。
通常从DIE分析一个恶意样本，可以查看基本信息，信息熵判断有无加壳或嵌入有效负载，字符串查看是否有可疑混淆或者一些明显的特征，导入表或导出表也可以发现一些常见于恶意行为的函数，此处查看一下导入表：
发现一个
VirtualAlloc
,该函数用于在地址空间分配内存，一般用于嵌入有效负荷。
djdqvq.sra
.sra
文件是一个二进制文件，基本信息没有，但是查看信息熵可以知道该文件被加密了。（高而平坦的曲线）
pgkayd.aq
.aq
文件同上。熵值不如上一个的的高，可能是低加密。
x32dbg动态分析
先对
cwlkewfbz.exe
进行分析。根据上面DIE分析和以往的经验判断，推测一下该exe中应该是藏有有效负荷的，即该exe只是一个Loader。
载入Xdbg中。
利用硬件断点提取shellcode
命令
bp VirtualAlloc
，F9运行：
程序直接跑飞了，说明从
Entry
到
VirtualAlloc
之间还存在某种反调试。
IDA静态分析
IDA32载入后，幸运的发现
VirtualAlloc
就在眼前，而且加密逻辑也很清晰，异或之后就执行代码了。
问题回到刚刚的 为什么
VirtualAlloc
之前就停止了呢？
时钟反调试
一处很简单的时钟反调试，由于沙箱或调试器的特性（经常将sleep设置为0）
这里先是
GetTickCount
获取自程序运行开始的时钟数，然后sleep了702毫秒（0x2BE=702毫秒，0x2BC=700毫秒）
睡眠之后再次
GetTickCount
，如果小于700则退出。
实际运行起来，发现这里并没有影响，将注意力放在
CreatFileA
上：
监视CreateFile
回顾一下该函数的定义：
根据函数的调用约定以及堆栈关系，可以知道
ecx
就是lpFileName，那么我们是否就可以根据该值来确定恶意软件要打开的文件是什么。（其实猜也猜到了，不是.aq就是.sra）
出现问题了，传入的ecx是0，也就是这一步导致后面的if判断都不可能实现。
最后问题还是回到
.nsi
脚本,该脚本可以控制包内应用程序的所有行为。后来发现是7-zip的版本太高了，一直降到15.05就可以提取到nsi脚本了。
使用notepad++查看一下：
看不懂，GPT解决一下，最后这句的意思就是，执行
cwlkewfbz.exe
传递
pgkayd.aq
作为参数。那么逻辑就清晰了，接着回到xdbg中，借助xdbg的File Command Line功能
Xdbg修复CreateFile
这样执行的时候，
pgkayd.aq
就会作为参数执行了。
给
CreateFileA
和
virtualalloc
下断点，运行
这次成功了。
解码shellcode
再次运行F9，就断在
VirtualAlloc
了。Ctrl+F9运行到函数结尾处，该值是
VirtualAlloc
的返回值，即分配内存的基地址。跳转过去到内存窗口：
在第一个字节处设置硬件断点
F9 之后再Ctrl+F9，直到所有缓存区都被填满：
然而这部分缓存由DB A3开头，不是熟知的4D5A，也不是shellcode常见的标识。推测该处不是我们要的有效负荷。也可以通过选中第一个字节，右键点击在反汇编窗口中显示，这样你可以看到与窗口对其的第一个命令是红色的问号。这表明该处是不正常的。
我们回到IDA中查看该处代码：
在执行恶意代码前，还对填充的数据做了一个异或操作。那么可以在后面执行处打一个断点，然后运行，直到全部解密完成。
最后能得到：
一块，E9 97 的内存区，看反汇编窗口也成功识别出了第一条指令。接着就选中所有的数据dump出来。得到dump.bin
手动分析shellcode
shellcode通常是一段二进制数据，不同于PE文件，无法使用IDA正常的去分析它。我们可以通过一个叫做Blobrunner的工具，将shellcode附加到这个工具上，再使用Xdbg附加该进程。
Ghidra静态分析
使用Ghidra分析的时候我们需要自己选择架构：
通常只要是 X86、32、little就可以了。
Ghidra分析完，从基地址的E9跳转过去可以看到如下：
调用一个函数 其中传入参数是一个十六进制值，该值类似于API哈希，我们可以用Google搜索验证这一点（该恶意软件也正是使用NSIS打包的）：
查看该API哈希函数，不同于使用0xD的API哈希函数。这里也有一个思路就是使用上图大佬给的hash算法来还原所有的API哈希。
当然这里学习如何解密一个未知的API哈希函数。
x32dbg调试API哈希
Blobrunner工具
Blorrunner是一个能够加载shellcode并提供可以使用调试器附加的进程的工具。这里我们从github上下载下来，和shellcode放在同一文件夹内，打开cmd 。运行
blobrunner.exe dump.bin
base:0x003e0000
x32dbg打开 附加进程：
设置断点
首先在基地址上 下一个断点，再在API哈希函数上下一个断点，从Ghidra中已知，基地址+0x73即为API哈希函数地址。
bp 0x003e0000
和
bp 0x003e0000+0x73
之后在blobrunner窗口点击任意按键，即可执行。
在xdbg中再次执行F9，断点会命中API哈希函数的push ebp。
在这里查看堆栈窗口，[esp+8]处即为我们要解的API哈希，刚刚Ghidra中可以知道程序往函数中传递了俩个参数，根据调用约定也可以知道，每当断在003E0073地址时，[esp+8]就是我们要求的API哈希。
这里Ctrl+F9执行到函数返回，API哈希函数的返回值当然就是解析出来的API名称了。
可以看到如下：
0x7F91A078被解析成了函数
ExitProcess
自动执行破解
我们可以通过不断F9，再Ctrl+F9的方法解析所有的API哈希，再对Ghidra修改函数名称来完成分析。但更好的是通过条件断点和日志来自动解析。
我们只需要在API哈希的起始处各设置一个条件断点，一个记录API哈希一个记录API名称。
具体可以参考最近几篇文章。可以得到如下：
深入分析
可以在命令中加多一句bp eax；这样可以自动给所有解密的API函数下一个断点
一直F9向下走，直到遇到可疑的地方：
lstrcatW
函数将一个字符串附加到另一个字符串。
创建文件
