'Reversing/Malware Analysis' 카테고리의 글 목록

개요기본적인 파일 정보는 아래와 같다. File Name : U******9 Diag Name : Linux/Xarceen.Gen Linux "file" 명령어를 통한 결과는 아래와 같다. 굵게 표시한 부분들을 통해 각각 32bit ELF 파일, 정적으로 컴파일, 스트립 되지 않은 파일임을 확인 할 수 있다. remnux@remnux:~/sample$ file U******9 UpTip999: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped 요약해당 악성코드는 공격자에 의해 감염 후, 원격지와 통신을 수행한다. 이 통신을 통해 공격하고자 하는 대상의 IP ..

2018.04.08

Reversing/Malware Analysis

[Malware] MadAngel 악성코드 분석

1. 개요악성코드는 여러 분류로 나누어 볼 수가 있다. 이 중 일반 사용자의 입장에서 ‘악성코드’ 라는 단어보다 친숙한 ‘바이러스’ 가 있다. 사실 필자도 보안을 공부하기 이전에는 ‘악성코드’ 라는 단어는 아예 들어보지 못했고, 대신 ‘바이러스’ 라는 단어로 모든 악성코드를 지칭했었다. 바이러스는 악성코드 분류의 한 종류로 ‘스스로를 복제하여 악의적 목적을 수행하는 악성 소프트웨어(Wiki)’ 라는 의미를 가지고 있다. 컴퓨터 바이러스가 아닌 우리가 알고 있는 메르스(MERS)나 감기와 유사하다. 바이러스에 감염된 사람으로부터 다른 사람도 감염시키듯이, 컴퓨터 바이러스는 감염된 파일을 실행시키면 다른 파일을 감염시킨다.컴퓨터 바이러스는 동작 방식에 따라 차이가 있겠지만, 일반적으로 악의적인 코드를 파일에..

2016.09.20

Reversing/Malware Analysis

공인인증서 탈취 악성코드

개요랜섬웨어나 게임 계정, 금융 정보 탈취 등으로 인한 피해를 끊이지 않고 있다. 이런 악성코드를 제작하는 공격자의 목적은 결국 금전을 획득하는 것이다. 우리는 많은 매체들을 통해 이런 사건에 대한 피해 소식을 접할 수 있다. 랜섬웨어의 경우 악성코드에 감염되면 파일이 암호화가 되어 공격자에게 금액을 지불해야 한다. 하지만 사용자 PC 에서 금융 정보를 탈취할 때, 공격자는 사용자의 보안 카드 번호 등을 알 수 없으므로 이에 대해 사용자가 입력하도록 한다. 따라서 이번 보고서에서는 금융 정보 탈취 악성코드에 감염된 경우 어떠한 증상이 있는지 알아보자. 동작악성 프로세스가 실행되었더라도 사용자가 Internet Explorer 자체를 실행시키지 않을 수가 있다. 때문에 공격자는 사용자 PC 에서 악성코드를..

2016.08.06

Reversing/Malware Analysis

[Malware] PETYA.exe 분석

2016.04.02

Reversing/Malware Analysis

[Malware] DarkSeoul 분석 (3.20 전산마비)

2016.03.23

Reversing/Malware Analysis

[Ransomware] .micro 랜섬웨어 분석 보고서

* 참고 : PDF를 기준으로 만든 내용이기 때문에, 포스팅보다는 PDF 파일을 보는 것이 더 좋습니다.1. 요약대상 악성코드에 대해 이후에 분석한 내용을 정리한 페이지다. 해당 악성코드는 랜섬웨어로 파일들을 암호화 하여 금액을 요구한다. 암호화 방식은 RSA 방식을 사용하며, 암호화 대상 파일은 크기가 32 Bytes에서 327,155,712 Bytes 사이에 있을 경우에 암호화 된다. 만약 파일의 크기가 이에 해당하지 않을 경우 진행되지 않는다. 그림 1. Malware Summary 최초 26.exe를 실행할 경우 %AppData%\Roaming에 새로운 이름으로 같은 파일을 생성 한 뒤 이를 실행한다. 이렇게 실행된 새로운 프로세스는 vssadmin 명령을 통해 볼륨 쉐도우를 제거하는 작업을 수행..

2016.02.22

Reversing/Malware Analysis

ixaobny.exe 분석 보고서

분석을 하는데 있어 처음으로 IDA를 중점으로 사용하게 된 계기가 되었다. 막힌 부분도 많았던지라 구체적으로 어떠한 기능을 하는지 확인하기는 힘들었지만, 그래도 일단 문서로 남겨놓자.

2016.02.16

Reversing/Malware Analysis

90u7f65d.exe Malware Analysis

개요 분석하고자 하는 파일에 대한 정보는 위의 표와 같다. 이제 이 파일을 가지고 정적 분석과, 동적 분석, 그리고 마지막으로 상세 분석을 진행할 것이다. 정적 분석에서는 해당 파일의 실행 없이 진행이 되며, 동적 분석은 해당 파일을 실행한 결과를 나타낸다. 상세 분석은 이 2가지를 종합하여 얻은 정보를 통해 좀 더 구체적으로 분석을 진행한다. 2. 정적 분석 정적 분석에서는 해당 악성코드의 실행 없이 분석을 진행한다. PE 구조에서 특이사항이나 문자열, 함수 등을 확인할 것이며 의심스러운 사항이 있을 경우 이에 대하여 나타낼 것이다. 이를 토대로 이후 동적 분석과 함께 상세 분석에서 토대가 된다. 2.1 PE구조 분석 PE구조에 있어 우선 Detect It Easy를 통해 패킹의 여부와 어떤 컴파일러를..

2015.12.28

Reversing/Malware Analysis

Prev 1 2 Next

Reversing/Malware Analysis

[Malware] MadAngel 악성코드 분석

Kail-KM

|2016. 9. 20. 23:28

MadAngel_분석보고서.pdf

1. 개요

악성코드는 여러 분류로 나누어 볼 수가 있다. 이 중 일반 사용자의 입장에서 ‘악성코드’ 라는 단어보다 친숙한 ‘바이러스’ 가 있다. 사실 필자도 보안을 공부하기 이전에는 ‘악성코드’ 라는 단어는 아예 들어보지 못했고, 대신 ‘바이러스’ 라는 단어로 모든 악성코드를 지칭했었다. 바이러스는 악성코드 분류의 한 종류로 ‘스스로를 복제하여 악의적 목적을 수행하는 악성 소프트웨어(Wiki)’ 라는 의미를 가지고 있다. 컴퓨터 바이러스가 아닌 우리가 알고 있는 메르스(MERS)나 감기와 유사하다. 바이러스에 감염된 사람으로부터 다른 사람도 감염시키듯이, 컴퓨터 바이러스는 감염된 파일을 실행시키면 다른 파일을 감염시킨다.

컴퓨터 바이러스는 동작 방식에 따라 차이가 있겠지만, 일반적으로 악의적인 코드를 파일에 삽입하여 공격자가 지정한 악의적인 행동을 수행한 다음에서야 원래의 정상적인 동작을 수행하도록 한다. 그렇기에 일반 사용자의 입장에선 모든 파일이 잘 실행되기 때문에 모를 수도 있다. 하지만 이미 바이러스가 실행된 사용자 PC 는 대부분 속도가 현저히 저하 되거나, CPU 사용량이 크게 증가하는 등으로 사용자의 PC 사용을 방해한다. 이번에 분석하고자 하는 컴퓨터 바이러스는 ‘Mad Angel’ 로 해당 악성코드의 동작 방식과 감염 방식 등에 대하여 알아보자.

2. 분석 정보

