2.1. 분석 대상 개요

확보한 악성코드는 총 6개이며, 감염 체인 구성에 따라 3개 유형으로 구분할 수 있다. 유형별 단계 구성과 각 단계의 역할은 아래 표와 같다.

위 표의 단계 구성은 확보한 악성코드로만 재구성한 것으로, 실제 공격에 사용된 전체 감염 체인과는 차이가 있다. 분석 과정에서 확인되지 않은 항목은 다음과 같다.

1. 각 유형별 유포 경로 및 초기 침투 악성코드

2. TYPE 1 드로퍼 실행 인자

3. TYPE 2 셸코드

4. TYPE 3 ADS 데이터

유형별 특징을 정리한 표는 아래와 같다.

2.2. TYPE 1

해당 유형은 드로퍼, 로더, 백도어로 구성되어 있고 최종 백도어는 COPPERHEDGE 변종으로 확인되었다.

2.2.1. smss.exe - 드로퍼

32비트 Windows MFC 실행 파일로, 내부 프로젝트명은 shayTamir이다. 정상 파일로 보이지만 실행 시 특정 길이의 인자가 전달되면 악성 로직이 실행된다.

caption - 파일 정보

악성 로직 실행 조건

악성코드 실행 시 34자(wide-char)의 인자가 전달되면 악성 로직이 실행된다. 전달된 인자에서 첫 번째와 마지막 글자를 제외한 나머지 글자는 다이얼로그 객체에 저장되며, 이후 오버레이 데이터를 복호화하는 ChaCha20 키로 사용된다.

caption - 인자 파싱 루틴

34자 인자가 전달되지 않으면 악성 로직은 실행되지 않아 정상 프로그램이 실행된 것처럼 보인다.

안티 리버싱 기법

악성코드에는 분석을 방해하기 위한 4가지 기법이 적용되어 있다. 적용된 기법은 아래 표와 같다.

문자열 복호화에 사용되는 ChaCha20 키, IV, Counter 값은 아래와 같다.

• ChaCha20 키(16진수 형태): BC B4 E7 B1 E6 B7 B4 E7 BD B1 B4 B7 B3 B2 E0 E4 B6 E0 BC E7 E4 E7 BC B7 B6 BC B3 B6 B4 BD E0 B2

• ChaCha20 IV: 876543210987

• ChaCha20 Counter: 255

API 이름은 XOR 연산만으로 암호화되어 있으나, 복호화 루틴은 단일 키를 반복하는 형태가 아니다. 복호화에는 아래 세 값을 조합해 한 바이트씩 평문을 구한다.

• 암호화된 이름

• xor 키 테이블

• 데이터 영역의 바이트 데이터

암호화된 이름과 xor 키 테이블은 고정된 값이지만 데이터 영역의 바이트 데이터는 복호화 과정에서 계속 변경된다. 이로 인해 특정 바이트를 복호화하려면 이전 연산이 모두 정확히 수행되어야 한다.

caption - api 이름 복호화 로직

복호화에 사용되는 xor 키 테이블 데이터는 아래와 같다.

• 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 82(16진수 형태)

이 중 06 09 2A 86 48 86 F7 0D 01 01 01은 DER로 인코딩된 rsaEncryption OID의 바이트열과 일치한다. 이는 암호 관련 표준 상수를 본래 용도와 무관하게 사용한 것으로 보인다.

드롭 파일명 생성

드로퍼는 실행될 때마다 서비스로 실행되는 DLL과 백도어의 파일명을 무작위로 생성한다. 파일명이 고정되어 있지 않으므로 파일명 기반 탐지 규칙으로는 식별이 어렵다. 드롭되는 두 파일의 구성은 아래 표와 같다.

파일명 생성 루틴은 2회 호출되며, 각 자리별로 지정된 알파벳 집합에서 문자를 하나씩 무작위로 선택하되 세 글자가 모두 서로 다르도록 제한한다. 자리별 알파벳 집합은 아래와 같다.

• 첫 번째 자리: [abcdefgmnpsw]

• 두 번째 자리: [abcdefhlmnprs]

• 세 번째 자리: [acefghinoprst]

이후 GetTickCount 함수 반환 값의 최하위 비트에 따라 svc 또는 mgr 문자열을 결합하고, 확장자를 붙여 최종 파일명을 완성한다. 이때 동일한 이름의 파일이 이미 존재하는 경우 최대 100회까지 재생성을 시도한다. 분석 과정에서 확인된 파일명은 edgsvc.dll, gsosvc.dat이다. 생성 경로는 C:\Windows\System32이다.

