[THREAT ANALYSIS] TDL4, TDL3와 무엇이 달라졌나

1부_TDL4 부트킷의 유래와 배포 과정

 

연재 목차 1. TDL4 부트킷의 유래 및 배포 과정, 특징(2011년 이번호) 2. TDL4 부트킷 상세 분석 과정과 목적(2011년11월호) 3. TDL4 부트킷 치료와 예방 방법(2011년12월호)

 

 

안철수연구소는2009년 하반기TDL3 루트킷(Rootkit)에 대한 분석보고서와 전용 백신을 배포한 바 있다. TDL3는 하드디스크의 언파티션드(Unpartitioned) 영역에 악성코드를 위치시켜 파일로의 존재를 감추는 주요한 특징과 시스템의 파일시스템 드라이버를 패치하여 안티바이러스 제품들로부터 자신을 보호하는 새로운 기법을 사용했다. 그 후로부터 몇 개월이 지나지 않아 새롭게 업그레이드된TDL4에 대한 해외 감염보고가 나오기 시작했다.

TDL3와TDL4의 가장 큰 차이점은 시스템의MBR(Master Boot Record)을 감염시켜TDL4 루트킷을 자동 실행하게 하는 부트킷 기법이 추가되었다는 점이다. 또한 윈도우 비스타 이후부터 적용된64비트OS 동작과 커널보안(Driver Signing, Code Integrity) 우회 기법이 새로운 방법으로 업그레이드 되었다.

월간‘안’에서는 기존의 윈도우OS 뿐만 아니라 윈도우 비스타, 윈도우7(x86 & x64)을 아우르는TDL4 부트킷의 감염 특징과 기법, 증상, 치료 방법을3회에 걸쳐 자세히 알아보고자 한다.

 

1. TDL의 유래

 

TDL 루트킷은 2008년 7월경 처음 등장하여 알려지기 시작했다. 대표적인 것으로는 TDSS, Alureon, Olmarik 등을 들 수 있다. TDL이라는 이름은 당시 악성코드 드라이버 파일 이름(tdlserv.sys)과 악성코드 레지스트리 설정 이름(HKLM＼Software＼tdl)에서 유래되었다. 당시에는 ZwEnumerateKey, ZwFlushInstructionCache 함수를 후킹하여 자신의 존재를 은폐시키고 ＼Device＼HarddiskVolume?에 자신의 디바이스를 등록(Attach)시켜 필터링했다.

이 TDL 루트킷은 2009년 7월경에는 ‘TDL2/2+’로 업데이트되어 하드디스크의 디바이스 스택에 등록하고 IofCallDriver를 후킹하여 안티바이러스 제품을 회피하였다.

이어 2009년 말에 발견된 ‘TDL3/3+’은 물리적 디스크의 마지막 부분인 언파티션드 영역에 자신의 악성코드를 저장하고 디스크 디바이스를 패치하여 자신의 볼륨을 만들어 사용하게 된다. 악성코드 드라이버는 시스템 프로세스에 쓰레드를 인젝션하여 C&C(Command and Control) 서버와 연결되었다.
 

[그림1] eEye의 부트루트킷 발표 자료

 

2010년 여름 등장한 ‘TDL4’는 MBR(마스트 부트 레코드)을 감염시키는 부트킷(Bootkit) 기법과 x64 시스템 보안 회피로 무장되어 새롭게 등장한다. 여기서 부트킷이란 시스템에 설치된 OS로 제어권이 넘어오기 전에 디스크의 MBR 코드를 감염시켜 OS의 부트 제어 코드를 패치시키도록 하는 악성코드를 통칭한다. eEye의 연구원들에 의해 2007년 발표된 ‘부트루트킷’이 오늘날의 부트킷의 시초로 보인다.

 

 

2. TDL4의 배포

 

TDL4에 대한 배포 과정에 대해서 2011년 초에 발표된 ESET 연구원(Eugene Rodionov, Aleksandr Matrosov)의 보고서(The Evolution of TDL: Conquering x64)에서 자세한 내용을 확인할 수 있다. 이 보고서에서는 TDL3의 배포 과정에는 도그마밀리언스(DogmaMillions), TDL4 배포 과정에서는 갱스터벅스(GangstaBucks)라는 사이버 범죄 집단이 연루되어 있다고 언급했다. 이들은 이름만 바꾼 동일한 러시아 마피아로 구성된 범죄조직으로 악성코드와 좀비 PC를 사이버상에서 거래하는 것으로 보고되었다.
 

