라자루스 루트킷 악성코드 분석 보고서(1/2)

#라자루스 #루트킷 #악성코드 #커널

본 게시글은 안랩 시큐리티대응센터(ASEC) 에서 2022. 09. 22. 자로 발간한 라자루스 공격 그룹의 BYOVD를 활용한 루트킷 악성코드 분석 보고서 의 내용에 대해 개인적으로 정리한 게시글입니다.

---

악성코드 관련 게시글들을 보다가 본의아니게 위에 기재한 악성코드 분석 보고서를 보게되어 공부 용도로 게시글을 작성해본다. 무엇보다 내 이목을 끌었던 것은 악성코드가 취약한 드라이버를 이용하여 커널단까지 조작하는 부분이었는데, 악성코드 분석 초보로써 굉장히 특이하다고 생각되었기에 세심하게 읽어보았다.

원본 보고서를 보면 거의 40장에 육박하는 매우 긴 분량이기 때문에 상세 내용을 나누어 서술해보겠다.

이번 게시글은 핵심 루트킷 파일이 작동하기 직전까지의 과정을 서술하는데에 초점을 두려고 한다.

1. 요약

• 악성코드는 취약한 드라이버 커널 모듈을 악용하여 커널 메모리에 대한 읽기, 쓰기 행위를 할 수 있음.
• 이러한 행위를 통해 백신(Anti Virus) 및 PC 모니터링 시스템도 무력화 가능함.
• 안랩에서는 보고서에서 이를 BYOVD(Bring Your Own Vulnerable Driver) 기법이라 지칭

---

2. 특징

2-(1). 공격 특징 정리

• 최신 윈도우들은 서명되지 않은 드라이버 로딩이 원초적으로 불가함(Win 10, Win 11, etc...)
• 그러나 당연하게도 합법적으로 서명된 하드웨어 공급업체의 드라이버 모듈은 로드할 수 있음.
• 이러한 점을 역이용하여 취약한 공급업체의 드라이버 모듈로 커널 메모리를 조작함.
• 커널 관련 전역 데이터 수정을 통해 AV 를 포함한 시스템 내 모든 모니터링 프로그램을 무력화 시켰음.

2-(2). WinIO of ENE Technology

• 이번 사례에서 사용된 드라이버 모듈은 ENE Technology 에서 제작한 하드웨어 관련 모듈임.
• 1999 년 Yariv Kaplan 의 WinIO 라는 오픈소스 라이브러리를 그대로 가져와 기반 모듈로 사용함.
• 더하여, 모듈을 호출하는 프로세스에 대한 검증 조건도 취약하다는 점을 노렸음.

---

3. ene.sys 분석 ( 초기 침투 기반 마련 단계 / 취약한 드라이버 모듈 )

이 부분에서는 ene.sys 드라이버에 대한 전반적 기능 및 취약성에 대해 정리한다.

3-(1). 물리 메모리 매핑 기능

• ENE Technology 에서 제작한 ene.sys 드라이버 모듈은 위에서 언급한 WinIO 오픈소스 라이브러리 기반으로 작성됨.
• 유저 영역에서 -> 커널 물리메모리 및 커널 IO 포트 까지 직접접근을 할 수 있도록 돕는 역할을 맡고있음.
• 물리 메모리 매핑 방식 : ZwMapViewOfSection 함수를 통한 공유 메모리 매핑 방식

(공유 메모리 매핑에 대해서는 추후 게시글 작성)

• 유저 영역의 프로세스는 IOCTL 함수 통신을 통해 커널 영역의 물리 메모리를 매핑할 수 있게 되고, 이는 유저 영역에서 임의의 커널 물리 메모리 영역을 조작할 수 있다는 의미
• 직접적인 물리 메모리 매핑은 드라이버의 기능에 따라 필요할 수도, 없을 수도 있음.
• 그러나 악용되면 큰 위협요소가 되므로 호출하는 프로세스에 대한 검증 작업이 철저히 이루어져야함은 자명하다. => (그러나.. ene.sys 는...)

3-(2). 호출 프로세스 및 유효 데이터 검증 로직

3-(2)-[1]. SB_SMBUS_SDK.dll 모듈 로드 검증

• ene.sys 드라이버 실행 시점에 "PsSetLoadImageNotifyRoutine" 함수를 호출하여 모듈 처리와 관련된 콜백 루틴 을 커널단에 등록함.
• 요 콜백루틴이라는게 프로세스가 모듈을 로드할 때마다 실행되는데, ene.sys 의 경우는 아래와 같다.
• 프로세스가 로드하는 모듈이 SB_SMBUS_SDK.dll 인지 확인하고, 맞다면 해당 프로세스를 무한 신뢰할 수 있는 놈이라고 인지하여 PID 정보 를 ene.sys 전역변수에 저장한다.
• 결과적으로 신뢰할 수 있는 프로세스가 되었기 때문에, 프로세스 <-> ene.sys 드라이버 간의 IOCTL 통신을 할 수 있게 되는 것이다.