해당 악성코드에 대한 정보는 아래와 같다. 분석 중 필자가 가진 샘플이 감염된 파일인 것을 알 수가 있었다. 대신 드롭되는 Serverx.exe 가 감염된 파일에 삽입된 부분의 코드와 유사한 코드라는 점과, 감염된 파일이 다른 파일을 감염시키는 동작을 수행하는 중 해당 프로세스를 강제로 종료하면 Serverx.exe 가 실행되어 감염을 재개하는 점으로 미루어보아 실질적으로 숙주와 같다는 것을 알 수 있었다.

아래 그림과 같이 sample.exe 를 실행시켰을 때 두 개의 ‘sample.exe’ 프로세스가 존재하고 있는 것을 확인할 수 있다. 이 중 부모 프로세스(PID:2540)가 악성 동작(파일 감염)을 수행하는 것이며, 자식 프로세스(PID:2548)는 감염된 파일의 원래 동작을 수행하는 것이다. 감염된 파일인 sample.exe 를 실행할 경우 바이러스에 의해 삽입된 악성 동작을 수행하는 부분에서 루프를 돌게 된다. 그러므로 MadAngel 은 파일이 원래의 동작을 수행하는 자식 프로세스를 생성한다.

감염 행위를 하고 있는 sample.exe 프로세스를 강제로 종료 시키면 아래 그림과 같이 Severx.exe 가 생성되는 것을 확인할 수 있다. 하지만 여기서 의문을 가져야할 점은 바로 “ctfmon.exe” 프로세스의 자식 프로세스로 생성되었다는 점이다.

ctfmon.exe 는 해당 샘플을 실행하기 이전부터 존재하고 있던 정상적인 프로세스이다. 그렇다면 어떻게 ctfmon.exe 가 Serverx.exe 를 자식 프로세스로 가질 수 있을까? 이는 sample.exe 가 동작하면서 임의의 프로세스에 Code Injection 을 하기 때문이다. Injection 되는 코드는 감염 행위를 하고 있는 프로세스가 종료되면, Serverx.exe 를 다시 실행시킨다. 결국 Serverx.exe 프로세스를 종료 시켜도 다시 Serverx.exe 가 실행된다.

감염된 샘플과 Serverx.exe 는 Serverx.exe 를 자동실행 레지스트리에 등록하여 PC 를 재부팅하여도 다시 감염을 실행하도록 한다.

3. 상세 분석

MadAngel 을 실행할 경우 아래와 같이 뮤텍스를 통해 이미 MadAngel 이 동작 중인지 확인한다. 뮤텍스의 이름이 “Angry Angel v3.0” 인 것을 알 수 있으며, 동작 중이라면 감염 동작을 수행하지 않고 파일 원래의 기능이 동작하도록 한다.

만약 동작 중이지 않다면, 실행된 MadAngel 은 WinExec API 를 통해 정상 동작을 수행하는 자기 자신을 실행한다. 실행된 또 다른 자기자신은 위와 마찬가지로 뮤텍스를 확인하고, 뮤텍스가 이미 존재하기 때문에 정상 동작을 수행하는 루틴으로 가게 된다.

악성코드는 System32 폴더에 Serverx.exe 라는 파일을 드롭한다. Serverx.exe 는 MadAngel 의 핵심 코드가 들어있는 실행 파일로, 실질적으로 Serverx.exe 가 감염될 코드와 같다. 드롭 후 Serverx.exe 를 자동 실행 레지스트리에 등록하여 PC 가 종료되더라도 다시 부팅될 때 감염 동작을 수행하도록 한다.

아래와 같이 새로운 스레드를 생성한다. 생성된 스레드는 RegNotifyChangeKeyValue API 를 통해 위에서 등록한 레지스트리의 값이 삭제될때까지 기다린다. 만약 해당 값에 변화가 생기면 다시 레지스트리에 등록한다.

자신에게 스레드를 생성한 뒤 FindWindow 를 통해 임의의 윈도우를 탐색하고 해당 윈도우에 대한 프로세스 ID 를 가져온다. 그리고 OpenProcess API 를 통해 해당 프로세스의 핸들을 얻는다.

얻어온 프로세스 핸들에 대해 VirtualAllocEx 를 통해 메모리 공간을 할당해준다. 할당한 메모리 공간에 새로운 데이터를 기록을 해주는 것을 확인할 수 있다. 메모리에 데이터를 기록한 후 현재 프로세스의 ID 를 가져온다. 이는 현재 프로세스 ID 를 CreateRemoteThread 를 통해 생성할 스레드의 인자로, 넘겨받은 프로세스 ID 가 종료되는지 확인하기 위함이다. CreateRemoteThread 를 통해 데이터를 기록한 메모리 공간을 실행하는 스레드를 생성해준다.

위의 동작을 수행한 뒤 파일 감염을 시작한다. 우선 FindFirstFile 과 FindNextFile API 를 통해 각 폴더를 탐색한다. 그리고 폴더에 있는 파일의 이름에서 끝의 네 글자가 아래와 같이 “.exe” 나 “.scr” 인지 확인한다. 이 두 확장자가 아닐 경우 감염시키지 않는다.

감염에 사용된 코드를 디컴파일 하면 아래와 같은 결과를 얻을 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
FileInfection()
{
    data = f.read(0x1000);
    pDos = &data;
    pNt = pDos + pDos.lfanew;    //pDos + 0x3c
    pSec = pNt + 0xf8;
    NumberofSection = pNt+6;
 
    for(int i=0; i<NumberofSection; i++)
        pSec += 0x28;     // Find a Last Section
    if(pNt.AddressofEntrypoint > pSec.RVA)
    {
        tmp = pNt.AddressofEntrypoint - pSec.RVA + pSec.PointertoRawData;
        SetFilePointer(hFile, tmp, FILE_BEGIN);
        ReadFile(hFile, Buffer:data-4, size:4);
    }
    pSec.Characteristics = pSec.Characteristics | 0xe0000000;
    
    FileEndPoint = SetFilePointer(hFile, 0, FILE_END);
    if(FileEndPoint == -1){ return; }
    
    pSec.SizeofRawData = FileEndPoint + 0x118f - pSec.PointertoRawData;
    if(pSec.SizeofRawData > pSec.VirtualSize)
    {
        dwOrigVirtualSize = pSec.VirtualSize;
        pSec.VirtualSize = pSec.SizeofRawData;
 
        calc = (pNt.SectionAlignment - 1);
    /* 이 크기만큼 SizeofImage 에 더함 */    
        pNt.SizeofImage += ((pSec.VirtualSize + calc) & NOT(calc)) - ((dwOrigVirtualSize + calc) & NOT(calc));
    }
 
    Orig.AddressofEntrypoint = pNt.AddressofEntrypoint;
    pNt.AddressofEntrypoint = pSec.RVA + FileEndPoint - pSec.PointertoRawData;
 
    MalCode[0x1B] = Orig.AddressofEntrypoint + pNt.Imagebase;    /* Write a OEP */
    WriteFile(hFile, MalCode, size:0x118F);    /* Write a MalData to FileEndPoint */
    SetFilePointer(hFile, 0, FILE_BEGIN);
    WriteFIle(hFile, pDos, size:0x1000);    /* Write a new pe header */
}
Colored by Color Scripter
cs

위와 같은 방식으로 파일이 감염되면 아래와 같은 구조를 띄게 된다. 기존의 AddressofEntrypoint에 ImageBase를 더한 값(EP) 가 덧붙여지는 악성 코드의 0x1b 지점에 기록되어, 감염 되기 이전의 AddressofEntrypoint 를 알 수 있다.

다음 표는 임의의 샘플의 감염 전 후 PE 구조 차이다.

4. 진단 및 치료

해당 샘플의 경우 다형성을 띄고 있지 않다. 그렇기에 진단이나 치료에 있어 상대적으로 어렵지 않다. 아래 바이너리는 감염된 두 파일에 덧붙여진 코드를 나타낸다. 코드에 있어 다른 부분은 0x1B 부터 4 bytes 만 다른 것을 확인할 수 있으며, 여기에 있는 값은 감염되기 이전의 EP 값이다. 따라서 이를 토대로 진단 코드를 선정할 수 있다.

