Kali-KM_Security Study

개요

기본적인 파일 정보는 아래와 같다.

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 주소를 얻어온다. 그 후 대량의 Packet 을 대상 주소로 전송하는 악성코드이다.





분석

자가 복사

해당 샘플의 경우 대상 환경에서의 지속성을 향상시키기 위하여 자기 자신을 복사한다. 복사되는 경로는 아래와 같다.
  • /usr/bin/{random_filename}
  • /bin/{random_filename}
  • /tmp/{random_filename}
  • /lib/libudev4.so



지속성 유지
추가적으로 악성 샘플을 다시 실행시키기 위해 '/etc/crontab' 파일을 변조한다. crontab 파일은 Windows 의 작업 스케쥴러와 같은 역할을 하며, 맨 마지막 줄의 내용이 추가된 것을 확인 할 수 있다. 해당 내용은 3분 마다 /etc/cron.hourly/gcc4.sh 를 실행하는 것이다.

remnux@remnux:~/test$ cat /etc/crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#
*/3 * * * * root /etc/cron.hourly/gcc4.sh


gcc4.sh 는 상기에 설명한 바와 같이 복사한 자기 자신(/lib/libudev4.so) 을 libude4.so.6 라는 이름으로 복사 후 실행시키는 내용이다.

remnux@remnux:~/test$ cat /etc/cron.hourly/gcc4.sh
#!/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin
cp /lib/libudev4.so /lib/libudev4.so.6
/lib/libudev4.so.6


/etc/init.d 에도 Random 한 이름을 파일을 생성한다. 

remnux@remnux:~/test$ cat /etc/init.d/{random_filename}
#!/bin/sh
# chkconfig: 12345 90 90
# description:{random_filename}
### BEGIN INIT INFO
# Provides:{random_filename}
# Required-Start:
# Required-Stop:
# Default-Start: 1 2 3 4 5
# Default-Stop:
# Short-Description: {random_filename}
### END INIT INFO
case $1 in
start)
/usr/bin/{random_filename}
;;
stop)
;;
*)
/usr/bin/{random_filename}
;;
esac


또한 "/etc/rc*.d" 경로 밑에 S90{random_filename} 의 형태로 위의 "/etc/init.d/{random_filename}" 을 가리키는 Link 파일을 생성한다. 여기서 rc*.d 폴더는 부팅 레벨에 따라, 각각의 부팅 레벨 폴더에 있는 파일들을 자동으로 실행하는 경로이다.



네트워크 (DDoS)

아래 주소를 DNS 요청으로 얻어오며, TCP Packet 과 UDP Packet 을 전송하는 것을 확인 할 수 있다. 해당 주소로부터 공격 대상에 대한 IP 주소를 받아온다.
  • 114.***.***.114 ; 중국의 네임 서버
  • 137.***.***.224 ; 원격지 주소 (공격 대상의 주소를 얻어옴)


원격지와의 통신을 통해 암호화 된 공격 대상의 IP 주소를 받아온다. 그 후 encrypt_code 부분을 통해 XOR 연산을 하여 해당 내용을 복호화 한다. 분석 당시ㅡ복호화 된 내용을 보면 0xc******8 로 IP 주소 104.***.***.203 을 가리키고 있다.


공격 대상의 주소를 가지고 온 뒤, 아래와 같이 대상 주소에 수 많은 패킷을 보낸다. 과도한 Packet 전송 동작 등을 보아 DDoS 공격 행위로 추정된다.


분석 당시ㅡ공격 대상이 되는 곳에 대해 조사한 결과, 아래와 같이 SharkTech 라는 곳을 알 수 있었다. 또한 대상은 DDoS 보호 서비스와 관련 된 사이트임을 알 수 있다.



기타
# 1
실행 시 자신을 Background 에서 실행되도록 한다.



#2
통신 중 지정 된 신호를 받을 경우 다운로드 동작을 수행 할 수 있다. 다운로드 주소는 공격자가 지정 할 수 있으며, 다운로드 완료 후 해당 파일을 실행한다.



#3
해당 샘플이 통신하는 dns.bbgbbg.top 의 경우 Whois 결과가 아래와 같다. 이는 whois guard 에 의해 보호된 주소임을 알 수 있다.