3-(2)-[2]. AES 암호화가 이용된 IOCTL 통신 및 호출시간 검증

• 유저 영역의 프로세스가 ene.sys 에 대한 물리 메모리 매핑을 요청하기 위해서는 특정 IOCTL 값(0x80102040) 과 _WINIO_PHYSICAL_MEMORY_INFO_EX 구조체 정보를 같이 넘겨서 검증을 받아야 한다.

typedef struct _WINIO_PHYSICAL_MEMORY_INFO_EX {
    // 중략
    ULONG_PTR BusAddress; // 매핑을 원하는 물리 메모리 주소
    // 중략
    PVOID BaseAddress; // 얻어온 물리메모리 Section 주소
    UCHAR EncryptedKey[16]; // 현재 시간 AES-ECB 모드로 암호화 한 값
} WINIO_PHYSICAL_MEMORY_INFO_EX, *PWINIO_PHYSICAL_MEMORY_INFO_EX;

• 검증은 위 구조체에서 EncryptedKey 를 이용해서 한다.
• (1) IOCTL 호출 시점의 시각(EncryptedKey_before)
• (2) IOCTL 값을 드라이버로부터 전달받아 처리한 시각(EncryptedKey_after)
• 위의 (1) 과 (2) 의 차이가 2ms 미만일 경우 유효한 프로세스라고 인지하게 됨.

3-(3). ene.sys 취약성 정리

• ene.sys 드라이버는 유저 영역에서 물리 메모리 영역 매핑을 자유자재로 할 수 있는 취약성이 존재한다.(매핑 자유, 검증 취약)
• 라자루스 사례에서는 MSI 의 RGB 램 모듈을 제어하는 모듈로써 다운받아지도록 위장 후, 악성코드가 배포되고있음을 확인하였다고 함.

---

4. 루트킷 악성코드 분석( 루트킷 본체를 이용한 침투 사전 준비 단계 )

• 공격에 관여되는 내용이 복잡해서 대강 모식도로 표현해보았다. 이 그림에 의거하여 진행하면 되겠다.
• 그림을 보면 "루트킷 로더" 라는 놈이 최초 시작점으로 볼 수 있다. "루트킷 본체" 는 루트킷 로더 프로세스 안에서 DLL 형태로 동작중인 상황.
• 루트킷 로더는 ene.sys 드라이버를 시스템 드라이브 경로에 생성 하고, 특수한 과정 활용하여 즉시 로드한다. 그리고 위에서 상술한 드라이버 취약성을 이용ㅎ아여 커널 메모리 영역의 특정 주소 값 을 수정하게 된다.

4-(1). What is "Previous Mode"?

• 커널 메모리 특정 주소 값은 바로 루트킷 스레드의 PreviousMode 라는 것인데, 이게 뭐냐면.

유저영역에서 동작하는 프로세스가 Nt 또는 Zw 계열의 함수를 실행하면, zW 계열의 함수는 같은 동작을 하는 Nt 계열 함수로 포인팅하고, 해당 Nt 함수는 내부적으로 나를 호출한 놈이 유저모드를 통해 온 놈인지 아니면 커널모드를 통해 온 놈인지 파악을 하게 된다.

만약 유저모드를 통해 온 놈이면 앞으로의 로직은 유저영역의 메모리를 사용하는 것이고, 커널 모드를 통해 온 놈이면 앞으로의 로직에서 유저영역 메모리 + 커널 메모리까지 같이 사용가능하도록 허가해준다는 것이다.

그리고 그에 대한 판단(유저모드 or 커널모드)을 PreviousMode 라는 필드 값으로 결정짓는 것이다. 0 은 God Mode 로, 커널과 유저 둘다 자유자재로 사용가능하다.

• 결론적으로 루트킷 본체가 커널 메모리에서 자유롭게 날뛸 수 있도록 ene.sys 가 기반마련을 하는 것이다.
• 관련 참고 내용은 링크1 링크2 첨부드립니다.

4-(2). ene.sys 드라이버 로드 상세 과정

• 드라이버 내용이 좀 길게 늘어지는데, 보고서에서도 상세하게 다루는 부분이다.
• umpass 라는 윈도우 서비스 드라이버를 타겟으로 일단 삼는다.
• umpass 에 대한 레지스트리 정보 중에서, 실제 umpass 드라이버가 존재하는 경로를 ene.sys 경로로 바꿔치기한다.