우선 위 바이너리를 확인하기 전에 파일의 특징적인 면이 있다. 바로 감염된 파일의 AddressofEntrypoint 가 덧붙여진 코드의 첫 지점(상:0x26200, 하:0x2B200)을 가리킨다는 것이다. 이와 함께 해당 지점에서 파일의 끝(EOF)까지의 크기가 0x118F 다. 따라서 EOF – 0x118F 와 AddressofEntrypoint 가 가리키는 Offset 이 동일한 위치가 된다. 이를 코드로 짜면 아래와 같다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
BOOL FirstDetection(HANDLE hFile)
{
    DWORD lpNumberOfBytesRead;
 
    DWORD NumberofSections;
    DWORD AddressofEntrypoint;
    
 
    DWORD CheckOffset = dwSize - 0x118f;
 
    lpAddr = VirtualAlloc(0, 0x1000, MEM_COMMIT, PAGE_READWRITE);
    ReadFile(hFile, lpAddr, 0x1000, &lpNumberOfBytesRead, 0);
 
    pDos = (PIMAGE_DOS_HEADER)lpAddr;
    pNt = (PIMAGE_NT_HEADERS)(pDos->e_lfanew + (BYTE *)pDos);
    pFile = (PIMAGE_FILE_HEADER)(0x4 + (BYTE *)pNt);
    pOption = (PIMAGE_OPTIONAL_HEADER)(0x18 + (BYTE *)pNt);
    pSection = (PIMAGE_SECTION_HEADER)(pFile->SizeOfOptionalHeader + (BYTE *)pOption);
 
    AddressofEntrypoint = pOption->AddressOfEntryPoint;
    NumberofSections = pFile->NumberOfSections;
 
    for (int i = 0; i < NumberofSections; i++)
    {
        if (AddressofEntrypoint > pSection->VirtualAddress && AddressofEntrypoint < (pSection->VirtualAddress + pSection->Misc.VirtualSize))
        {
            EPOffset = AddressofEntrypoint - pSection->VirtualAddress + pSection->PointerToRawData;
        }
        pSection++;
    }
    pSection--;
 
    if (CheckOffset == EPOffset)
    {
        return TRUE;
    }
    return FALSE;
}
Colored by Color Scripter
cs

위 코드를 통해 선진단을 하여 1차 분류를 한다. 조건에 부합한 파일에 다시 진단을 하여 핵심 코드 부분을 비교하여야 한다. 본 진단에서 사용할 바이너리는 두 부분으로 나누었다. 하나는 선진단에서 찾은 EP Offset 에서의 바이너리를 비교할 것이고, 다른 하나는 아래 그림에 나타낸 0x100 만큼의 크기이다. 해당 부분은 파일을 감염시키는 부분의 코드로 감염형 악성코드에서 중요한 부분이라 할 수 있다.

이러한 조건들을 다음과 같은 코드로 구성하여 비교할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
BOOL LastDetection(HANDLE hFile)
{
    DWORD lpNumberOfBytesRead;
 
    PVOID tmp;
    char ReadBuffer1[0x20];
    char ReadBuffer2[0x100];
    char CheckBuffer1[0x20] = { '\x60','\x78','\x03','\x79','\x01','\xEB','\xE8','\x74','\x11','\x00','\x00','\x8B','\x74','\x24','\x20','\xE8','\x11','\x00','\x00','\x00','\x61','\x78','\x03','\x79','\x01','\xEB','\x68'};
    char CheckBuffer2[0x100] = {'\xC8', '\x00', '\x00', '\x00', '\x60', '\x81', '\xEC', '\x00', '\x10', '\x00', '\x00', '\x8B', '\xFC', '\x68', '\x00', '\x10', '\x00', '\x00', '\x57', '\xFF', '\x75', '\x08', '\xFF', '\x56', '\x34', '\x0F', '\xB7', '\x47', '\x3C', '\x03', '\xF8', '\x3B', '\xFD', '\x0F', '\x87', '\xE4', '\x00', '\x00', '\x00', '\x66', '\x81', '\x3F', '\x50', '\x45', '\x0F', '\x85', '\xD9', '\x00', '\x00', '\x00', '\x81', '\xBF', '\x9B', '\x01', '\x00', '\x00', '\x79', '\x6C', '\x50', '\x7A', '\x0F', '\x84', '\xC9', '\x00', '\x00', '\x00', '\x8D', '\x9F', '\xF8', '\x00', '\x00', '\x00', '\x0F', '\xB7', '\x4F', '\x06', '\x49', '\x83', '\xC3', '\x28', '\xE2', '\xFB', '\x3B', '\xDD', '\x0F', '\x87', '\xB1', '\x00', '\x00', '\x00', '\x8B', '\x47', '\x28', '\x2B', '\x43', '\x0C', '\x72', '\x23', '\x03', '\x43', '\x14', '\x6A', '\x00', '\x50', '\xFF', '\x75', '\x08', '\xFF', '\x56', '\x3C', '\x50', '\x8B', '\xC4', '\x6A', '\x04', '\x50', '\xFF', '\x75', '\x08', '\xFF', '\x56', '\x34', '\x58', '\x66', '\x3D', '\x60', '\xE8', '\x0F', '\x84', '\x86', '\x00', '\x00', '\x00', '\x81', '\x4B', '\x24', '\x00', '\x00', '\x00', '\xE0', '\x6A', '\x02', '\x6A', '\x00', '\xFF', '\x75', '\x08', '\xFF', '\x56', '\x3C', '\x83', '\xF8', '\xFF', '\x74', '\x70', '\x50', '\x05', '\x8F', '\x11', '\x00', '\x00', '\x2B', '\x43', '\x14', '\x89', '\x43', '\x10', '\x8B', '\x53', '\x08', '\x3B', '\xC2', '\x72', '\x16', '\x89', '\x43', '\x08', '\x8B', '\x4F', '\x38', '\x49', '\x03', '\xC1', '\x03', '\xD1', '\xF7', '\xD1', '\x23', '\xC1', '\x23', '\xD1', '\x2B', '\xC2', '\x01', '\x47', '\x50', '\x59', '\x2B', '\x4B', '\x14', '\x03', '\x4B', '\x0C', '\x87', '\x4F', '\x28', '\x03', '\x4F', '\x34', '\xE8', '\x00', '\x00', '\x00', '\x00', '\x5F', '\x81', '\xEF', '\x13', '\x0E', '\x00', '\x00', '\x89', '\x0F', '\x83', '\xEF', '\x1B', '\x68', '\x8F', '\x11', '\x00', '\x00', '\x57', '\xFF', '\x75', '\x08', '\xFF', '\x56', '\x38', '\x83', '\xF8', '\xFF', '\x74', '\x18', '\x6A', '\x00', '\x6A', '\x00', '\xFF', '\x75', '\x08', '\xFF', '\x56', '\x3C', '\x8B', '\xC4', '\x68'};
    
    SetFilePointer(hFile, EPOffset, 0, 0);
    ReadFile(hFile, ReadBuffer1, 0x20, &lpNumberOfBytesRead, 0);
 
 
    OrigEP = (BYTE)ReadBuffer1[0x1b];
    OrigEP += (BYTE)ReadBuffer1[0x1c]*0x100;
    OrigEP += (BYTE)ReadBuffer1[0x1d]*0x10000;
    OrigEP += (BYTE)ReadBuffer1[0x1e]*0x1000000;
    OrigEP -= pOption->ImageBase;
 
    SetFilePointer(hFile, EPOffset + 0xd58, 0, 0);
    ReadFile(hFile, ReadBuffer2, 0x100, &lpNumberOfBytesRead, 0);
 
    for (int i = 0; i < 0x1b; i++)
    {
        if (ReadBuffer1[i] != CheckBuffer1[i])
        {        
            /* Check a aml data size at mal's data[0xdf6]&[e3c] */
            return FALSE;
        }
    }
 
    for(int i=0; i< 0x100; i++)
    {
        if(ReadBuffer2[i] != CheckBuffer2[i])
        {
            return FALSE;
        }
    }
 
    return TRUE;
}
Colored by Color Scripter
cs

