Experiment on overwritten data location from a victim

3.20 대란이라고 일컫을 만큼 파괴력이 강한 악성코드가 금융기관과 방송매체를 강타했다.

많은 전문가와 전문기관에서 이미 악성코드에 관한 분석 레포트를 내놓고 있지만, 정작 어느정도의 피해를 하드디스크에 가했는지에 대한 내용은 없는 것 같아 간단히 포스팅한다. 매우 간단한 실험이지만 데이터 복구에 도움이 되지 않을까 생각한다.

This posting deals with simple analysis on the location of overwritten area for exploited machine. I hope this could be helpful to preform recovery process.

* 단계 (Steps)

(1) VMware 가상 이미지 할당 (10기가), 단일 volume
(2) Windows XP SP3 설치
(3) 감염직전 Snapshot 확보
(4) 감염후 자동종료
(5) 개별 이미지 변환
(6) 두 이미지 바이너리 비교분석

(1) Creates virtual image with the size of 10GB virtual disk (VMware)
(2) Installs Windows XP SP3
(3) Takes a snapshot before malware infection
(4) Takes un-bootable image after infection
(5) Converts each image to raw one.
(6) Compares two binaries

* 결과 (Results)

(1) 바이너리 비교 시간 때문에 우선 첫 100MB를 비교해 본 결과 덮어쓴 영역이 일정 간격으로 되풀이되고 있었다.
신기하게도 그 간격은 처음부터 0x330D9FFF (816MB)까지는 0x1BD000 (1,780KB)와 0x3F6000 (4,056KB)이 번갈아  가면서 덮어쓰고 있었고 0xFFFFFFFF (4GB)까지는 이 둘을 합한 0x5B3000 (5,836KB)마다 한 번씩 나타났다.  길이는 정확히 0x19000(100KB)를 유지하고 있었다. 하지만 4GB 이후 영역부터 마지막까지는 모두 합쳐 10회 이하로 나타났고 길이도 이보다 짧게 나타났다.

Looking into the first 100MB due to time-consuming comparison, I found there is a constant distance to the next overwritten area. The periodic distance is 0x1BD000(1,780KB) and 0x3F6000(4,056KB) from the  first address to 0x330D9FFF(816MB) but 0x5B3000(5,836KB) in betwen the address 0x5B3000 and
0xffffffff(4GB). The length of repetitive strings “PRINCIPPES” maintains 0x19000(100KB) to be exact.
After that address, the string has seen less than 10 times with shorter length.

 

The table shows periodic distance is 0x1BD000(1,780KB) and 0x3F6000(4,056KB) in the address range of 0x00000000 ~ 0x330D9FFF (816MB)

 

The table shows periodic distance is 0x5B3000(5,836KB) in the address range of 0x330DA000 ~ 0xFFFFFFFF (4GB)

(2) 악성코드(MD5: 9263E40D9823AECF9388B64DE34EAE54)는 맨 처음 MBR 영역을 “PRINCIPPES”로 덮어쓴다.  다른 문자열도 존재하나 이번 실험에서는 HITA..는 한 번도 나오지 않았다. MBR 바로 다음은 주소 0x7000에 있는 VBR 영역이다.
The malware(MD5: 9263E40D9823AECF9388B64DE34EAE54) overwrote MBR area with strings “PRINCIPPES”

It did only 480 bytes, while MBR accounted for 512 bytes. Then the first VBR(Volume boot record)
was overwritten,  where is normally located in 0x7000. No area overwritten with “HITA..” was shown.

Destructed MBR
Destructed data

 

Microsoft Volume Licence with KMS

마이크로소프트는 Vista 버전부터 기관에서 복수 사용자를 인증하는 볼륨 라이선스를 MAK(Multiple Activation Keys) 이나 KMS(Key Management Server) 방식으로 제공한다. KMS를 통한 방식은 키 관리 서버와 주기적으로 통신하며 180일마다 재확인 절차를 거친다. 다만 MAK으로 인증한 제품의 경우 KMS로 재인증을 수행하지 않는다. 상세한 내용은 아래 링크를 참조하자.

http://en.wikipedia.org/wiki/Volume_license_key
http://www.microsoft.com/Licensing/existing-customers/product-activation.aspx

오피스 2010 버전 정품을 KMS 방식으로 인증하는 방식을 한 번 지켜봤다.