caption - 드롭 파일 생성 로직

하이재킹 대상 서비스 선정

로더 DLL을 svchost.exe가 자동으로 실행하도록 만들기 위해, 새로운 서비스명을 생성하지 않고 netsvcs 그룹에 이름은 등록되어 있으나 실제 서비스 키가 존재하지 않는 빈 슬롯을 찾아 하이재킹 대상으로 삼는다.

먼저 암호화된 레지스트리 경로(HKLM\SOFTWARE\Microsoft\Windows NT\currentVersion\Svchost)를 복호화해 해당 경로의 netsvcs 값에서 서비스 목록을 조회한다. 이후 각 항목에 대해 HKLM\SYSTEM\CurrentControlSet\Services\<서비스명> 키 열기를 시도하고, 열기에 실패한 이름만 수집한다. 마지막으로 수집된 목록에서 rand 함수 반환 값을 이용해 하나를 선택하고 하이재킹한다.

caption - 레지스트리 조회 로직

로더, 백도어 추출 및 드롭

로더와 백도어는 악성코드 오버레이 영역에 암호화 및 압축된 상태로 내장되어 있다.

먼저 악성코드에 존재하는 28바이트 마커 34567890ABCDEFGHIJklmnopqrst를 탐색해 오버레이 위치를 식별한다. 이후 인자로 전달된 데이터를 키로 사용해 28바이트 헤더를 ChaCha20으로 복호화하고, 복호화된 첫 4바이트 값이 나머지 6개 DWORD의 합과 일치하는지 확인하는 체크섬 검사를 한다. 이 검사는 전달된 인자가 올바른 경우에만 통과하므로, 인자 값을 모르면 내장된 로더와 백도어를 추출할 수 없다.

caption - 검증 로직

체크섬 검사를 통과하면 헤더의 오프셋 및 길이 정보를 이용해 데이터 세그먼트 2개를 복호화하고, 각각 C:\Windows\System32 경로에 미리 생성된 파일명으로 저장한다.

caption - 파일 생성 로직

설정 데이터 구성 및 저장

로더는 자신이 복호화해야 할 백도어의 파일명과 복호화 키를 알아야 한다. 이를 위해 두 정보를 레지스트리에 암호화해 기록한다.

4,204 바이트의 설정 블롭을 구성해 생성된 파일명 등의 정보를 기록하고, 이를 ChaCha20으로 암호화해 아래 레지스트리 경로에 REG_BINARY 형식으로 저장한다. 이때 %d 형식 지정자에는 파일명 첫 3글자에서 각각 0x60을 뺀 값을 대입하고, 레지스트리 기록에 성공하면 다이얼로그 플래그를 1로 세팅한다. 확인된 레지스트리 경로는 아래와 같다.

• 레지스트리 경로: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\USB_Keyboard_547

caption - 레지스트리 경로 생성 로직

설정 데이터 구조는 아래 표와 같다.

• 설정 데이터는 다른 감염 사례에서 확인하였다. 레지스트리 값, 로더명, 백도어명이 본 보고서에서 언급되는 것과 다르다.

• 그러나 설정 데이터에 있는 백도어 ChaCha20 키를 이용해 다음 단계 복호화가 가능하였다.

서비스 등록 및 실행

위 과정에서 다이얼로그 플래그가 1이 되면 SCM API를 이용해 서비스를 등록하고 실행한다. 과정은 다음과 같다.

1. CreateServiceW로 서비스를 생성하고, ImagePath는 %SystemRoot%\system32\svchost.exe -k netsvcs로 지정해 공유 프로세스 방식으로 동작하게 한다.

2. ChangeServiceConfig2로 서비스 설명과 복구 옵션을 설정한다. 실패 시 120초 지연 후 자동 재시작하며, 실패 카운터는 24시간 주기로 초기화된다.

3. HKLM\SYSTEM\CurrentControlSet\Services\<선택된 서비스명>\Parameters\ServiceDll 값에 드롭한 DLL 경로를 REG_EXPAND_SZ 형식으로 기록한다.

4. StartService로 서비스를 실행한다.

이로 인해 시스템 부팅 시마다 로더가 자동으로 실행되며, 서비스가 비정상 종료되더라도 복구 설정에 의해 재시작된다.

2.2.2. edgsvc.dll - 로더