이러한 진단 코드를 통해 감염된 파일들을 탐색하면 올바르게 진단하는 것을 확인할 수 있다.

위와 같이 진단을 한 다음 감염된 파일들을 치료하여야 한다. 우선 파일 뒷부분에 덧붙여진 0x118F 만큼을 잘라내는 것과 PE 헤더의 AddressofEntrypoint 를 올바르게 수정해주어야 한다. 그리고 파일을 실행에 직접적으로 관련이 있는 SizeofRawData 의 값도 수정해주어야 한다. 이는 다음과 같은 코드로 나타낼 수 있다.

5. 결론

제작한 코드로 치료한 결과는 아래의 표와 같다. 아래의 표는 국내 모 백신이 치료한 파일들의 MD5 값과 직접 제작한 코드로 치료한 파일의 MD5 를 비교한 것으로 해시 값이 동일한 것을 확인할 수 있다.

하지만 위 두 번째 표와 같이 감염형 악성코드를 ‘치료’ 했다는 것이 감염 이전과 완전히 동일하는 것을 뜻하지는 않는다. 물론 가능하다면 이전과 완전히 동일하게 하는 것이 가장 이상적이지만, 감염형 악성코드가 동작할 때 기존 파일의 정보를 모두 보존하지는 않는다. 그렇기에 복구할 수 없는 부분도 존재하게 된다. 또한 정책적인 면에서 위험의 소지가 있다면 최소한만큼만 수정하는 경우도 있다. 그러므로 치료되었음에도 감염 이전과 해시 값이 다르게 나타나는 경우도 빈번하다.

'Reversing > Malware Analysis' 카테고리의 다른 글

XorDDos Analysis Report (1)	2018.04.08
공인인증서 탈취 악성코드 (0)	2016.08.06
[Malware] PETYA.exe 분석 (2)	2016.04.02
[Malware] DarkSeoul 분석 (3.20 전산마비) (0)	2016.03.23
[Ransomware] .micro 랜섬웨어 분석 보고서 (1)	2016.02.22

Reversing/Malware Analysis

공인인증서 탈취 악성코드

Kail-KM

|2016. 8. 6. 00:36

개요

랜섬웨어나 게임 계정, 금융 정보 탈취 등으로 인한 피해를 끊이지 않고 있다. 이런 악성코드를 제작하는 공격자의 목적은 결국 금전을 획득하는 것이다. 우리는 많은 매체들을 통해 이런 사건에 대한 피해 소식을 접할 수 있다. 랜섬웨어의 경우 악성코드에 감염되면 파일이 암호화가 되어 공격자에게 금액을 지불해야 한다. 하지만 사용자 PC 에서 금융 정보를 탈취할 때, 공격자는 사용자의 보안 카드 번호 등을 알 수 없으므로 이에 대해 사용자가 입력하도록 한다. 따라서 이번 보고서에서는 금융 정보 탈취 악성코드에 감염된 경우 어떠한 증상이 있는지 알아보자.

동작

악성 프로세스가 실행되었더라도 사용자가 Internet Explorer 자체를 실행시키지 않을 수가 있다. 때문에 공격자는 사용자 PC 에서 악성코드를 지속시키기 위해 자동 실행 레지스트리에 등록한다.

[그림1] 자동 실행 등록

사용자의 PC 에 공인인증서가 존재하고 있는지 확인한다. 공인인증서를 찾은 경우 임시 폴더 하위에 이를 복제하는 것을 확인할 수가 있다. 그리고 복제한 공인인증서 파일을 압축하여 임의의 ZIP 파일로 저장해 놓는다.

[그림 2] 공인인증서 복사 및 압축

PAC (Proxy Auto Config)

실행된 악성코드는 Internet Explorer 의 시작 페이지를 국내 유명 포털 사이트로 바꾼다. 그리고 AutoConfigURL 에 값을 등록해준다. 이를 통해 자동 구성 스크립트가 사용되며, 사용자가 URL 입력 시 연결할 IP 정보를 알아 오기 위해 레지스트리 값에 등록된 주소에 질의한다.

[그림 3] 시작 페이지 변경 및 PAC 설정

등록된 주소는 "127.0.0.1:1171" 로 자신 PC 의 1171 번 포트에 질의하게 된다. 아래 그림을 보면 악성 프로세스인 b.exe 가 1171 번 포트에서 LISTENING 중인 것을 확인할 수 있다. 이를 통해 URL 에 따른 IP 정보를 b.exe 에서 받아오게 된다. 사용자는 일반 웹 사이트에 접속하더라도 b.exe 에게 질의하여 공격자가 원하는 사이트로 접속하게 된다.

[그림 4] 연결 대기

네트워크

악성코드는 공격자의 서버와 통신을 시도한다. 공격자의 서버는 QQ 사이트에 등록되어 있어, 네트워크 패킷을 보면 아래와 같이 QQ 사이트 공격자 ID(338366585)를 통해 공격자의 IP 를 받아온다.

[그림 5] QQ 에 사용자 주소 요청 (QQ : 103.7.30.86, 공격자 : 103.20.193.205)

공격자 서버의 주소를 정상적으로 받아 왔다면, 이전에 압축한 사용자 공인인증서를 탈취한다. 아래 패킷과 같이 ZIP 파일의 PK 헤더와 공인인증서 정보가 있는 것을 확인할 수 있다.

[그림 6] 공인인증서 전송

파밍 사이트

감염된 후 Internet Explorer 를 실행하면 아래와 같은 팝업 창이 나타나 다른 행동을 할 수 없게 된다. 은행 배너 중 하나를 클릭하면 공격자가 지정한 파밍 사이트로 이동하게 된다.

[그림 7] 인터넷 접속 시 팝업 창

IBK 기업은행 배너를 클릭한 결과 실제 IBK 기업은행과 같은 페이지로 이동한 것을 확인할 수 있다. 여기까지는 일반 은행 업무를 볼 때와 같은 상황이다. 하지만 은행 사이트에 접속하여 업무를 보기 위해 임의의 버튼을 클릭하면 아래와 같은 메시지 창이 나타난다. 메시지 창이 나타난 이후 가짜 본인인증 사이트로 이동된다.

[그림 8] 클릭 시 나타나는 팝업창

이동한 웹 사이트에는 한국 인터넷 진흥원 KISA 를 볼 수 있으며, 이용자 정보 입력을 유도한다. 하지만 이 페이지 역시 가짜 사이트로 이용자 정보 입력을 제외한 다른 버튼을 클릭할 경우 페이지 이동이 이루어지지 않는다. 이용자 정보 또한 임의의 정보를 기입하면 다음 페이지로 넘어가진다.

[그림 9] 개인정보 입력 유도

임의로 개인 정보를 입력하고 진행을 하면 URL 에 자신이 기입한 이름, 주민번호, 계좌번호 등이 URL 에 노출되는 것을 확인할 수 있다.

[그림 10] 입력한 임의의 개인정보

[그림 11] URL 에 노출되는 개인정보

마지막으로 이체 비밀번호와 보안카드 정보 입력을 유도한다. 정상적인 인증과 달리 보안 카드의 모든 번호를 입력하도록 한다.

[그림 12] 보안카드 정보 입력 유도

결론