Domain Name: b****g.t*p
Registry Domain ID: D20160920G10001G_81549331-top
Registrar WHOIS Server: whois.namecheap.com
Updated Date: 2016-09-20T00:04:28Z
Creation Date: 2016-09-20T00:04:24Z
Registry Expiry Date: 2020-09-20T00:04:24Z
Registrar: Namecheap Inc.
Registrar IANA ID: 1068
Registrar Abuse Contact Email: abuse@namecheap.com
Registrar Abuse Contact Phone: +1.6613102107
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Registry Registrant ID: C20160920C_09331172-top
Registrant Name: WhoisGuard Protected
Registrant Organization: WhoisGuard, Inc.
Registrant Street: P.O. Box 0823-03411
Registrant City: Panama
Registrant State/Province: Panama
Registrant Postal Code: 0
Registrant Country: PA
Registrant Phone: +507.8365503
Registrant Phone Ext:
Registrant Fax: +51.17057182
Registrant Fax Ext:
Registry Admin ID: C20160920C_09331173-top
Admin Name: WhoisGuard Protected
Admin Organization: WhoisGuard, Inc.


#4
지속적으로 랜덤한 문자열을 생성 후, "/lib/libudev4.so" 를 해당 이름으로 복사한다. 그리고 한번에 5개씩 해당 이름으로 프로세스를 생성한다.  하기의 동작은 반복적으로 이루어지기 때문에, 반복적으로 생성&소멸 된다.


이 때,  기존의 랜덤한 이름의 또 다른 자기 자신은 아래와 같이 삭제한다.



#5
프로세스의 도입부에서 아래의 문자열을 복호화한다.
cat resolv.conf
sh
bash
su
ps -ef
ls
ls -la
top
netstat -an
netstat -an
top
grep "A"
sleep 1
cd /etc
echo "find"
ifconfig eth0
ifconfig
route -n
gnome-terminal
id
who
whoami
pwd
uptime

복호화 된 문자들은 아래와 같이 execve 명령을 통해 악성프로세스의 인자로 주어지게 된다.






대응 방안

프로세스 종료

동작 중인 프로세스에 대해 종료해야 한다. 종료하고자 하는 프로세스의 이름은 아래와 같은 형태이며, 동일한 이름을 가진 5개의 프로세스와, 자식-부모 관계를 갖고 있는 4개의 프로세스를 추가로 삭제해야 한다.
  • {random_10_chrar_filename}

파일 삭제
악성코드가 감염 환경에서의 지속성을 유지하기 위한 요소들을 제거해야 한다.
  • /usr/bin/{random_filename}
  • /bin/{random_filename}
  • /tmp/{random_filename}
  • /etc/rc*.d/S90{{random_filename}
  • /etc/init.d/{random_filename}
  • /etc/cron.hourly/gcc4.sh


고려 사항

  • 잔여 프로세스가 계속 실행되고 있음ㅡ아마 잔여프로세스가 새로운 이름으로 원본 파일을 실행할 것으로 추정
  • crontab 에 의해 3분마다 다시 프로세스 실행
  • 이와 같은 경우 Windows 라면 메모리 진단 및 치료를 수행, 하지만 수동 치료의 경우에는?


Comment +1

  • 질문드립니다. 2019.11.20 16:08

    안녕하세요 작성자님
    서버용 리눅스 Debian에서
    지금의 바이러스에 감염되었는데요..

    프로세스로 추정되는 것들을 찾아서
    kill -9 명령어를 실행했으나, 없어지지 않네요..

    물론 top 명령어로
    좀비 프로세스가 아니라는 것은 확인했으나
    프로세스가 죽지 않아서 도움을 구하고자 합니다.

    '부모 관계의 프로세스 4개를 종료해야한다'
    는 문구를 조금더 구체적으로 알수있을까요?

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 */
}
cs

위와 같은 방식으로 파일이 감염되면 아래와 같은 구조를 띄게 된다. 기존의 AddressofEntrypointImageBase를 더한 값(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(00x1000, 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;
}
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, 00);
    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 + 0xd5800);
    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;
}
cs

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

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



5. 결론

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

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


Comment +0

개요

랜섬웨어나 게임 계정, 금융 정보 탈취 등으로 인한 피해를 끊이지 않고 있다. 이런 악성코드를 제작하는 공격자의 목적은 결국 금전을 획득하는 것이다. 우리는 많은 매체들을 통해 이런 사건에 대한 피해 소식을 접할 수 있다. 랜섬웨어의 경우 악성코드에 감염되면 파일이 암호화가 되어 공격자에게 금액을 지불해야 한다. 하지만 사용자 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 감염 여부를 확인하여야 한다.


Comment +0


PETYA 분석.pdf


Comment +2


