실전 악성코드와 멀웨어 분석 실습 7-1 분석

안녕하세요. Message입니다.

<실전 악성코드와 멀웨어 분석> 책의 실습 문제 7-1을 분석합니다.

분석환경은 Windows 7 Ultimate 64x / Vmwre 12.1.0 build 입니다.

 

 

------------------------------------------------------------------------------------------------------------------------------------------

0. 기초 동적 분석

------------------------------------------------------------------------------------------------------------------------------------------

문제풀이에 앞서 간단한 동적 분석을 진행합니다.

 

1) PE구조 & 패킹체크

별도의 패킹이 되어 있지 않습니다.

 

2) DLL 체크

KERNEL32.dll, ADVAPI32.dll, WININET.dll 총 3개의 dll을 임포트합니다.

눈여겨 보지 않았었는데, 각 dll별로 임포트하고 있는 숫자를 CFF에서 표기해주는군요.

각 DLL에서 43개, 3개, 2개의 API를 임포트하고 있습니다.

 

- KERNEL32.dll

항상 가장 많은 API들을 임포트하고 있어서 그런지, 딱 보았을때 어떤 API를 이용하여

어떤 악성행위를 하는지 가장 감이 오지 않습니다.

 

- ADVAPI32.dll

서비스 관련 API들이 보입니다. 아마 백그라운드에서 동작할 수 있음을 염두해둡니다.

 

- WININET.dll

지난번의 문제들과 동일하게 Internet 연결 관련 API들이 보입니다.

 

 

3) String 체크

IDA의 String Window(Shift+F12)를 보면 아래와 같이 .data섹션(초기화된 전역변수, 읽기/쓰기 가능) 에서

MalService, 악성URL, IE와 버전 등의 스트링값이 존재합니다.

 

------------------------------------------------------------------------------------------------------------------------------------------

1. 이 프로그램은 어떤 방식으로 컴퓨터가 재시작할 때마다 실행(지속 메커니즘)을 보장하는가?

------------------------------------------------------------------------------------------------------------------------------------------

악성코드를 호출하면 main에서 가장 첫번째로 호출하는 함수가 바로 StartServiceCtrlDispatcher API입니다.

실전 악성코드 책에 있는 악성코드를 분석하면서, 서비스에 등록되는 악성코드 실습을 이미 해봤기에

그냥 비슷하거나 동일한 케이스라고만 막연히 생각하였는데, 가만보니 처음보는 API였습니다.

그래서 지난 실습을 검색하여서, 어떤 차이점이 있나 확인해보았습니다.

- 실습3-2 URL : http://redscreen.tistory.com/13

 

결론적으로 주요 골자는 아래와 같습니다.

"서비스는 WinLogon.exe가 호출하는 Services.exe(SCM:서비스제어관리자)에 의해 관리되지만

예외적으로 DLL 기반의 서비스는 svchost.exe에 의해 관리된다"

지난번엔 DLL기반의 서비스를 분석하였고, 오늘은 SCM이 관리하는 서비스에 관한 내용을 살펴봐야 합니다.

 

main 어셈블리 코드를 살펴보면 아래와 같습니다.

아직 악성코드가 어떤 방식으로 실행되어지고, 서비스가 등록되는지 파악은 안되지만

"MalService" 라는 서비스를 만들어 동작하고 있음을 확인되었습니다.

 

 

------------------------------------------------------------------------------------------------------------------------------------------

2. 이 프로그램은 왜 뮤텍스를 이용하고 있는가?

------------------------------------------------------------------------------------------------------------------------------------------

짧은 메인에서 StartServiceCtrlDispatcherA API를 호출하고 난 이후에 바로 sub_401040 서브루틴을 호출합니다.

해당 서브루틴은 아래와 같이 OpenMutexA API를 호출하고

함수가 종료된 이후에 값이 0인지 확인하는 TEST EAX, EAX 명령어를 이용해 프로세스 종료 혹은 진행을 결정합니다.

특이한점은, "HGL345" 라는 이름의 뮤텍스를 오픈해서 핸들을 정상적으로 가져왔을 경우에

왼쪽으로 분기하여 ExitProcess를 호출하며 프로세스를 종료시키는 점입니다. 

 

만약 해당 뮤텍스가 존재하지 않는다면, 오른쪽으로 분기하여 아래와 코드를 실행합니다.

기존에 있는 뮤텍스에 접근하는것이 아니라, CreateMutexA API를 이용하여

방금 시도했던 "HGL345" 뮤텍스를 새로 생성합니다.

이런 코드구조로 실행되는 이유는 특정 시간에 시스템에서 실행 파일 사본이 하나만 동작하게 보장하기 위해서입니다.

만약 이미 악성코드가 수행중이라면, 바로 위의 OpenMutexA 함수 호출을 성공하면서, 프로세스가 종료됩니다.

 