사용자 PC 에 저장된 공인인증서를 탈취 후 PAC 를 통해 파밍 사이트로 연결하는 악성코드에 대하여 알아보았다. PC 에 인증서를 저장해놓은 경우 금융 정보 탈취 악성코드가 접근하기 쉬워진다. 따라서 인증서를 USB 와 같은 이동식 매체에 저장하여 필요할 때만 연결하여 사용하는 것이 하나의 예방법이 될 수 있다. 또한 파밍 사이트로 연결되는 방법은 위에서 언급한 PAC 외에도 존재하므로 사용자가 속을 수 있다. 그러므로 위와 같이 과도한 개인 및 금융 정보를 요구한다면 의심을 해보아야 한다. 의심되는 증상이 있을 경우 정보 기입을 멈추고 백신을 통해 PC 감염 여부를 확인하여야 한다.

'Reversing > Malware Analysis' 카테고리의 다른 글

XorDDos Analysis Report (1)	2018.04.08
[Malware] MadAngel 악성코드 분석 (0)	2016.09.20
[Malware] PETYA.exe 분석 (2)	2016.04.02
[Malware] DarkSeoul 분석 (3.20 전산마비) (0)	2016.03.23
[Ransomware] .micro 랜섬웨어 분석 보고서 (1)	2016.02.22

Reversing/Malware Analysis

[Malware] PETYA.exe 분석

Kail-KM

|2016. 4. 2. 21:16

PETYA 분석.pdf

'Reversing > Malware Analysis' 카테고리의 다른 글

[Malware] MadAngel 악성코드 분석 (0)	2016.09.20
공인인증서 탈취 악성코드 (0)	2016.08.06
[Malware] DarkSeoul 분석 (3.20 전산마비) (0)	2016.03.23
[Ransomware] .micro 랜섬웨어 분석 보고서 (1)	2016.02.22
ixaobny.exe 분석 보고서 (0)	2016.02.16

Reversing/Malware Analysis

[Malware] DarkSeoul 분석 (3.20 전산마비)

Kail-KM

|2016. 3. 23. 00:39

[Malware]DarkSeoul분석.pdf

'Reversing > Malware Analysis' 카테고리의 다른 글

공인인증서 탈취 악성코드 (0)	2016.08.06
[Malware] PETYA.exe 분석 (2)	2016.04.02
[Ransomware] .micro 랜섬웨어 분석 보고서 (1)	2016.02.22
ixaobny.exe 분석 보고서 (0)	2016.02.16
90u7f65d.exe Malware Analysis (0)	2015.12.28

Reversing/Malware Analysis

[Ransomware] .micro 랜섬웨어 분석 보고서

Kail-KM

|2016. 2. 22. 22:16

Ransomware_Micro.pdf

* 참고 : PDF를 기준으로 만든 내용이기 때문에, 포스팅보다는 PDF 파일을 보는 것이 더 좋습니다.

1. 요약

대상 악성코드에 대해 이후에 분석한 내용을 정리한 페이지다. 해당 악성코드는 랜섬웨어로 파일들을 암호화 하여 금액을 요구한다. 암호화 방식은 RSA 방식을 사용하며, 암호화 대상 파일은 크기가 32 Bytes에서 327,155,712 Bytes 사이에 있을 경우에 암호화 된다. 만약 파일의 크기가 이에 해당하지 않을 경우 진행되지 않는다.

그림 1. Malware Summary

최초 26.exe를 실행할 경우 %AppData%\Roaming에 새로운 이름으로 같은 파일을 생성 한 뒤 이를 실행한다. 이렇게 실행된 새로운 프로세스는 vssadmin 명령을 통해 볼륨 쉐도우를 제거하는 작업을 수행하는 스레드를 생성한다. 또한 CMD나 작업관리자, 또는 Process Explorer와 같은 프로세스의 실행 및 동작을 방해하도록 이들을 계속 종료한다.

암호화가 진행되는 동안 해당 프로세스는 자기 자신을 레지스트리에 지속성을 위하여 등록한다. 하지만 여기서 말하는 지속성이란, 암호화가 완료되지 않은 채로 PC가 종료되었을 경우 다시 PC가 부팅되었을 때 암호화를 마저 진행하도록 하기 위함이다. 랜섬웨어는 모든 암호화가 완료되었을 경우, 자기 자신을 삭제한 뒤 프로세스 또한 종료한다.

2. 개요

분석하고자 하는 대상 악성코드는 랜섬웨어(Ransomware)로 파일을 암호화하여 이에 대하여 금전적인 요구를 강요하는 것이다. 일반적으로 랜섬웨어의 경우 복잡한 암호화 알고리즘을 사용하는 것이 대부분이기 때문에, 실질적으로 복구는 힘들다. 따라서 암호화 키를 찾는 것이 아닌, 어떻게 랜섬웨어가 동작하는지 확인하기 위하여 분석을 진행할 것이다.

악성코드를 분석하는데 있어 크게 2 단계로 나누어 살펴볼 것이다. 동적 분석과 정적 분석으로, 동적 분석은 악성코드를 직접 실행시키므로 나타난 결과들에 대하여 살펴볼 것이다. 반대로 정적 분석의 경우 악성코드를 디버거를 통해 실행했을 때의 결과에 대하여 살펴볼 것이다. 필요하다면 메모리 분석 기법까지 사용할 것이다. 각 분석에 사용된 도구들은 다음의 표와 같다.

표 1. 사용 도구

위의 도구들을 이용하여 전체적인 분석을 진행하였다. 동적 분석을 먼저 진행하여 어떠한 동작들이 이루어지는지 확인한 뒤, 정적 분석을 통해 이에 대하여 좀 더 구체적으로 알아볼 것이다.

3. 동적 분석

동적 분석은 악성코드를 실행하므로 나타나는 증상에 대하여 정리한 페이지다. 이러한 동적 분석을 통해, 나타나는 결과들을 명확하게 확인할 수 있다는 장점이 있다. 다만, 실행할 때 가상 환경에서 진행하여야 한다는 점과 놓치는 측면이 있을 수 있다는 단점이 존재한다. 분석 환경은 Windows 7 x64이며 구분을 위하여 최초 실행하는 악성코드의 이름은 26.exe로 변경 후 분석을 진행하였다.

3.1 Process 분석

해당 악성코드를 실행하면 새로운 프로세스를 생성한다. 여기서 해당 프로세스의 이름은 무작위로 정해진다. 분석을 하면서 생성된 프로세스의 이름이 ltwpiwd.exe였다. 해당 파일의 위치를 찾아 해시 값을 비교해본 결과, 최초 26.exe와 같은 해시 값을 가지고 있었다. 따라서 26.exe는 자신을 감추기 위해, 본래의 26.exe를 제거하고 새로운 파일을 %AppData%\Roaming\에 생성한 뒤 이를 실행한다.

그림 2. Process Hacker

암호화 동작을 진행하며 볼륨 섀도우 카피와 관련된 프로그램들이 실행되는 것을 확인할 수가 있다. 이는 VSS를 통해 데이터 복구하는 것을 방지하기 위하여 존재하고 있는 VSS를 제거하는 동작(vssadmin delete shadows /all / Quiet)을 한다. 또한 암호화가 진행되는 동안 HELP_RECOVER_instructions+pgv(이하 Help파일) 라는 암호화를 풀기 위한 방법을 나타내는 파일이 Txt, Html, Png의 형태로 각 폴더에 생성된다.

여기서 해당 프로세스가 진행되는 동안 cmd.exe, ProcessExp 등을 비롯한 몇 가지 프로그램이 계속 종료되는 현상이 나타났다. 이는 랜섬웨어 파일이 분석 또는 감염자가 다른 행동을 하지 못하도록 하기 위함으로 보인다. 암호화가 완료된 후, HELP파일들이 ltpiwd.exe의 하위 프로세스로 txt, html, png로생성된다. 그 후 해당 프로세스는 종료한다. Help 파일 중 html은 아래의 그림을 보자.

그림 3. HELP_RECOVER_instructions+pgv.html

해당 내용을 확인해보면, 전형적인 랜섬웨어가 가지는 특성을 보인다. RSA 암호화 방식을 사용하고 있으므로 해제가 어려울 것이다라는 것을 경고하며, 퍼스널 홈 페이지를 제공한다. 각 페이지에 접속을 시도해본 결과 현재 접근할 수 없는 페이지로 나타난다.