[그림2] 갱스터벅스의 웹 사이트 메인 화면

 

갱스터벅스 조직 아래에는 수천 개의 하청업체가 존재하며, 실제 배포 과정은 이들을 통해서 이루어진다고 보고 있다. [그림 3]은 악성코드가 설치된 양에 따라 고객에게 지불을 요청하는 안내문이다.

 

[그림 3] 갱스터벅스의 PPI(Pay Per Install) 방식의 대금 결제

 

 3. TDL 4의 특징

 

TDL4에 대한 가장 큰 변화는 윈도우 비스타에 이르러 추가된 x64 감염과 비스타의 커널 모드 보안에 대한 우회 기법이다. TDL3에서 TDL4로 업그레이드시킨 것은 바로 이를 회피하기 위한 것으로 보인다.

TDL4 부트킷 분석에 앞서 이해를 돕기 위해 윈도우 비스타 시스템의 부트 프로세스와 윈도우 비스타 커널 보안에 대해 자세히 살펴보자.

 

[그림 4]는 BIOS를 통한 시스템 부팅 과정과 EFI(Extensible Firmware Initiative)를 통한 시스템 부팅 과정을 하나의 그림으로 표현해 놓은 것이다. 기존의 PC/AT BIOS를 사용하는 부팅은 MBR을 사용하여 부트 파티션을 찾아 해당 bootmgr를 동작시킨다. 그러나, 인텔의 EFI 부팅 과정은 MBR을 통한 %SystemDrive%＼Boot＼PCAT＼bootmgr를 동작시키는 방법 대신 %SystemDrive%＼Boot＼EFI＼bootmgr.efi를 이용하여 부팅한다. 결론적으로 MBR을 감염시키는 TDL4는 EFI를 사용하는 시스템에는 영향을 주지 못하는 것이다.

 

[그림 4] 윈도우 비스타 부트 프로세스 & TDL4 부트킷

 

가. 드라이버 서명 검증(Driver Signing)
마이크로소프트사는 급격히 증가하는 루트킷으로부터 시스템 커널을 보호하기 위해 모든 커널 드라이버(Kernel Driver)는 Class 3 code singing 인증을 받아야 시스템에 로드될 수 있도록 했다. 신뢰된 서명은 오직 마이크로소프트 CA(Certificate Authority)와 베리사인 CA만을 통해서 서명을 받을 수 있다.

x64 시스템은 부팅 시 WINLOAD.EXE와 NTOSKRNL.EXE의 Static Library CI.DLL로부터 다음의 세 가지 함수와 카탈로그 해시파일들(ntpe.cat, nt5.cat, ntph.cat)을 통하여 검증한다. 
① MinCrypL_CheckSignedFile(WINLOAD.EXE & CI.DLL)
② MinCrypL_CheckImageHash(WINLOAD.EXE)
③ MinCryptK_FindPageHashesInCatalog(CI.DLL)

 

나. 커널 코드 패치 검증(PatchGuard)

패치가드(PatchGuard)는 x64 커널코드 변경에 대한 감시를 위해 비스타에 새롭게 추가된 기능이다. 패치가드는 NTOSKRNL.EXE에 포함되어 있으며 주기적(5~10분 간격)으로 커널 메모리의 코드 검사를 진행한다. 드라이버 서명 검증(Driver Signing)과 커널 코드 무결성 검증(Code Integrity)은 BCD 환경변수에 따라 중지가 가능하지만 패치가드는 그렇지 않다.

 

다. 커널 코드 무결성 검증(Code Integrity)

코드 무결성 검증은 NTOSKRNL.EXE의 Static DLL인 CI.DLL에서 이루어지며 CI.DLL는NTOSKRNL.EXE보다 먼저 초기화가 이루어져야 한다. 따라서 CI.DLL이 실행되지 못하거나 문제가 생기면 NTOSKRNL.EXE 또한 실행되지 못하여 부팅이 실패하게 된다.
CI.DLL의 초기화 루틴 PESetInitialState는 카탈로그 캐시파일(%SYSTEM%＼CatRoot＼{F750E6C3-38EE-11D1-85E5-00C04FC295EE}＼bootcat.cache)을 생성한다. 또한 I_PEProcessNotify CallBack을 통하여 새로운 프로세스가 메모리에 적재될 때마다 PsIsProtectedProcess 함수를 통해서 보호 프로세스를 확인하고 I_PEUpdatePEHashBucket 함수를 통해서 보호 프로세스 상태를 저장한다.

 