[Malware]DarkSeoul분석.pdf



Comment +0



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를 통해 다음 파일에 대한 활동을 시작한다. 이렇게 스레드가 생성이 되고 스레드가 대상 모든 파일에 암호화가 진행되면, 스레드가 종료되며 해당 프로세스도 종료된다.

Comment +0


Malware_ixaobny분석.pdf


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


Comment +0

  1. 개요


 분석하고자 하는 파일에 대한 정보는 위의 표와 같다. 이제 이 파일을 가지고 정적 분석과, 동적 분석, 그리고 마지막으로 상세 분석을 진행할 것이다. 정적 분석에서는 해당 파일의 실행 없이 진행이 되며, 동적 분석은 해당 파일을 실행한 결과를 나타낸다. 상세 분석은 이 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은 생성되지 않았다. 또한 지속성을 위한 해당 레지스트리 값이 변화하지 않았다. 다음과 같이 생각해볼 수가 있다.

 

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

 

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

 

# Cuckoo 분석 결과

/malwr.com/analysis/YzRjOTg0ZThmYWYzNDgxYWIyM2QwNGRkNWMxZTE4ODk/



Comment +0

  1. 개요


 악성코드에 대해 공부를 할 때는 몰랐지만, 직접 여러 악성코드를 분석해보니 네트워크와 연결을 진행하는 악성코드가 정말 많다는 것을 알게 되었습니다. 그렇기에 네트워크와 관련해서 정말 지식이 부족하다고 느껴지기에 계속 미루는 것보단 한번 직접 네트워크에 대해 간간히 공부해보자는 생각에서부터 이렇게 시작하게 되었습니다.

 이번 문서에서는 네트워크에 대한 저의 첫 문서인 만큼 너무 깊이는 들어가지고 않고 향후에 악성코드를 분석하는데 있어 저번과 같은 지장이 있지 않을 정도로 학습을 하려고 합니다. 따라서 이번에는 간단하게 WireShark에 대하여 기초적인 학습을 진행하였습니다. 

  

1.1 WireShark란?

보안 공부를 시작한지 얼마 안된 사람들도WireShark나 Nmap에 대해서는 자주 들을 수가 있을 것입니다. WireShark는 세계에서 가장 널리 쓰이는네트워크 프로토콜 분석기로 아래와 같은 장점이 있습니다.

그림 1. WireShark

    • 오픈 소스라 무료로 사용이 가능
    • Packet Capture를 위한 pcap 네트워크 라이브러리 제공
    • Tcpdump와 유사하나 GUI를 통해 편리한 인터페이스 제공
    • 다양한 필터링 기능 제공


1.2 네트워크 개념

아래의 그림은 OSI 7 Layer에서 각 레이어별 기능과 통신 프로토콜에 대해 간단히 정리되어 있는 것이다.

그림 2. 각 레이어별 기능과 프로토콜

아래의 그림은 TCP를 이요한 3-Way Handshaking으로 이후에 나오는 내용이기에 참고할 겸 첨부하였다.

그림 3. 3-Way HandShake



2.패킷 캡처


 우선 실행 후 화면은 아래의 그림-3와 같다. Start라는 버튼 아래 현재 환경에서 갖는 네트워크 장치에 대해 목록이 있으며, 이 중에 하나를 선택 후 'Start'를 누르면 캡처가 시작된다.

그림 4. WireShark 실행 화면

  이렇게 패킷 캡처를 시작하면 네트워크 장치를 지나는 패킷들이 나열되며 본인의 PC 환경에 따라 상이하지만 대부분 정말 많은 패킷의 교환을 확인할 수가 있다.


2.1 패킷 캡쳐

이제 실제 악성코드가 행위에 사용했던 네트워크 패킷을 한번 확인해보자. 해당 악성코드는 저번 주 분석에 실패를 하였던 Nethost.exe에 초점을 맞추었다.

그림 5. Packet Capture 화면

위에서 Start를 통해 악성코드를 실행하기 전에 캡처한다. 그 후 악성코드가 실행되는 동안의 패킷들이 와이어샤크가 기록을 하며 악성코드의 종료와 함께 캡처를 중지하였고 총 2182개의 패킷이 캡처되었으며, 매우 많은 양임을 알 수가 있다. 따라서 아래와 같은 필터링 기능을 통해 범위를 줄여보자.



2.2 실습 – GET /chrome_extension.exe