3.2 MFT 분석

MFT에는 파일에 대한 메타정보들이 저장되어 있다. 여기서 $UsnJrnl에는 저널 로그가 기록되어있으며 $LogFile에 비하여 상대적으로 기록할 수 있는 로그의 크기가 크다. 따라서 $LogFile을 통해 트랜젝션 로그를 살펴볼 수 있으며, $UsnJrnl을 통해서는 많은 양의 저널 로그를 살펴볼 수 있다.

일반적으로 랜섬웨어의 경우 많은 이벤트들이 발생하기 때문에, $LogFile의 경우 많은 부분이 덮어씌워진다. 따라서 해당 랜섬웨어가 초반에 남기는 정보들이 지워지게 된다. 이 경우 $UsnJrml을 확인할 경우 상대적으로 $LogFIle에 비하여 기록이 남아 있는 확률이 높다. 그러므로 각 용도에 맞게 이를 참고하면 된다.

표 2. NTFS Log Tracker

위 표는 랜섬웨어가 종료된 후의 MFT이다. 우선 실행을 한 후 최초 실행된 26.exe와 같은 파일을 'Roaming'에 생성한다. 그 다음, recover_file_hbmmvstaw.txt라는 파일이 생성되었다는 것을 알 수 있다. 해당 파일은 4줄의 문자열이 구성되어 있다. 해당 파일이 어떠한 용도인지는 알 수가 없다. 내용은 아래와 같다.

표 3. Recover_file_hbmmvstaw.txt

3.3 Prefetch 분석

프로세스가 실행되면 Prefetch 파일을 생성하게 된다. 이러한 프리패치 파일의 경우 어떠한 파일이 같이 로드되었는지 확인할 수가 있기 때문에, 좋은 단서들이 될 수 있다. 해당 파일의 경로와 관련된 다른 파일들에 대한 정보까지 확인할 수가 있다. 아래의 표를 확인하자.

표 4. WinPrefetchView

표에서 볼 수 있듯이, 최초에 실행된 26.exe는 itpiwd.exe를 로드한 항목으로 가지고 있다. 이는 26.exe가 하위 프로세스로 생성한다는 점에서 알 수가 있다. 그리고 3.1에서 확인했듯이, 해당 랜섬웨어는 여러 번 VSSVS나 VSSADMIN과 관련하여 실행여부를 확인한다. 만약 이에 대해 "Yes"를 누르지 않을 경우, VSS가 삭제되지 않는다. 따라서 해당 여부를 묻는다면 "No"를 약 2초 간격마다 프로세스가 종료될 때까지 반복해서 눌러주거나 무시하여야 한다.

3.4 Registry 분석

해당 랜섬웨어를 실행한 뒤, 레지스트리에도 변화가 있다. 이를 확인하기 위하여 REGA를 사용하였다. 변화된 레지스트리 키 중 아래의 키를 보자. 해당 경로는 악성코드가 지속성을 유지하기 위하여 생성되는 부분이다.

표 5. REGA

여기서 해당 레지스트리에 등록되는 새로운 26.exe(ltpiwd.exe)는 3.2의 표에서 나타낸 바와 같이, 프로세스의 기능을 다하면 자기 자신을 삭제한다. 이럴 경우 해당 키는 아무런 쓸모가 없다고 보일 수 있다. 하지만 해당 키에 등록되는 것은, 암호화가 진행되는 동안 사용자가 강제적으로 프로세스를 종료하거나, 컴퓨터를 종료하였을 경우를 대비한 행동이라 볼 수 이다. 다시 말해 프로세스가 진행 중에 종료가 되면 랜섬웨어는 암호화가 된 결과물이 적게 산출되기 때문에, 이를 방지하기 위함이라 볼 수가 있다.

3.5 Network 분석

암호화가 진행되는 동안 "212.85.98.241"와 네트워크 연결이 진행되는 것을 확인할 수 있다. 해당 패킷은 WireShark를 통해 캡처하여 확인할 수 있다. "212.85.98.241"와 네트워크 연결이 진행되기 때문에 Whois를 통해 해당 IP를 조회할 수가 있다. 조회한 결과는 아래의 표와 같다.

표 6. Whois

여기서 해당 도메인 주소를 알 수가 있다. Southinstrument.org라는 사이트로 해당 사이트에 접속하려는 결과 백신으로부터 해당 사이트가 차단된다. 따라서 VM을 통해 접속해본 결과, 일반적인 장비 판매 업체의 사이트로 확인된다.

4. 정적 분석

정적 분석에서는 동적 분석을 통해 얻은 행위들에 대하여 좀 더 세부적으로 살펴볼 것이다. 분석을 진행하는데 있어 안티 디버깅 기법에 의하여 디버거로 분석을 계속 진행할 수 없었다. 따라서 실행되고 있는 해당 프로세스를 메모리에서 추출하여 이를 분석할 것이다.

프로세스가 패킹이나 암호화 되어있을 때, 이를 디버거로 분석하기에는 난해하다. 하지만 이러한 프로세스들도 메모리에 올라오게 되면, CPU가 알아볼 수 있는 명령어로 전달되어야 하기 때문에 결국 암호화나 패킹을 해제한 상태로 메모리에 올라오게 된다. 이러한 측면을 활용하고자 메모리에서 추출한 것이다.

추출한 프로세스를 IDA를 통해 분석을 진행하였다. 해당 프로세스에서는 0041F3E0에 주요 함수들이 있는 것으로 확인된다. 해당 부분의 앞부분에 SHGetFolderPath API를 통해 여러 폴더의 경로를 구해오는 것을 확인할 수가 있다.

이렇게 진행된 후 CopyFile API와 CreateProcess API가 오는 것을 확인할 수 있다. 3.1에서 동작을 확인했던 바에 비추어 26.exe가 새로운 파일 이름을 갖는 ECX에 맞게 생성되는 것으로 보인다. 그 후 이를 실행하여 프로세스로 생성하는 것임을 알 수 있다.

그림 4. IDA – CreateProcess & CopyFile

3.1에 따르면 새로운 프로세스 ltwpiwd.exe이 생성된 것으로 확인할 수 있다. 이러한 프로세스는 암호화를 진행한다. 여기서 암호화가 진행되는 동안 vssadmin.exe가 실행되는 것을 확인할 수 있었다. 또한 해당 명령어가 "vssadmin.exe delete shadows /all /Quiet"로 기존의 VSC를 삭제하는 명령어였다. IDA를 통해 확인할 결과 해당 명령어는 스레드를 통해 진행된다. 다음 그림에서 CreateThread API가 사용되는 것을 확인할 수 있다. 여기서 해당 스레드의 내용은 StartAddress의 내용을 실행하는 것으로 해당 부분에 인자로 사용되는 명령어는 위에서 언급했던 vssadmin 명령어이다. 이렇게 vssadmin이 스레드를 통해 진행되는 것이다.

그림 5. IDA - CreateThread

VSS와 관련된 스레드가 생성된 후, 가장 핵심적인 스레드가 생성된다. 해당 스레드에 사용된 API들은 우측의 주석에 적어놓았다. 위에서와 마찬가지로 Start Address에 스레드가 수행할 명령어와 함수가 존재하고 있다. 주석을 보자. Wnet-으로 네트워크와 관련된 API들이 있으며, 그 외에 파일을 찾는 API들이 보이며, 찾은 파일들을 수정하는 함수들도 존재하고 있다.

그림 6. IDA – CreateThread

해당 Start Address를 좀 더 자세히 확인하면, 우선 FindFirstFile API를 통해 암호화 하고자 하는 첫 대상 파일을 찾는다. 대상이 된 파일은 CreateFile의 OPEN_EXISTING 인자를 통해 해당 파일 연다. 그리고 만약 파일의 사이즈가 32 Bytes보다 작거나, 327,155,712 Bytes 보다 클 경우 암호화가 진행되지 않고 다음 파일로 넘어가게 된다. 반대로, 사이즈가 이에 부합할 경우 해당 파일을 ReadFile을 통해 파일의 내용을 읽는다.