edgsvc.dll은 하이재킹된 서비스로 등록되어 실행되는 로더이다. 앞 단계인 드로퍼와 동일하게 API를 실행 시점에 해석해 IAT를 은닉하고, 레지스트리에 저장된 설정 데이터를 복호화해 백도어 파일 경로와 복호화 키를 획득한다. 백도어는 리플렉티브 로딩 방식으로 메모리에서 실행한다.

API 이름 암호화 및 동적 API

API 이름은 xor 연산만으로 암호화되어 있으나, 복호화 루틴은 단일 키를 반복하는 형태가 아니다. 복호화 함수는 분기와 호출 없이 약 8,960개 명령으로 구성되어 있다. 복호화에는 아래 세 값을 조합해 한 바이트씩 평문을 구한다.

• 암호화된 이름

• xor 키 테이블

• 데이터 영역의 바이트 데이터

암호화된 이름과 xor 키 테이블은 고정된 값이지만 데이터 영역의 바이트 데이터는 복호화 과정에서 계속 변경된다. 이로 인해 특정 바이트를 복호화하려면 이전 연산이 모두 정확히 수행되어야 한다.

caption - api 이름 복호화 로직

복호화에 사용되는 xor 키 테이블 데이터는 아래와 같다.

• 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 82(16진수 형태)

이 중 06 09 2A 86 48 86 F7 0D 01 01 01은 DER로 인코딩된 rsaEncryption OID의 바이트열과 일치한다. 이는 암호 관련 표준 상수를 본래 용도와 무관하게 사용한 것으로 보인다.

설정 데이터 조회 및 복호화

먼저 악성코드에 하드코딩된 ChaCha20 키와 IV로 레지스트리 서브키 문자열과 값 이름을 각각 복호화한다. ChaCha20 키와 IV는 드로퍼가 사용하는 것과 동일하다.

• ChaCha20 키(16진수 형태): BC B4 E7 B1 E6 B7 B4 E7 BD B1 B4 B7 B3 B2 E0 E4 B6 E0 BC E7 E4 E7 BC B7 B6 BC B3 B6 B4 BD E0 B2

• ChaCha20 IV: 876543210987

• ChaCha20 Counter: 255

복호화된 서브키 문자열에는 드로퍼와 동일하게 %d 형식 지정자 3개가 포함되어 있으며, 로더 파일명의 첫 3글자에서 0x60을 뺀 값이 대입되면 최종 경로가 완성된다.

• 최종 레지스트리 경로: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\USB_Keyboard_547

레지스트리 경로에서 암호화된 설정 데이터(4,204바이트)를 읽어 ChaCha20으로 복호화한다. 복호화된 설정 데이터에서 추출하는 정보는 아래 2가지이다.

• 백도어 파일명

• 백도어 복호화용 ChaCha20 키

caption - 설정 데이터 복호화 및 추출 로직

로더는 서로 다른 2개의 ChaCha20 키를 사용하고, 획득 경로가 상이하다. 상세 정보는 아래 표와 같다.

백도어 복호화 및 실행

위 과정에서 백도어 파일명과 백도어 복호화용 ChaCha20 키를 추출하였으므로 먼저 C:\Windows\System32 문자열과 백도어 파일명을 결합해 전체 경로를 구성한다. 이후 파일 데이터를 읽어 백도어 복호화용 ChaCha20 키를 이용해 복호화한다. 만약 복호화 과정에서 키 인자가 전달되지 않은 경우 하드코딩된 키를 사용하도록 구현되어 있다. 확인된 복호화 키는 아래와 같다.

• 백도어 복호화용 ChaCha20 키: GX152-6M2V9Z-16KIPG-KAJRE4-PR376

caption - 복호화 키 설정 로직

복호화된 백도어는 파일로 생성되지 않고 자체 구현된 PE로더 로직을 통해 메모리에서 실행된다. 단계는 다음과 같다.

1. MZ 및 PE 시그니처 탐색 및 검증

2. 메모리 할당 이후 헤더와 섹션 데이터 복사

3. 베이스 재배치 및 임포트 테이블 해석

4. 섹션별 메모리 보호 속성 적용

5. TLS 콜백 실행

6. 엔트리포인트 호출

2.2.3. gsosvc.dat - 백도어

로더에 의해 메모리에서 실행되는 백도어로, 해당 백도어는 COPPERHEDGE 변종으로 확인되었다.

동작 모드 조건

DllMain 함수 실행 시 ChaCha20으로 프로세스명 2개(lsass.exe, svchost.exe)를 복호화한 뒤, 현재 프로세스명 및 로드된 DLL명 길이와 비교해 동작 모드를 결정한다. 복호화에 사용되는 ChaCha20 키, IV는 드로퍼 및 로더와 동일하다.