1. 참조 파일과 레지스트리 위치 (Files and Registry keys for KMS)

키 인증에 관련된 파일은 아래 디렉토리와 레지스트리를 참조한다.
The key management refers to the directory and the registry location below.

C:\Program Files\Common Files\Microsoft Shared\OfficeSoftwareProtectionPlatform
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OfficeSoftwareProtectionPlatform

2. 절차 (Procedures)

(1) 먼저 아래 디렉토리의 vbs를 수행하여 key server를 설정해 준다.
First of all, key server should be identified by executing vbs in the directory below.

C:\Program Files\Microsoft Office\Office14>cscript ospp.vbs /sethst:[key.management.server]

위 서버는 아래 registry 위치에 저장된다. 세션ID 또한 존재하는 것으로 보아 일정기간 동안 유효한 것으로 보인다.
The key server value is stored in the specific registry location as follow. There is a ServiceSessionId, which makes using product valid.

HKLM\SOFTWARE\Microsoft\OfficeSoftwareProtectionPlatform\KeyManagementServiceName
HKLM\SOFTWARE\Microsoft\OfficeSoftwareProtectionPlatform\ServiceSessionId

MS Office 2010이 사용하는 모듈 ID와 레지스트리 디렉토리는 다음과 같다. 해당 모듈을 찾을 수 있다면 MS Office 2010 사용자이거나 사용했던 적이 있다고 판단할 수 있다.
The moduleID and its identifying location might inform investigators that the user has been used MS Office 2010.

moduleID: ba38975c-7786-44bc-b924-147c77920328
HKLM\SOFTWARE\Microsoft\OfficeSoftwareProtectionPlatform\Plugins\Modules\ba38975c-7786-44bc-b924-147c77920328

(2) 아래 명령어를 통해 서버로부터 key를 activation한다. 아래 결과는 일부를 변조한 것이다.
The script activates the key from the KMS server. Note that the result has been altered for security reasons.

C:\Program Files\Microsoft Office\Office14>cscript ospp.vbs /act
Microsoft (R) Windows Script Host 버전 5.7
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

—Processing————————–
—————————————
Installed product key detected – attempting to activate the following product:
*** ID: ****7360-8c5f-417c-9d61-816******e0c
LICENSE NAME: Office 14, OfficeProPlus-KMS_Client edition
LICENSE DESCRIPTION: Office 14, VOLUME_KMSCLIENT channel
Last 5 characters of installed product key: J3AT1
<Product activation successful>
—————————————
—————————————
—Exiting—————————–

3. 흔적 (The artifacts)

해당 스크립트가 실행되는 동안 시스템의 변화를 살펴봤다.

(1) 이벤트뷰어 (Event viewer)에서 다음과 같은 정보를 확인할 수 있었다.
하나는 클라이언트에서 활성화 요청을 하고 다른 하나는 서버에서 활성과 결과를 보여준다.
The event viewer recorded an activation results: one for request from client, and the other for response from KMS.

The client has sent an activation request to the key management service machine.
Info:
0x00000000, 0x00000000, key.management.server:1688, …….-b604-4b8c-9a48-99d4348fcf37, 2012/12/04 07:06, 0, 2, 972, 6f345b60-8a5c-427c-….-836a982589dc, 5

The client has processed an activation response from the key management service machine.
Info:
0x00000000, 0x00000000, 1, 0, 10, 120, 10080, 2012/12/04 07:06

KMS 서버는 주로 1688 포트를 사용하고 있으며, 외부에서 접근할 수 있도록 설정되어 있을 경우 어떻게 될까 궁금해서 시도해 봤으나 포트가 닫힌 탓인지 product key가 맞지 않아 아래 에러 코드와 함께 불가했다.
The KMS server use port 1688/tcp. I gave a try to switch a different server, but failed for some reasons with errors.

ERROR CODE: 0xC004F074
ERROR DESCRIPTION: The Software Licensing Service reported that the computer cou
ld not be activated. No Key Management Service (KMS) could be contacted. Please
see the Application Event Log for additional information.
To view the activation event history run: cscript ospp.vbs /dhistorykms

수 분 후 활성화가 완료되면 아래와 같이 상태 체크를 하게 된다.
In several minutes, the service checked the licensing status.