아래와 같은 필터 옵션을 적용하므로 이전보다 가독성이 좋아지는 것을 확인할 수가 있다. 해당 패킷을 보면 그림-3에서와 같이 3 way handshake를 통해 연결이 진행되는 것을 확인할 수가 있다.

그림 6. TCP 연결

위의 연결이 해제된 후 재연결이 되면 HTTP로 해당 아이피에 /chrome_extension.exe를 요청하는 것을 확인할 수가 있다.

그림 7. TCP 연결 & extension.exe요청

 이렇게 요청을 한 후 아래의 그림과 같이 1514의 길이만큼 지속적으로 패킷을 받는 것을 확인할 수가 있다. 여기서의 패킷은 디버거를 통해 확인해본 결과 extension.exe에 기록될 명령어들의 내용이다. 아래의 그림과 같이 확인할 수가 있다.

그림 8. GET - Extension.exe



2.3 실습 – GET /chrome_start_page.exe

 Nethost.exe는 이러한 동작을 한번 더 반복하는데 이번에는 extension.exe가 아니라 start_page.exe로 데이터를 요청하는 것을 확인할 수가 있다. 아래의 그림과 같다.

그림 9. GET – Start_Page.exe

 이와 같이 IP주소 193.238.153.91과의 통신은 각 파일에 기록될 데이터들을 주고 받고 종료가 된다. 따라서 다른 IP와 연결되는 패킷도 확인을 해보자.


2.4 실습 – 이 외 패킷

 위의 작업이 끝난 후 다른 패킷들을 살펴 본 결과 아래의 패킷을 확인할 수 있다. HTTP로 185.20.186.44에 패킷을 보내는 것으로 마지막에 Fail이라는 단어를 같이 보내는 것으로 보아 악성코드의 어떠한 기능이 실패했다는 것을 추측해볼 수가 있다.

그림 10. Fail을 보내는 패킷

 하지만 이것만 가지고는 불분명했지만 뒤에 캡처된 패킷의 경우 종료를 알리는 것을 확인할 수가 있었고, 이외의 기능이 없이 이와 관련된 연결이 모두 종료되는 것을 확인할 수가 있었다.

그림 11. Fail이후의 패킷

 


  3. 결론


 지난 주에 nethost.exe를 분석하며 해당 악성코드가 웹 브라우저의 정보를 가지고 오는 것임을 추후에 확인할 수가 있었는데, 이러한 기능을 하지 않고 종료되는 것을 확인할 수가 있었다.

 이에 대해 몇 가지 결론을 생각해본다면 해당 서버에 연결을 시도하고 RST와 ACK 패킷이 돌아오는 것으로 보아, 해당 서버가 현재는 막혔을 것이라 예상을 해볼 수가 있다.

 이러한 네트워크 분석을 병행하므로 확실히 해당 악성코드에 대한 이해도가 높아지는 것을 체감할 수가 있었고, 이론만 공부하다가 악성코드를 직접 분석해보며 항상 느끼는 것이지만 무엇이 부족한지 매번 알게 된다는 점이다. 따라서 이후에 네트워크에 대하여 한계를 느끼면 다시 해당 문서를 작성하고자 합니다.



참고

필터링 옵션과 관련하여 참고

https://wiki.wireshark.org/CaptureFilters

https://wiki.wireshark.org/DisplayFilters

전체적인 내용

    http://asec.ahnlab.com/156

    http://openness.tistory.com/entry/Wireshark-%EC%82%AC%EC%9A%A9%EB%B2%95


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

ixaobny.exe 분석 보고서  (0) 2016.02.16
90u7f65d.exe Malware Analysis  (0) 2015.12.28
WireShark를 통한 Nethost.exe악성코드 네트워크 분석  (0) 2015.11.30
Nethost.exe분석  (1) 2015.11.26
server.exe 분석  (0) 2015.10.05
Morris Worm Source Code  (0) 2015.02.17

Comment +0

  개요


해당 악성코드 파일(nethost.exe)에 대한 기본적인 파일 정보는 아래의 표-1과 같다. 

이를 통해 해당 악성코드는 러시아어로 작성된 것과 버전에 따라 유포자 및 제작자에 의해 업데이트가 될 수 있다는 것을 확인할 수가 있다.

  

  정적 분석


정적 분석에서는 PE구조를 확인하고, 이를 통해 패킹의 여부를 확인하며 그 외에 PE구조의 특이사항을 확인할 것이다. 이러한 PE 구조의 특이사항이란 IAT나 문자열 등을 포함하며 이를 통해 프로세스의 대략적인 기능에 대하여 추측해볼 것입니다.