이렇게 읽은 후 해당 파일의 앞 부분에 0x170만큼 데이터가 기록된다. 여기서 0x16C까지의 내용은 모두 공통적인 바이트를 갖고 뒤 바이트부터는 서로 상이하다. 파일에 대한 기록이 완료되면 FindNextFile API를 통해 다음 파일에 대한 활동을 시작한다. 이렇게 스레드가 생성이 되고 스레드가 대상 모든 파일에 암호화가 진행되면, 스레드가 종료되며 해당 프로세스도 종료된다.

'Reversing > Malware Analysis' 카테고리의 다른 글

[Malware] PETYA.exe 분석 (2)	2016.04.02
[Malware] DarkSeoul 분석 (3.20 전산마비) (0)	2016.03.23
ixaobny.exe 분석 보고서 (0)	2016.02.16
90u7f65d.exe Malware Analysis (0)	2015.12.28
WireShark를 통한 Nethost.exe악성코드 네트워크 분석 (0)	2015.11.30

Reversing/Malware Analysis

ixaobny.exe 분석 보고서

Kail-KM

|2016. 2. 16. 21:36

Malware_ixaobny분석.pdf

'Reversing > Malware Analysis' 카테고리의 다른 글

[Malware] DarkSeoul 분석 (3.20 전산마비) (0)	2016.03.23
[Ransomware] .micro 랜섬웨어 분석 보고서 (1)	2016.02.22
90u7f65d.exe Malware Analysis (0)	2015.12.28
WireShark를 통한 Nethost.exe악성코드 네트워크 분석 (0)	2015.11.30
Nethost.exe분석 (1)	2015.11.26

Reversing/Malware Analysis

90u7f65d.exe Malware Analysis

Kail-KM

|2015. 12. 28. 02:38

개요

분석하고자 하는 파일에 대한 정보는 위의 표와 같다. 이제 이 파일을 가지고 정적 분석과, 동적 분석, 그리고 마지막으로 상세 분석을 진행할 것이다. 정적 분석에서는 해당 파일의 실행 없이 진행이 되며, 동적 분석은 해당 파일을 실행한 결과를 나타낸다. 상세 분석은 이 2가지를 종합하여 얻은 정보를 통해 좀 더 구체적으로 분석을 진행한다.

2. 정적 분석

정적 분석에서는 해당 악성코드의 실행 없이 분석을 진행한다. PE 구조에서 특이사항이나 문자열, 함수 등을 확인할 것이며 의심스러운 사항이 있을 경우 이에 대하여 나타낼 것이다. 이를 토대로 이후 동적 분석과 함께 상세 분석에서 토대가 된다.

2.1 PE구조 분석

PE구조에 있어 우선 Detect It Easy를 통해 패킹의 여부와 어떤 컴파일러를 사용했는지를 확인해볼 것이다. 어떤 언어로 제작이 되었는지에 따라 해당 소스를 복구할 수도 있기 때문에 이는 반드시 확인을 해주어야 한다.

그림 1. Detect It Easy

C/C++로 작성된 것을 확인할 수가 있으며, 별 다른 패킹이 되었는지는 나타나지 않는다. 이제 PE View를 통해 좀 더 PE구조에 대하여 자세히 살펴보자. 아래의 그림을 확인해보자.

그림 2. PE view

특이한 사항을 바로 확인할 수가 있을 것이다. 우선 Gangnam, freebody, wtf 섹션은 일반적인 파일에는 존재하지 않는 다는 점이다. 각 섹션의 내용을 확인해본 결과 문자열들이 존재하였으며 해당 문자열은 다음과 같다.

일반적으로 장난과 같은 느낌이 든다. 이 세 섹션은 별 중요한 내용이 없는 것 같고 이 외에 한 가지를 제외하고 다른 특이사항은 없는 것 같다. 리소스 섹션에는 .png 파일의 signature인 {89 50 4E 47 0D 0A 1A 0A}가 존재하고 있다. 아래의 그림을 보자.

그림 3. PE view – Resource Section

그림 파일이 안에 있다는 것임으로 이를 추출해보고자 했다. 7zip을 통해 파일에서 png signature를 갖는 부분을 찾았으며 해당 파일의 이름은 87로 되어있다. 확장자를 png로 변환하고 열어서 확인해본 결과는 아래와 같다.

그림 4. Error – PNG File

해당 파일이 손상되어 확인을 할 수 없다는 화면이 출력되는 것을 확인할 수가 있다. 그렇다면 이제 다른 부분을 분석하여 보자.

2.2 Import Address Table 분석

문자열에서는 별다른 내용이 확인되지 않았으니 함수를 확인하였다. Import 하는 DLL은 6개이며 각 DLL에서 의심스러운 행위와 관련된 몇 가지 함수들을 선별하여 표에 정리하였다. 아래의 표를 보자.

특정 디렉터리를 생성한다는 점과 파일과 관련하여 찾기, 생성, 삭제, 이동, 읽기, 쓰기 기능이 있다는 점에서 어떤 파일과 관련되는지 이름을 찾는 것이 중요하겠다. 프로세스와 스레드도 어떤 기능의 프로세스와 스레드가 생성되는지를 상세분석에서 확인해보자.

3. 동적 분석

동적 분석에서는 위 정적 분석에서 확인하였던 내용을 중점적으로 어떠한 기능을 하는지 확인할 것이다. 그 외에도 정적 분석에서 확인하지 못하였던 부분이 있다면 추가로 인지를 하고 종합하여 상세분석을 진행하는데 참고할 것이다.

3.1 프로세스 분석

해당 프로그램 90u7f65d.exe를 실행할 경우 90u7f65d가 프로세스로 생성된다. 하위 프로세스는 생성되지 않는 것으로 보인다.

그림 5. Process Explorer

3.2 네트워크 분석

우선 다른 곳과 연결이 되는지를 확인해보자. 여기에는 TCP View를 사용하였으며 결과는 아래의 그림과 같다.

그림 6. TCP View

해당 프로세스가 연결을 SYN 패킷을 보내는 것을 확인할 수 있지만 정확한 원격 주소가 출력되지 않고 있다. 따라서 다른 방법을 통해 해당 주소를 확인할 수 있는지 알아보자.

그림 7. Rekall – Netscan

프로세스가 실행 중인 메모리를 덤프 떠서 메모리 분석 도구인 Rekall을 통해 어떠한 곳과 연결을 하려는 지 확인해 보았다. 결과는 위의 그림과 같으며 90u7f65d.exe 외에 System(pid=4)도 해당 주소와 연결을 하려고 했던 것을 확인할 수가 있다.

그림 8. WireShark – packet

WireShark를 통해 캡처한 많은 패킷 중 해당 주소를 필터로 나타낸 결과이다. 위의 그림과 같이 3번의 연결을 시도하려는 작업을 하지만 닫힌 포트이므로 연결이 제대로 이루어지지 않는 것을 확인할 수가 있다. 그 다음, 해당 IP에 대한 정보를 찾아보았다.

그림 9. 해당 IP 정보

위의 정보는 Whois를 통해 찾아본 결과이다. 프랑스 국적으로 등록이 되어 있으며 해당 사이트의 주소가 나와있는 것을 볼 수가 있다. 해당 웹사이트에 접속하여 화인해보자.

그림 10. 해당 웹 사이트

해당 사이트에 접속해보니 서버를 빌려주는 등의 서비스를 하는 업체인 것 같다. 이 외에 별다른 정보를 알아내지는 못했다. 그러므로 임대 받은 서버 등을 통해 악성코드와 관련되는 것이라 볼 수 있다.

3.3 레지스트리 분석