The Software Protection service has completed licensing status check.
Application Id=59a52881-a989-479d-af46-f275c6370663
Licensing Status=
1: 191301d3-..-..-b0c7-d7..9e3, 1, 0 [(0 [0xC004F014, 0, 0], [(?)(?)(?)(?)(?)(?)])(1 )(2 )]
2: 6f327760-..-..-9b61-83..70c, 1, 1 [(0 [0x00000000, 1, 0], [(?)(?)( 1 0x00000000 30 0 msft:rm/algorithm/volume/1.0 0x00000000 259192)(?)(?)(?)])(1 )(2 )]
3: fdf3ecb9-b56f-43b2-a9b8-1b48b6bae1a7, 1, 0 [(0 [0xC004F014, 0, 0], [(?)(?)(?)(?)(?)(?)])(1 )(2 )]

Application 이벤트 ID 1003를 MS에서 직접 조회해 보았으나 예상대로 별 내용을 알려주지 않는다.
The Microsoft does not give any information details about application event ID 1003, as expected.

 

(2) 네트워크 패킷 (network packets)은 요청시 260 바이트, 응답시 176 바이트의 stub 데이터를 포함하는데 아마 activation에 필요한 최소한의 데이터만 주고받는 것으로 보인다.  The network packets containing stub data for key activation was observed: 260 bytes for request and 176 bytes for response.

(3) 시스템 변경사항 (system alteration) :스크립트 실행 당시 파일을 추적해 본 결과 흥미롭게도 C:\WINDOWS\AppPatch\sysmain.sdb라는 파일 접근, 오픈 등 40여 차례의 오퍼레이션이 일어났으나 어떤 작업인지는 알아낼 수 없었다. 키관리 서버에서 세션키를 수립하면 레지스트리 아래 위치에 저장되는 것으로 보인다.
While executing the cscript, the operation was found to access and/or open the file, C:\WINDOWS\AppPatch\sysmain.sdb. The session key seems to be stored in particular registry location.
HKLM\SOFTWARE\Microsoft\OfficeSoftwareProtectionPlatform\Plugins\Modules\ba38975c-7786-44bc-b924-147c77920328

Demystifying Registry (1)

Windows 환경에서 수많은 정보의 보고인 Registry를 하나씩 살펴보자.

1. dd를 이용한 HDD 덤프 (Dumping HDD with dd)

집에 있던 무척 오래된 8GB짜리 고물 하드디스크가 있길래 덤프해 봤다.
I dumped the image of old hard drive with the size of 8GB at home.

D:\Tools\Digital Forensic\Dump\fau\FAU.x86>dd.exe if=\\.\G: of=C:\Temp\winxp.img
conv=noerror –localwrt
Statistics for logical volume \\?\Volume{fa049b8f-018b-11e2-8062-005056c00008}\
0x082832000 bytes available
0x082832000 bytes free
0x214b0000 bytes total
Volume Name:    \\?\Volume{fa049b8f-018b-11e2-8062-005056c00008}
Volume Label:   KOO
Mount Points:
G:\
Drive Type:             Fixed
Volume Serial Number:           1c62-13ee
Maximum Component Length:       255

Volume Characteristics:
File system preserves case
File system supports Unicode file names
File System:            FAT32
Mounted:                Yes
Clustered:              No
Volume Extents:
Disk Number:     1
Starting Offset: 0x0000000000007e00
Extent Length:   0x0000000201cbb200

Copying \\.\G: to C:\Temp\winxp.img
Output: C:\Temp\winxp.img
8620061184 bytes
8220+1 records in
8220+1 records out
8620061184 bytes written

Succeeded!

이제 X-Ways Forensics 도구를 이용해 Registry를 추출해 보자.

2. Registry 알아보기

(1) 데이터 유형 목록 (Listing of Registry value data types)
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724884(v=vs.85).aspx

