該病毒利用加密算法對文件進行加密,使得用戶無法對文件進行正常操作
運行之前：
利用PEID,發(fā)現(xiàn)其沒有加殼
一般通過觀察其輸入表來判斷其行為,然而這里比較奇怪的是輸入表里面居然沒有Kernel32.dll,說明其太可疑了！?。『苡锌赡芡ㄟ^加密來隱藏了自己的行為
利用Strings查看一下其字符串列表：
全是亂碼,及有可能進行了加密或者混淆
火絨劍監(jiān)控:
文件監(jiān)控：
遍歷文件夾，加密文件并且在每個文件夾下創(chuàng)建勒索相關(guān)圖文信息
執(zhí)行監(jiān)控:
通過執(zhí)行監(jiān)控可以看到,創(chuàng)建了一個新的可執(zhí)行文件，并且調(diào)用cmd，打開notepad寫入文字信息，僅通過調(diào)用cmd就可以視為病毒行為，普通程序根本不需要調(diào)用cmd命令行工具
行為監(jiān)控：
自我刪除:
自我復(fù)制：
釋放隱藏文件
啟動自釋放文件
可以看出其有以下幾個行為：
- 自我復(fù)制
- 在User/Documetns下創(chuàng)建了一個文件并隱藏了
- 自我刪除
pcHunter監(jiān)控
重啟之后，使用pcHunter查看，發(fā)現(xiàn)
設(shè)置了勒索圖文為啟動項，更改了注冊表，本身已經(jīng)刪除了病毒本身的程序，無法打開任務(wù)管理器和注冊表編輯器
動態(tài)檢測:
加載至OD 里面:跟進到第一個call中發(fā)現(xiàn)有大量的混淆：
再仔細(xì)反思一下剛才的那些行為,會釋放一個PE文件,其很有可能調(diào)用了CreateProcess這個API, 可以在CreateProcess處下斷點試試看:
按F9運行:
CreateProcess創(chuàng)建了一個進程,進程名字在 commandLine所對應(yīng)的那個字符串,其實所創(chuàng)建的進程的名字一般是寫在第一個參數(shù)的,即ModuleFileName;當(dāng)然這里可以寫NULL,名字就可以寫在第二行的CommandLine里面了,一般而言,利用CreateProcess創(chuàng)建出來的線程是要運行的;而這里的參數(shù)為：CREATE_SUSPEND,故這里的線程創(chuàng)建出來之后隨即被掛起
以掛起的形式創(chuàng)建了一個進程,說明其之后還應(yīng)該會恢復(fù)進程,這里可能為ResumeThread,在ResumeThread出下斷點;同時我們可以推測,為何要以掛起的方式創(chuàng)建進程,很有可能要在創(chuàng)建出來的進程里面做一些操作,比如可以寫一些東西,這時候可能會用到VirtualAlloc以及VirtualAllocEx,WriteProcessMemory等函數(shù)
在這些地方下斷點;
果然在這個函數(shù)段下來了;
繼續(xù)運行,發(fā)現(xiàn)其在WriteProcessMemory這個API斷下來了：
為了更加清晰的分析其過程,再重新用OD加載一下(同時在上面幾個API下斷點)：
第一次Virtualloc
第二次VirtualAlloc;
第三次VirtualAlloc:
第四次VirtualAlloc
返回值:01270000;
Size:3AC00
CreateProcessW處斷下來了;
再一次在VirtualAllocEx處斷下來了：
WriteProcessMemory處停下來！
到這里,我們可以大概推測出這個病毒執(zhí)行的大概的流程了：
一開始的時侯連續(xù)調(diào)用了四個virtualalloc函數(shù),并且在第四次調(diào)用這個函數(shù)申請的空間里面存放惡意代碼,值得注意的是這個程序何時將惡意代碼放入VirtualAlloc申請的那個空間我們目前是不知道的,但是有一點可以確定的是在調(diào)用WriteProcessMemory的時候,之前申請的那個空間里面肯定已被填入了惡意代碼;繼續(xù)分析,在調(diào)用了4次VirtualAlloc之后,又調(diào)用了CreateProcessW函數(shù),接著調(diào)用VirtualAllocEx和WriteProcessMemory函數(shù);看來果然如我們之前推測的一般,先將惡意代碼拷貝至第四次VirtualAlloc申請的空間,然后利用WriteProcessMemory將剛才用VirtualAlloc申請到的空間里的存放的惡意代碼存放至用VirtualAllocEx申請出來另一個進程(此進程是通過CreateProcess創(chuàng)建出來的)的空間中;另一方面根據(jù)WriteProcessMemory這個API中的一個參數(shù),可以得知VirtualAlloc申請出來的空間中的惡意代碼是存放于緩沖區(qū)之中的,說明其數(shù)據(jù)是以文件的形式保存的,故這里為我們提供了方便,我們只要將dump下來即可
(注:經(jīng)過多次測試,發(fā)現(xiàn)在createrocess之前的那個virtualalloc申請的空間里面將放惡意代碼,故要得到那個virtualalloc的返回值(即申請空間的首地址))
IDA中一些小結(jié):
可以查看導(dǎo)入表(imports):
看里面的導(dǎo)入的函數(shù),通過查看里面的可疑函數(shù),可疑定位到相關(guān)地址(結(jié)合交叉引用)
在OD中如何拷貝二進制到010Editor里面:
再利用010Editor編輯器將隨機基址關(guān)掉(在可選頭里面,具體參見講義里面)(可以方便調(diào)試與測試)
獲取權(quán)限的相關(guān)操作:
進行提權(quán)的相關(guān)操作:
動態(tài)跟蹤,將進一步驗證:
(在IDA中查到相關(guān)特征api之后在OD里面進行下斷點)
讀取當(dāng)前進程權(quán)限:
獲取當(dāng)前進程的SID:
上圖中描述了dump出的文件中有復(fù)制文件與刪除文件的操作;
下圖中為進入自我是刪除的函數(shù):
利用ShellExecuteW函數(shù)在OD里面進行動態(tài)跟蹤;
驗證了之前的判斷,確實是在刪除自身！
設(shè)置注冊表鍵值:
獲取磁盤信息:
遍歷文件
加密文件:
跟進函數(shù)sub_411960,發(fā)現(xiàn)大量的加密操作:
管理員權(quán)限運行:
解密字符串:
利用WNetOpenEnum和WNetEnumResourceW對網(wǎng)絡(luò)資源進行枚舉,
HGLOBAL __stdcall sub_401610(LPNETRESOURCEW lpNetResource)
{
HGLOBAL result; // eax@2
void *v2; // ebx@3
DWORD v3; // edi@5
const wchar_t **v4; // esi@6
DWORD cCount; // [sp+0h] [bp-8h]@1
SIZE_T dwBytes; // [sp+4h] [bp-4h]@1
dwBytes = 0x4000;
cCount = -1;
if ( WNetOpenEnumW(2u, 0, 0, lpNetResource, (LPHANDLE)&lpNetResource) )
{
result = 0;
}
else
{
result = GlobalAlloc(0x40u, dwBytes);
v2 = result;
if ( result )
{
while ( 1 )
{
memset(v2, 0, dwBytes);
if ( WNetEnumResourceW(lpNetResource, &cCount, v2, &dwBytes) )
break;
v3 = 0;
if ( cCount )
{
v4 = (const wchar_t **)((char *)v2 + 20);
do
{
if ( dword_43A834 <= 64 && *(v4 - 5) == (const wchar_t *)2 && *(v4 - 4) == (const wchar_t *)1 )
{
wcscpy_s(&word_43AE58 + 1024 * dword_43A834, 0x400u, *v4);
++dword_43A834;
}
if ( (*((_BYTE *)v4 - 8) & 2) == 2 )
sub_401610((LPNETRESOURCEW)(v4 - 5));
++v3;
v4 += 8;
}
while ( v3 < cCount );
}
}
GlobalFree(v2);
result = (HGLOBAL)(WNetCloseEnum(lpNetResource) == 0);
}
}
return result;
}
同時發(fā)現(xiàn) HttpSendRequestA和InternetCrackUrlA等函數(shù),說明其進行了網(wǎng)絡(luò)連接