사실 뭔가 내용은 많아보이지만, Hex-ray 상으로 살펴보면, 그냥 스쳐지나가는 체크일뿐입니다.

이후에 맨아래의 CreateServiceA를 호출하기 위해

OpenSCMManagerA, GetCurrentProcess, GetModuleFileNameA API를 순차적으로 호출합니다.

① OpenSCMManagerA : 프로그램이 서비스를 추가하거나 수정할 수 있는 서비스 제어 관리자 핸들 반환

② GetCurrentProcess : 현재 프로세스의 핸들 반환 (근데 왜 실행했는지는 모르겠네요)

③ GetModuleFileNameA : 첫째 인자가 0 인 경우, 현재 동작중인 실행 파일이나 로드된 DLL의 전체 경로명 반환

Tip. API 뒤에 붙은 A or W는 String을 다루는 API임을 알려줍니다. A는 ANSI를, W는 UNICODE를 의미합니다.

 

CreateServiceA API를 호출하기 위해서는 아래처럼 많은 인자값들이 필요합니다.

그중에 주요한 인자만 정리하고 넘어갑니다.

- hSCManager : 서비스 실행에 필요한 SCM / ①에서 얻은 SCM 핸들

- dwServiceType : SERVICE_WIN32_OWN_PROCESS(0x10)

        ※ SERVICE_KERNEL_DRIVER(0x01) / SERVICE_FILE_SYSTEM_DRIVER(0x02) / SERVICE_ADAPTER(0x04) / SERVICE_RECOGNIZER_DRIVER(0x08)

- dwStartType : 시스템 시작 시 자동 시작 / SERVICE_AUTO_START(0x02)

       ※ SERVICE_BOOT_START(0x00) / SERVICE_SYSTEM_START(0x01) / SERVICE_DEMAND_START(0x03) / SERVICE_DISABLED(0x04)

- lpBinaryPathName : 실행파일의 바이너리 경로 / ③에서 얻은 경로

 

서비스함수를 실행한 이후에는 시간과 관련된

SystemTimeToFileTIme, CreateWaitableTimerA, SetWaitableTimer, WaitForSingleObject API들을 순차적으로 실행합니다.

여기서 중요 포인트는 WaitForSingleObject API입니다.

 

아래 Hex-ray 결과에서 알 수 있다싶이 WaitForSingleObject의 결과값이 0이되면

20번 반복수행되는 CreateThread가 동작합니다.

WaitForSingleObject의 인자값을 넣어주기 위해서 CreateWaitableTimerA, SetWaitableTimer 등을 실행합니다.

① SystemTimeToFileTIme : 시스템 타임 --> 타임 포맷으로 변환 / ③의 인자값으로 사용하기 위해

② CreateWaitableTimerA : waitable 타이머 객체 생성( 생성시 Non-Signaled 상태 ) / ①의 결과값을 인자로 사용

③ SetWaitableTimer : waitable 타이머 객체에 알람 시간 설정 ( 알람 시간이 되면 Signaled 상태 ) / ②의 결과값을 인자로 사용

④ WaitForSingleObject : 넣어준 waitable 타이머 객체가 Signaled 상태가 되면, WAIT_OBJECT_0(0x00000000L) 반환

Tip. 자료형에 따른 접미사

 

SystemTime.wYear에 2100을 할당함으로서, 2100년 1월 1일이 되어

반환값이 WAIT_OBJECT_0(0x00000000L)이면 20번의 CreateThread를 수행하게됩니다.

CreateThread안에는 StartAddress 라는 함수가 들어있는데,

InternetOpenA -> InternetOpenUrl 순으로 "http://www.......book.com" URL에 IE8을 이용하여

반복적으로 접근을 시도합니다. 20개의 스레드가 동작하므로 상당한 트래픽이 유발될 수도 있습니다.

DDoS 공격을 위한 악성코드가 이런식으로 구성되는구나...싶었습니다.

 

------------------------------------------------------------------------------------------------------------------------------------------

3. 이 프로그램을 탐지할 때 호스트 기반으로 좋은 시그니처는 무엇인가?

4. 이 악성코드를 탐지할 때 네트워크 기반으로 좋은 시그니처는 무엇인가?

5. 이 프로그램의 목적은 무엇인가?

6. 이 프로그램은 언제 실행을 종료하는가?

------------------------------------------------------------------------------------------------------------------------------------------

3. 호스트기반의 좋은 시그니처는 "MalService"라는 서비스와 "HGL345"라는 이름의 뮤텍스입니다.

4. 네트워크 기반의 시그니처는 IE8.0과 URL입니다.

5. 프로그램의 목적은 특정 시간대에 수행되는 DDoS 공격입니다.

6. 종료되지 않으며, 2100년 1월 1일부터 20개의 스레드를 동작시켜 무한루프로 동작합니다.