Registry PATH : HKLM\SYSTEM\ControlSet001\Services\UmPass

Before : \SystemRoot\System32\drivers\umpass.sys

After : \SystemRoot\System32\drivers\umpassmgr.sys

• 그 후에, 위 레지스트리 경로를 인자로 삼아, NtLoadDriver 함수를 호출하여 ene.sys 드라이버 모듈을 구동한다.
• 루트킷 변형에 따라 CVE-2021-21551 LPE 취약점을 사용한 것도 있다고 전해진다.

4-(3). 루트킷 본체의 행위

• DLL 의 이름은 FudModule.dll
• 루트킷은 Vmprotect 로 실행 압축 되어있었다고 한다. => 안랩은 이걸 정적으로 풀 수 있었나? 아니면 동적으로 정상코드가 적재된 상태를 덤프한건가..? 어케 복구한건지 궁금함
• 루트킷 본체는 DLL 로써 당연히 export 하는 함수가 존재하고 루트킷 로더가 이걸 활용하는데, 대표적으로 Create, Close 라는 함수가 있다.

<Close 함수>

• NtQueryVirtualMemory 함수를 통해 루트킷이 로드된 메모리 영역에 대한 아래와 같은 검증을 수행함.

• DLL 베이스 주소 & 0x20000 == 0 인가? => DLL이 페이징 파일에 매핑되어있는지 검증 => set 상태이면, 다른 프로세스와 메모리를 공유하지 않음.
• DLL 베이스 주소 & 0x1000000 == 0 => DLL이 이미지 파일에 매핑되어있는가? => set 상태이면, 다른 프로세스와 메모리 공유.
• 보통 악성코드는 MEM_PRIVATE 이거나 MEM_IMAGE 특성을 띄는 경우가 많다.
• Close 함수의 다른 활동으로는 NtCurrentTeb 함수로 PEB 에 대한 정보를 얻어와서 OSBuildNumber 가 Win 10 RS3 이하인지 확인함. => 이 부분은 후술하여 상세설명하겠다.

<Create 함수>

• 핵심 기능은 ene.sys 드라이버 생성 및 서비스 실행, 보안제품 무력화... 등이다. 장황하게 설명할 곳은 아닌듯.

<Close 함수의 OS 버전 확인>

• OS 버전 확인은 OS 마다 서로 다른 커널 오프셋 정보를 정확히 얻어내어 PreviousMode 필드와 같은 값을 정확히 수정하기 위함에 그 목적이 존재한다. 굉장히 치밀하다...
• OS 마다 다른 경우의 예로는, 커널 모드로만 접근 가능한 ETHREAD 객체의 PreviousMode 필드는 아래와 같이 오프셋이 달라진다는 경우가 있을 수 있다.

Win7(7601) PreviousMode => ETHREAD + 0x1F6
Win10(1809) PreviousMode ⇒ ETHREAD + 0x232

4-(4). Kernel DTB(Directory Table Base) 주소 획득

• 루트킷은 지금까지는 임의의 커널 메모리에 대한 물리 메모리 매핑 방식을 통해 R/W 권한을 획득하였다.
• 최종적으로는 ETHREAD 객체의 PreviousMode 필드의 물리메모리 주소까지 구해내야한다.
• NtQuerySystemInformation 함수에 SystemExtendedHandleInformation 을 인자로 전달하면, 프로세스 내의 핸들 정보들을 얻을 수 있고 루트킷은 이를 통해 핸들이 커널 메모리 어디에 존재하는지 파악 후, ETHREAD 객체의 PreviousMode 가상 주소까지 획득하였다.
• 또한 System 프로세스의 DirBase 값을 찾아서 직접 친히 Kernel DTB 주소를 획득하는 코드를 구현하였다.

4-(5). 가상 주소에서 물리 주소로 변환하는 과정

• 루트킷이 시스템 프로세스의 Kernel DTB(CR3 register) 주소를 획득.
• DTB 에는 가상 주소에서 물리 주소로 바꾸기 위한 기준(디렉터리 페이지 베이스) 이 들어있다.
• 자세한 과정은 아래 그림 참고

(물리주소 변환 과정은 추후 게시글 작성)

---

다음 내용은 추후에...

여기까지가 바로 직접적인 AV 무력화, 침투 공격 등을 위한 사전기반 마련 과정이었다.

APT 공격이었던 만큼 라자루스의 치밀함과 섬세함이 느껴지는 것 같아서.. 나도 기빨린다.

얼른 다음 내용도 써야겠다.