라. Secure Bootup(TPM Chip)

TPM(Trusted Platform Module) 칩을 컴퓨터 보드에 장착하고 하드디스크의 모든 데이터를 비트로커(BitLocker) 드라이브 암호화하고 TPM에 암호화 정보와 키를 관리하는 것을 말한다. 이를 통해 컴퓨터 자체의 도난에 대해서 안전할 수 있다.

 

마. ＼Device＼PhysicalMemory 디바이스에 대한 접근제한

마이크로소프트사는 윈도우 2003 SP1부터 유저모드(User-Mode) 프로세스에서 ＼Device＼PhysicalMemory를 이용한 시스템 메모리접근을 제한시켜 커널을 보호하고 있다.

 

 

지금까지 윈도우 비스타부터 적용된 커널 보호 메커니즘에 대해서 설명했다. 이제부터는 실제 TDL4 부트킷에 적용된 커널 보호 메커니즘에 대한 우회기법에 대해 살펴보자.

 

[그림 5] TDL4에 감염된 디스크 이미지 구성

 

TDL4는 윈도우 비스타 & 7 시스템 감염을 위해 부트킷 기능이 추가되었다. [그림 4]의 ①은 감염된 MBR을 표시한 것이다.(TDL4 시스템 감염은 다음 호에서 상세하게 다룰 예정이다.) MBR은 디스크의 마지막 두 번째 섹터를 읽어 복호화하여 ldr16의 위치를 얻는다. Ldr16은 Interrupt 13h 핸들러를 후킹하고 정상 MBR을 읽고 실행한다.

 

 
[그림 6] BCD 코드 무결성 체크 무력화

 

Ldr16 코드에서 후킹된 Int 13h 핸들러에서는 디스크 데이터를 읽어 메모리에 적재되는 AH = 42h(Extended Read Sectors From Drive)를 필터링하여 BCD(Boot Configuration Data) ‘16000020’ 문자열과 ‘/MININT’ 문자열을 검색하여 ‘26000022’와 ‘IN/MINT’ 문자열로 각각 변경한다. 이것의 의미는 BCD BcdLibraryBoolean_EmsEnabled(0x16000020) 설정을 BcdOSLoaderBoolean_WinPEMode(0x26000022)로 변경하는 것으로 코드 무결성 검증을 무력화시키는 작용을 하게 된다.

 

[그림 7] 부트 매니저와 부트 로더 설정

 

부트매니저(Bootmgr)는 부트로더(Winload.exe)를 부트로더는 NTOSKRNL.EXE와 Hal.dll을 시스템에 적재하고 윈도우 커널을 생성한다. 이 과정에서 부트로더(Winload.exe)는 디버깅(Debugging) 설정이 되어 있는 경우, 다음과 같이 설정에 맞는 3개의 dll 중 하나를 로드한다.

 

A. Kdcom.dll(Null Modem Cable)
B. Kd1394.dll(IEEE 1394 Cable)
C. Kdusb.dll(USB 2.0 Debug Cable)

 

Int 13h Handler에 의한 후킹의 또 하나의 중요 목적은 바로 Winload.exe에 의해서 메모리에 적재되는 kdcom.dll을 확인하여 [그림 6]의 TDL4 Volume ldr32의 이미지로 교체하는 작업이다. Winload.exe에 의해서 kdcom.dll의 KdDebuggerInitialize1이 호출되게 되어 있기 때문에 교체된 ldr32의 KdDebuggerInitialize1 함수는 PsSetCreateThreadNotifyRoutine CallBack 함수를 등록하여 TDL4 Main Driver인 drv32 또는 drv64 모듈을 로드시킨다. Kdcom.dll이 TDL4의 ldr32로 메모리 패치되기 때문에 후에 NTOSKRNL.EXE의 PatchGuard를 회피하기 위해서 drv32(x64 시스템에서 drv64)를 동작시키고 나서 다시 원본 kdcom.dll으로 메모리 복원이 이루어진다.

 

이번 호에서는 TDL4로 업그레이드된 배경과 윈도우 비스타 보안에 대한 회피 방법과 부트킷 동작 방법에 대해 알아보았다. 다음 호에서는 실제 TDL4의 감염루틴과 새로운 볼륨(Volumn) 구성, 동작 방식, 안티바이러스 회피 방법 등을 상세히 다루어 보도록 하겠다.@