Value Type
REG_BINARY (3)
이진 데이터
REG_DWORD (4)
32비트 숫자
REG_DWORD_LITTLE_ENDIAN (4)
32bit 숫자 (little-endian format)
REG_DWORD_BIG_ENDIAN (5)
32비트 숫자 (big-endian format)
REG_EXPAND_SZ (2)
Null로 끝나는 가변 데이터 문자열로 환경변수 참조 ex) “%PATH%”
ExpandEnvironmentStrings 함수로 호출
REG_LINK (6)
Null로 끝나는 Unicode 문자열로 symbolic link 경로 전용
REG_OPTION_CREATE_LINK를 이용한 RegCreateKeyEx 함수 호출
REG_MULTI_SZ (7)
Null, 빈 문자 (\0)로 끝나는 일련의 문자열
ex) String1\0String2\0String3\0LastString\0\0
첫 번째 \0은 첫 번째 문자열 종료, 중간 \0은 각 문자열, 마지막 \0은 sequence 종료를 의미함
REG_NONE (0)
정의되어 있지 않음
REG_SZ (1)
Null로 끝나는 문자열. Unicode나 ANSI 문자임

(2) Registry 경로와 파일 (Registry Paths and Files)

Registry는 Hive 구조로 되어 있으며 아래 링크에 잘 설명되어 있으니 참조하자.
http://technet.microsoft.com/en-us/library/cc750583.aspx

키는 다음 6개로 구성된다.
HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS, HKEY_CURRENT_CONFIG, HKEY_DYN_DATA

Key 설명
HKEY_CLASSES_ROOT
HKEY_LOCAL_MACHINE\SOFTWARE\Classes의 Symbolic Link
HKEY_CURRENT_USER
HKEY_USERS 사용자 프로파일 Hive 하위 키 Symbolic link
HKEY_LOCAL_MACHINE
물리적 hive는 존재하지 않으며 hive 구조의 다른 키를 보유함
HKEY_USERS
로그온 계정의 사용자 프로파일 hive를 담고 있는 장소
HKEY_CURRENT_CONFIG
현재 하드웨어 정보를 가지고 있는 키 Symbolic link

(HKEY_LOCAL_MACHINE \SYSTEM CurrentControlSet\Control\IDConfigDB\Hardware Profiles 하위)

HKEY_DYN_DATA
데이터 탐색 성능을 위한 장소이며 물리적 hive는 존재하지 않음

레지스트리는 크게 6개의 물리적 파일과 2개의 휘발성 파일이 있다.
There are six physical hive files in hard disk and two volatile files in memory.

Registry Path File Path
HKLM\System
%WINDIR%system32\config\SYSTEM
HKLM\SAM
%WINDIR%system32\config\SAM
HKLM\Security
%WINDIR%system32\config\SECURITY
HKLM\Software
%WINDIR%system32\config\SOFTWARE
HKLM\Hardware
휘발성 Hive
HKLM\System\Clone
휘발성 Hive
HKEY_USERS\User SID
사용자 Profile (NTUSER.DAT)
“Document and Settings\User” (WinXP), “Users\User” (Vista 이후)
HKEY_USERS\Default
%WINDIR%system32\config\DEFAULT

(3) 하이브 구조 (Hive Structures)

Registry는 파일 시스템에서 블록단위와 마찬가지로 논리적인 Hive 구조를 가지고 있다. Registry의 블록 크기는 4,096바이트(4KB)이며 새로운 데이터가 Hive에 추가될 때 block으로 증가한다. Hive는 다섯 가지의 데이터 유형으로 Key cell, Value cell, Subkey-list cell, Value-list cell, Security-descriptor cell로 구성된다. 특히 아래 보이는 kv, kn은 Signature다. (Little Endian)
Registry has logical hive structure just like blick unit in file system. The size of the block is 4,096 Bytes (4KB). It increments by block size when adding new data. Hive structure has 5 different data types: Key cell, Value cell, Subkey-list cell, Value-list cell, Security-descriptor cell. See the signatures within the excerpt of a raw registry file.

 

Cell Data Type
Key cell
레지스트리 키를 저장하고 있으며 키 노드라고도 함
* Signature: 키-kn, kl-심볼릭 링크
* 키가 최종 업데이트된 timestamp (LastWrite)
Value cell
키값과 데이터를 저장하는 셀
*  Signature : kv
* 유형: 상단 레지스트리 유형 참조 (e.g., REG_DWORD, REG_BINARY),
* 값 이름
* 값의 데이터를 담고 있는 셀 인덱스
Subkey-list cell
키 셀을 가리키는 일련의 인덱스로 구성
Value-list cell
값 셀을 가리키는 일련의 인덱스로 구성
Security-descriptor cell
보안 식별자를 가지고 있는 셀
*  Signature: ks