악성코드가 지속성을 유지하기 위해 레지스트리에 등록을 했을 경우도 있다. 그러므로 레지스트리에 어떠한 변화가 생겼는지 REGA와 Regshot을 통해 확인해보았다. 아래의 그림과 같은 변화가 나타났다.

그림 11. REGA

Internet Settings와 관련하여 동작이 이루어지는 것을 확인할 수가 있다. 이 외에도 Tcpip, Tracing 등 레지스트리를 조작하는 것을 확인할 수 있었지만 지속성과 관련된 레지스트리 항목은 보이지 않았다.

3.4 MFT 분석

MFT 분석을 위하여 WinHex를 통하여 $MFT, $LogFile, $UsnJrnl:$J를 수집하였다. 이렇게 수집된 정보를 통해 분석은 NTFS Log Tracker를 통해 진행하였으며, 실행 후 변화가 일어난 .pf 파일을 제외한 사항은 다음과 같다.

그림 12. NTFS Log Tracker – Excel

위의 그림과 같이 IE와 관련이 있는 Content.IE5, Cookies, History 디렉터리의 각 index.dat 파일과 어떠한 행위를 하는 것을 알 수가 있다. 대부분 이를 통해 개인정보를 가져온다는 점을 고려했을 때, 이 또한 이러한 가능성을 배제할 수 없다.

4. 상세 분석

이번 장에선 위 정적 분석과 동적 분석을 통해 얻은 정보들을 바탕으로 더 자세히 알아보는 과정을 포함하고 있다. 주로 OllyDBG와 Rekall을 통해 분석이 진행되며 그 외에 IDA pro와 Volatility를 같이 사용하고 있다.

4.1 메모리 분석

메모리를 통해 우선 해당 프로세스가 가지는 핸들을 확인해보았다. 어떠한 파일을 핸들로 갖는지 먼저 확인해보았다. 아래의 그림과 같이 이전에 MFT를 통해 확인한 index.dat과 관련하여, 악성코드로 인한 것임을 확인할 수 있다.

그림 13. Volatility – handles

Malfind Plugin을 통해 인젝션이 일어났는지 확인해보았다. 그 결과 아래와 같이 나타난 것을 확인할 수가 있다. 실행, 읽기, 쓰기 권한이 있는 페이지에 MZ 헤더가 있는 것을 확인할 수가 있다.

그림 14. Rekall – Malfind

이를 추출하기 위해 dlldump Plugin을 사용하였으며 해당 주소를 베이스로 주어 추출하였으며 성공적으로 추출이 되었다.

그림 15. Volatility - dlldump

추출한 dll에서 특이한 문자열과 API는 찾을 수가 없었기에 간단하게 Virustotal을 통해 확인해보았다. 결과는 아래의 그림과 같으며 53개의 엔진 중 4곳에서 악의적인 기능이라 의심을 받는 결과가 나왔다.

그림 16. Virustotal

4.2 디버깅 분석

GetProcAddress API는 지정된 모듈에서 함수의 주소를 구할 때 사용되는 API이다. 여기선 EncodePointer와 DecodePointer 함수의 주소를 구하는 것을 아래의 그림과 같이 확인할 수 있다.

그림 17. GetProcAddress

Thread를 생성할 때 사용하는 CreateThread를 호출하는 것을 볼 수가 있다. 여기서 스레드를 CREATE_SUSPENDED로 CreateionFlags를 주므로 생성된 스레드는 바로 대기 상태가 되며 ResumeThread API를 호출해야 본 기능을 진행하게 된다.

그림 18. CreateThread

생성된 스레드는 바로 대기상태에 진입을 하였기 때문에 ResumeThread를 호출해야 하며 이를 밑의 그림과 같이 바로 호출하는 것을 확인할 수가 있다. 만약 비교문에서 값이 같을 경우엔 스레드를 재개시키지 않는다는 것 또한 같이 확인할 수가 있다.

그림 19. ResumeThread

CreateFile API는 파일을 생성하는 것뿐만이 아니라 해당 이름의 파일이 존재하고 있는 지의 여부를 확인하는데도 사용된다. 여기선 OPEN_EXISTING 이므로 해당 파일이 존재하는지를 확인하는 것으로 반환 값이 'FFFFFFFF'이므로 존재하지 않음을 알 수 있다.

그림 20. CreateFile

Sleep 함수를 호출한 뒤 아래의 부분과 같이 값을 이동하는 과정을 볼 수가 있다. 마치 유니코드와 같이 1바이트는 NULL이 위치하고 있으며 많은 부분이 바뀌며 아래의 그림을 보자.

그림 21. Decoding

변환된 부분 중에서 아래의 그림과 같이 "vcltest3.dll" 과 "RegisterAutomation"이라는 문자열을 확인할 수가 있다. 그 외에 다른 부분은 특정한 문자열을 확인할 수는 없었다.

그림 22. Decoding – String

하지만 분석을 하는 도중 에러가 발생하였다. 디코딩을 진행한 부분의 주소를 ESI에 넣고 이를 CALL 명령어를 통해 호출하는 과정이다. 하지만 해당 호출 부분으로 이동한 후 디버거로 더 이상 분석이 불가능하게 된다.

그림 23. Error

혹시나 해서 IDA Pro로 열어본 결과 아래와 같은 결과를 확인할 수가 있었다. 따라서 어떻게 해야 할지 모르므로 더 이상 분석은 어려울 것 같다.

그림 24. Error

5. 결론

전체적으로 분석하는 내용을 실패하였다. 분석한 범위에서 내릴 수 있는 결론은 하나뿐이다. 인터넷 브라우저를 통해 개인정보 유출의 가능성이 있다는 것이다. 이제 Cuckoo Sand Box를 통한 결과를 확인해보자.

인터넷 브라우저에서 개인 정보를 가로채는 기능을 함
시스템의 정보를 수집하는 기능
자동 실행을 위해 \Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon 등록
C:\에 autoexec.bat이 Drop 됨

위와 같이 정리할 수 있다. 하지만 여기서 의문이 남는다. 본인의 VM에서 일반적으로 실행(디버거 없이)한 경우에도 autoexec.bat은 생성되지 않았다. 또한 지속성을 위한 해당 레지스트리 값이 변화하지 않았다. 다음과 같이 생각해볼 수가 있다.

해당 서버와의 연결이 이루어진 뒤에 주요한 기능들이 실행되는데 현재 서버가 닫힌 상태이므로 본 기능을 진행하지 않는다.
가상 머신에서 실행을 했기 때문에 이를 인지하고 본래의 기능을 진행하지 않는다.

본인의 실력이 부족한 것도 사실이지만, Cuckoo를 통한 결과에 따르면 생성되었어야 할 파일이 생성되지 않는다는 점부터 결국 찜찜하게 분석을 마무리 짓는다.

# Cuckoo 분석 결과

/malwr.com/analysis/YzRjOTg0ZThmYWYzNDgxYWIyM2QwNGRkNWMxZTE4ODk/

'Reversing > Malware Analysis' 카테고리의 다른 글

[Ransomware] .micro 랜섬웨어 분석 보고서 (1)	2016.02.22
ixaobny.exe 분석 보고서 (0)	2016.02.16
WireShark를 통한 Nethost.exe악성코드 네트워크 분석 (0)	2015.11.30
Nethost.exe분석 (1)	2015.11.26
server.exe 분석 (0)	2015.10.05

'Reversing > Malware Analysis' 카테고리의 다른 글

'Reversing > Malware Analysis' 카테고리의 다른 글

'Reversing > Malware Analysis' 카테고리의 다른 글

'Reversing > Malware Analysis' 카테고리의 다른 글

'Reversing > Malware Analysis' 카테고리의 다른 글

'Reversing > Malware Analysis' 카테고리의 다른 글

'Reversing > Malware Analysis' 카테고리의 다른 글

개요

'Reversing > Malware Analysis' 카테고리의 다른 글

티스토리툴바