• ChaCha20 키(16진수 형태): BC B4 E7 B1 E6 B7 B4 E7 BD B1 B4 B7 B3 B2 E0 E4 B6 E0 BC E7 E4 E7 BC B7 B6 BC B3 B6 B4 BD E0 B2

• ChaCha20 IV: 876543210987

• ChaCha20 Counter: 255

전체 동작 모드의 동작 조건과 설명은 아래 표와 같다.

모드 1은 악성코드가 SSP(Security Support Provider)로 lsass.exe에 로드된 상태이고 모드 3은 설정 데이터를 %LOCALAPPDATA%\Microsoft\Internet Explorer\brndlog.txt:loginfo ADS에 저장한 형태이다.

모드 값은 프로세스명 매칭 결과로만 1, 2, 4, 5 중 하나로 결정되고 모드 0, 3은 별도의 외부 로더가 컨텍스트(모드 필드, 설정 포인터)를 직접 구성해 실행한 방식에서만 사용된다. 본 보고서에서는 동작 모드가 2 또는 5인 경우에 대해 설명한다.

지속성 확보

위 과정이 완료되면 중복 실행 방지를 위해 뮤텍스를 생성하고 지속성을 확보한다. 뮤텍스명은 아래와 같다.

• 뮤텍스명: MsSecurityObj

caption - 뮤텍스 설정 로직

지속성은 SSP 등록을 통해 확보한다. HKLM\SYSTEM\CurrentControlSet\Control\Lsa경로의 Security Packages 값에 로더 파일명을 추가하고, 이때 System32 경로의 reg.exe를 이용해 기존 Security Packages 값을 읽어 기존 항목을 64자 단위로 그대로 보존한 채 로더 파일명만 목록에 추가해 REG_MULTI_SZ 값을 재구성한다. 이후 시스템 부팅 시 lsass.exe가 SSP로 등록된 DLL을 자동으로 로드한다.

caption - 레지스트리 값 작성 로직

자가 보호 루틴

모드 1, 2, 4, 5에서는 초기화 과정에서 자가 보호 루틴이 실행된다. 먼저 설정 데이터가 담긴 레지스트리 값을 삭제하고, 로더와 백도어 데이터를 각각 메모리에서 읽은 뒤 로더와 백도어를 삭제한다. 이후 콘솔 컨트롤 핸들러를 등록해, 시스템 종료 이벤트 발생 시 메모리에 저장 중인 로더와 백도어 그리고 설정 데이터가 복원되도록 설정한다.

caption - 메모리 저

설정 데이터는 이미 메모리에 존재하므로 따로 읽지는 않는다. 또한 복원 시 로더는 파일 데이터에 64MiB ~ 80MiB 정크 데이터가 추가된 상태로 복원된다. 설정 파일은 기존 레지스트리 경로에 복원된 후 SSP를 재등록한다.

시스템 정보 수집

컴퓨터명, 사용자명, 네트워크 어댑터의 IPv4 주소, OS 제품명, ANSI 코드 페이지를 수집한다. 또한 현재 동작 모드도 수집하며 컴퓨터명과 CPU 모델명을 결합한 데이터의 CRC32 값을 시스템 식별 값으로 생성한다. 이후 자신의 실행 경로를 획득해 해당 디렉토리를 작업 디렉토리로 설정한다.

caption - 시스템 정보 수집 로직

C&C 서버 통신

설정 데이터에 포함된 C&C 서버 URL에 대해 요청을 전송한다. 확인된 C&C 서버 URL은 총 3개로 모두 국내 서버이다.

• hxxps://f*****.com/include/security.asp

• hxxp://1*****.2/default.php

• hxxp://1*****.7/default.php

C&C 서버 SSL 적용 여부에 따라 통신 시 사용하는 파라미터 구성이 상이하다.

• SSL: hash=<1000~9999 랜덤>&lang=T3F56E5UJH0JC3D4&ei=<50~255 랜덤>&ie=<통신 데이터>

• Non-SSL: hash=<1000~9999 랜덤>&lang=T3F56E5UJH0JC3D4&oq=<통신 데이터>

통신 데이터는 12바이트 헤더와 가변 길이 페이로드로 구성되며, 헤더 구조는 아래 표와 같다.