PE구조 분석

PE구조를 확인해본 결과 별도의 패킹이 되지 않은 것을 확인할 수가 있었으며, TLS 영역도 존재하지 않음을 확인할 수가 있다. 아래의 그림은 DIE를 통해 해당 프로그램을 분석한 결과이다..

그림 1. PE구조 분석

 

그림에서와 같이 해당 악성코드는 C/C++로 작성된 것을 확인할 수가 있다.

  

문자열 분석

해당 악성코드에는 다양한 문자열들이 존재하는데 네트워킹과 관련된 문자열이 많음을 확인할 수가 있습니다. 몇 가지 선별한 문자열은 아래와 같다. 

 

이러한 문자열들을 통하여 인터넷 브라우저를 통하여 네트워킹을 진행하며 이외에도 ping 명령어, 그리고 레지스트리 키, FTP 등을 확인할 수가 있다. 따라서 웹브라우저의 연결을 통하여 특정한 사이트와 연결을 하거나, 다른 어떠한 작업을 진행하기 위하여 ping 명령어를 사용하는 것이라 예상해 볼 수가 있다.

  

Import Address Table 분석

어떤 함수들이 사용되고 있는지 IAT에 나타나있는 항목을 Dependency Walker를 통해 확인해 보았으며, 이 중에서 악성코드의 기능으로 의심되는 몇 가지 항목은 아래의 표와 같습니다. 

 

이를 통해 보았을 때 WS2_32.dll에서 네트워킹과 관련된 API들이 많이 사용되는 것을 알 수가 있다. 또한 CRYPT32.dll과 ADVAPI32.dll을 통해 암호화와 레지스트리 값 설정을 하는 함수가 존재하며 KERNEL32.dll을 특정한 파일과 기능하는 함수들이 있고 SHELL32.dll을 통해 특정한 명령어를 실행할 것이라 예상할 수가 있다.


동적 분석


동적 분석에서는 정적 분석을 토대로 예상되는 기능들을 직접 안전한 환경에서 실행하므로 일어나는 변화들을 관찰하여 이에 대하여 알아볼 것입니다. 여기선 Process Explorer를 통하여 프로세스의 변화를 관찰하고 TCP Viewer를 통하여 네트워크를 관찰하고 마지막으로 MFT를 분석할 것입니다.


          프로세스 분석

해당 프로세스를 실행시키고 ProcessExplorer을 통하여 아래와 같이 extension.exe가 실행이 추가적으로 실행이 되며, 이후 startpm.exe도 실행이 되는 것을 알 수가 있다.

그림 2. 프로세스 진행과정(1)

 

이렇게 3개의 프로세스가 실행되고 startpm.exe가 종료되기 전에 하위 프로세스로 CMD를 통하여 Ping 명령어를 사용하는 것을 확인할 수가 있었다.

그림 3. 프로세스 진행과정(2)

 

이러한 결과를 토대로 이후4장 상세 분석을 함에 참고를 하면 도움이 될 것이다.

  

네트워크 분석

해당 악성코드가 네트워킹을 하는 과정에 대하여 어느 곳과 연결이 네트워킹을 하는지 알아보기 위하여 TCP Viewer를 통하여 확인해보았다.

 

그림 4. TCP/UDP 연결 확인

 

위의 그림에서와 같이 악성코드가 실행된 후 이전에는 없던 System Process(PID:0)이 생기는 확인할 수가 있다. 이렇게 사용되는 프로세스와 원격주소에 대하여 정리한 것은 아래의 표와 같다.

 

 

이와 같이 총 9개의 주소 혹은 IP와 네트워킹을 하는 것을 확인할 수가 있으며, 프로세스가 종료된 후에는 이러한 네트워킹도 모두 종료가 되는 것을 확인할 수가 있었다.

  

MFT 분석

악성코드가 동작한 시간 이후로 MFT에 나타난 변화를 통하여 어떠한 파일이나 디렉터리가 생성되었는지를 확인해 보았으며 아래의 표와 같이 정리할 수가 있습니다. 

 

위의 표와 같이 SystemDir이라는 디렉터리를 생성 후 Temp나 그 곳에 부차적인 파일들을 생성하여 실행을 진행하고 실행이 완료된 후에는 삭제하는 것을 확인할 수가 있었다.

그 후 IE와 관련된 흔적들을 지우는 것을 확인할 수 있었으며 이를 통해 웹을 통한 행위에 대해 유심히 살펴보아야 함을 알 수가 있다.

  