통신 데이터와 헤더는 각각 ChaCha20 및 XOR로 암호화된 후 Base64로 인코딩되어 URL 파라미터에 연결된다. 첫 통신 시 C&C 서버의 응답이 전송한 hash 파라미터 값과 일치하는지 검증하며, 불일치할 경우 연결을 종료한다.

caption - 응답 데이터 검증 로직

명령 수신 루프는 먼저 hash=<기존 hash 파라미터 값+10000> 값과 명령 ID 0x2047로 폴링 요청을 전송한다. 이후 기존 hash 파라미터 값과 함께 C&C의 명령 데이터를 수신하면 명령 ID에 따라 핸들러를 호출하며, 명령 실행 결과를 기존 hash 파라미터 값과 함께 전송한 후 다시 <기존 hash 파라미터 값+10000> 값으로 폴링한다.

확인된 명령 코드는 총 30개로 상세 동작은 “부록 C. 명령 코드” 참고 바란다.

추가 모듈 로드 및 인젝션

실행 중 반복적으로 설정 데이터에 저장된 2개의 PNG 파일 경로에서 은닉된 추가 모듈 데이터를 읽어와 복호화한 뒤 explorer.exe에 인젝션해 실행한다. 다만 분석된 설정 데이터에는 PNG 파일 경로가 기록되어 있지 않았다.

복호화 과정은 다음과 같다.

1. 각 32바이트 블록에 대해 i = 31부터 0까지 역순으로 순회하며, key[i] 값을 12로 나눈 나머지가 0이 아닌 경우에만 아래를 수행한다.

2. 교환 위치 j = (key[i] % 12 + i) % 32를 산출한 뒤, block[i]와 block[j]를 교환한다.

3. 교환 후 block[i](원래 block[j]에 있던 값)를 key[i]와 XOR한다.

복호화에 사용되는 키는 설정 데이터(+0x100C)에 각 바이트가 0xBD와 XOR된 형태로 저장되어 있으며, 이를 XOR해 원본 키를 복원한다. 원본 복호화 키는 아래와 같다.

• 원본 복호화 키(16진수 형태): BD BD 11 9E BD BD BD BD CD 9E BD BD BD BD C5 9E 85 62 82 C1 BB BD BD BD BD BD AD C1 05 62 F0 3F

2.3. TYPE 2

해당 유형은 로더, 다운로더, 셸코드로 구성되어 있으나 셸코드는 확보하지 못하였다.

2.3.1. rasgreeng.dll - 로더

해당 로더에는 ES-Computing의 유효하지 않은 인증서로 서명이 적용되어 있다.

레지스트리 조회 및 복호화

특정 레지스트리 경로에 존재하는 다운로더와 설정 데이터를 읽어 복호화한다. 레지스트리 경로는 평문으로 존재하고, 각 레지스트리 경로에 대한 설명은 아래 표와 같다.

암호화된 다운로더 데이터는 AES-CBC-128로 복호화한다. 복호화에 사용되는 키와 IV는 아래와 같다.

• AES 키: g2Oc6qWRU3n.B0Pm

• AES IV(16진수 형태): 00000000000000000000000000000000

caption - 레지스트리 조회 및 복호화 로직

암호화된 설정 데이터는 로더에서 복호화하지 않고 다음 단계인 다운로더에서 복호화한다.

다운로더 실행 및 인자 전달

복호화된 다운로더를 메모리에서 실행하는데, 이때 다운로더의 DllMain 함수를 호출하면서 AES 키와 암호화된 설정 데이터를 인자로 전달한다.

caption - 메모리 실행 로직

2.3.2. bold.dll - 다운로더

네임드 파이프 생성

DllMain 함수가 호출되면 네임드 파이프를 생성한다. 이때 파이프 이름은 다음 단계를 통해 생성된다.

1. D9hWnVEqdgzJ673B8euS 문자열에서 무작위 인덱스 문자 2개를 골라 서로 위치를 교환한다.

2. 위 과정을 201회 반복한다.

3. \\.\pipe\<셔플 결과 문자열> 형식으로 최종 이름을 조합한다.

caption - 파이프 생성 로직

C&C 서버 통신

인자로 전달받은 암호화된 설정 데이터를 함께 전달된 AES 키로 복호화해 C&C 서버 URL을 추출한다. 확인된 C&C 서버 URL은 아래와 같다.

• hxxps://d*****.com/lgdacom_mobile/lgdacom.asp

• hxxps://www.l*****.co.kr/lib/asp/include_view.asp