상세 분석


상세 분석에서는 해당 악성코드에 대하여 상세한 분석이 진행되며, 필요하다면 부차적인 파일들도 상세 분석을 진행할 것이다.


Nethost.exe분석

우선 MFT에서 분석한 바와 같이 Nethost는 %AppData%\Local\SystemDir을 생성하는 것을 확인할 수가 있었다. 이후에 extension.exe와 startpm.exe는 동시에 생성되는 것이 아니라 같은 방식으로 extension.exe이 먼저 생성되기에 이에 맞추어 startpm.exe의 생성과정은 생략하였다.

그림 5. SystemDir 생성

 

이렇게 생성된 디렉터리와 %AppData\Local\%Temp 디렉터리를 통하여 악성코드가 어떠한 행위를 하는 것을 알 수가 있었다. 이렇게 기능을 한 후 프로세스가 종료된 후 디렉터리 내에 해당하는 내용들을 삭제하는 것 또한 확인할 수가 있었다.

그림 6. 네트워크 연결

 

네트워킹을 진행하는 것을 확인할 수가 있으며 send와 recv명령어를 사용하는 것을 확인할 수가 있었으며 동적 분석에서 확인한 바와 같이 여러 IP와 연결하는 것을 확인할 수가 있었다.

그림 7. CreateFile함수 통한 파일 생성

 

위의 그림과 같이 SystemDir 디렉터리에 extension.exe라는 파일을 생성을 하며, 이후엔 이와 같은 방식으로 startpm.exe를 생성한다. 이렇게 생성된 파일은 아래의 그림과 같이 WriteFile API를 통하여 버퍼가 기록된다.

그림 8. WriteFile 통한 기록

 

이렇게 recv를 통해 데이터를 받은 후 WriteFile을 통하여 4096Byte 만큼씩 데이터를 기록하는 것을 확인할 수가 있다. 이때의 IP는 193.238.153.90이다.

그림 9. MoveFile을 통한 파일 이동

 

872KB까지 기록이 된 후 MoveFile 함수를 통하여 기록되던 파일(SystemDir\)이 Temp디렉터리에 exe.tmp로 이동 되는 것을 확인할 수가 있다. 이후 아래의 그림과 같이 CopyFile 함수를 통하여 최초에 실행됐던 nethost.exe가 Temp\extension.exe와 Temp\startpm.exe로 복사가 되는 것을 확인할 수가 있다.

그림 10. CopyFile을 통한 파일 복사

 

이렇게 된 후 .tmp로 옮겨진 파일을 읽어서, CopyFile을 통한 원본과 같은 파일에 쓰는 것을 아래의 그림과 같이 확인할 수가 있다.

그림 11. 복사된 파일에 기록

위의 루프가 끝난 후 아래 그림 같이 CreateProcess를 통하여 각 파일(extension.exe, startpm.exe)를 실행하는데 여기서 이를 실행할 때 아래의 그림과 같이 인자를 주는 것을 확인할 수가 있었다.

그림 12. CreateProcess API 함수

     

CreateProcess의 CommandLine에 사용되는 각 프로세스의 인자는 아래의 표-6에 정리한 것을 볼 수가 있다. 여기서 이는 모두 한 줄에 해당하는 항목임을 유의하자. 

 

이렇게 각 프로세스는 생성된 후 아래의 그림과 같이 DeleteFile API를 사용하여 exe.tmp파일을 제거한다.

그림 13. DeleteFile API 함수

이렇게 작업을 수행한 후 해당 nethost.exe는 종료가 되는 것을 알 수가 있다. 이러한 분석을 통해 보았듯이, nethost.exe는 Dropper인 것을 알 수가 있다.




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

90u7f65d.exe Malware Analysis  (0) 2015.12.28
WireShark를 통한 Nethost.exe악성코드 네트워크 분석  (0) 2015.11.30
Nethost.exe분석  (1) 2015.11.26
server.exe 분석  (0) 2015.10.05
Morris Worm Source Code  (0) 2015.02.17
Rejoice와 서버파일 분석(정적)  (0) 2015.01.15

Comment +1

  • 고광우 2017.11.12 15:41

    Nethost.exe 실제 악성프로그램을 구해서 악성코드 분석을 하면서 공부를 하고 싶습니다.

    대부분의 사이트들이 분석 보고서만 보여주거나 URL을 제공해도 대부분 막혀 있습니다.

    혹시 위의 프로그램을 주실 수 있습니까?