통신을 시도하기 전에 각 C&C 서버 URL별로 실제 통신 가능 여부를 먼저 확인한다. 먼저 봇 ID를 4바이트 rand 함수 반환 값으로 생성한 뒤 type=<봇 ID(hex)>&data=8Rvi4-UPMQvFgjMJ3cZF 형식으로 파라미터를 구성해 POST 요청을 전송하고, 응답이 <!DOCTYPE html>로 시작하는지 확인해 활성 여부를 판단한다.

caption - 통신 가능 여부 확인 로직

활성으로 확인되면 데이터를 수신한다. 이때 type=cisco 형식으로 POST 요청을 전송해 C&C 서버로부터 데이터를 수신한다. 응답 데이터의 앞 15바이트가

<!DOCTYPE html>

로 시작하면 나머지 데이터를 복호화한다. 복호화는 응답 데이터의 공백 문자를 +로 치환하고 Base64로 디코딩한다. 이후 AES-CBC-128로 복호화한다.

caption - 응답 데이터 복호화 로직

복호화된 데이터는 10바이트 헤더와 실제 데이터로 구성되며, 헤더 구조는 아래 표와 같다.

이때 수신한 명령 코드가 60(0x3C) 이하이면 오프셋 10부터의 데이터를 셸코드 실행 함수로 전달한다. 셸코드 실행 시에는 파이프 이름, 복호화된 설정 데이터, 다운로더의 상태 정보 등을 함께 전달한다. 셸코드 실행을 마친 뒤, 방금 실행한 명령 코드가 19(0x13)이고 실행 결과가 0이면 통신 루프를 정상 종료한다. 추가로 크기가 큰 셸코드의 경우 헤더의 종료 플래그가 설정되고 누적 수신량이 전체 크기에 도달할 때까지 type=cisco 요청을 반복해 분할 수신한다.

수신한 명령 코드가 60(0x3C)을 초과하는 경우에는 셸코드를 실행하지 않고, 명령 코드 24(0x18)와 플래그 1로 확인 응답만 전송한 뒤 다음 명령을 대기한다.

caption - 셸코드 실행 로직

파이프 데이터 송신

네임드 파이프 스레드는 메인 C&C 통신 루틴과 별도의 스레드로 생성되어, 파이프를 통해 전달되는 데이터를 C&C 서버로 전송한다. 데이터 앞 10바이트에 수신 시와 동일한 구조의 헤더를 추가하고, 수신 데이터 복호화에 사용한 것과 동일한 키로 AES-CBC-128 암호화를 한다. 최종적으로 암호화된 데이터를 Base64로 인코딩해 type=article&data=<인코딩된 데이터> 형식으로 POST 요청을 전송한다.

caption - 파이프 데이터 송신 로직

C&C 서버에서 다운로드하는 셸코드는 확보하지 못해 이후 과정은 분석할 수 없었다.

2.4. TYPE 3

2.4.1. ipbootp.dll - 로더

해당 로더는 자기 자신의 ADS에 저장된 암호화된 DLL을 복호화해 메모리에서 실행한다.

API 이름 암호화 및 동적 API

API 이름은 AES-CBC-128로 암호화되어 있다. 복호화에 사용되는 키와 IV는 하드코딩되어 존재한다.

• AES 키(16진수 형태): CE F6 E7 9D D1 F2 C6 1B 5F 26 5D A1 7D 73 A2 15

• AES IV(16진수 형태): CD 85 ED 5E 75 20 CB 3F 98 3E 6B 7F DA 53 71 1D

ADS 페이로드 추출 및 실행

ADS 관련 문자열도 AES-CBC-128로 복호화된다. ADS 관련 문자열은 아래와 같다.

• :dat, :kgb

자기 자신의 ADS에서 암호화된 페이로드와 복호화 키를 추출한다. 각 ADS 경로는 아래 표와 같다.

:kgb의 첫 16바이트가 AES 키이고 다음 16바이트가 IV이다. 이후 AES-CBC-128로 암호화된 페이로드를 복호화한다. 복호화된 페이로드는 파일로 생성되지 않고 자체 구현된 PE로더 로직을 통해 메모리에서 실행된다. 단계는 다음과 같다.

1. MZ 및 PE 시그니처 탐색 및 검증

2. 메모리 할당 이후 헤더와 섹션 데이터 복사

3. 베이스 재배치 및 임포트 테이블 해석

4. 섹션별 메모리 보호 속성 적용

5. TLS 콜백 실행

6. 엔트리포인트 호출

ADS는 확보하지 못해 이후 과정은 분석할 수 없었다.