M4ndU의 만두만두한 블로그

https://dfir.pubpub.org/pub/h78di10n/release/2

저자: Alexandros Vasilaras 1 , Evangelos Dragonas 2 , Dimitrios Katsoulis 3

vasilaras@digitalforensics.gr , dragonas@digitalforensics.gr , katsulis@digitalforensics.gr

라이선스:  Creative Commons Attribution 4.0 국제 라이선스(CC-BY 4.0)

- 개요

질문 : Windows 이벤트 로그에서 이전에 연결된 장치의 VSN을 몇 개나 복구할 수 있는가

OS 버전 : Windows 10 Pro 2004 build 19041

도구 : JLECmd 1.4.0.0, LECmd 1.4.0.0, AXIOM 4.7, Partition-4DiagnosticParser

- 배경

윈도우 10에 파티션/진단 이벤트 로그가 처음 도입됨.

C:\Windows\System32\winevt\Logs\ Microsoft-Windows-Partition%4Diagnostic.evtx

이 로그에서 여러 볼륨이 있는 장치의 최대 3개의 VSN을 찾을 수 있음.

해당 로그를 분석해서 VSN을 추출하는 도구를 개발함.

해당 이벤트 로그에는 이동식 디스크 (USB 스틱, SD카드, 외장 하드 등)과 컴퓨터 내부 디스크에 대한 정보가 저장됨.

- 이벤트 로그 필드 일부 설명

[시스템 섹션]

• EventID: 항상 1006
• TimeCreated [SystemTime]: 타임스탬프
• EventRecordId: 로그 파일 내의 각 기록에 할당된 고유 번호
• Computer: 컴퓨터 이름
• Security [UserID]: 유저의 SID값. 항상 S-1-5-18임 (User SYSTEM).

[이벤트 데이터 섹션]

• DiskNumber: In our analysis, we found this number varying in a range between 0-3, with 0 being assigned to the disk running the operating system (OS).
• IsSystemCritical: This value is usually false, apart from when DiskNumber was 0.
• BytesPerSector: Bytes per sector (usually 512-defined by the manufacturer) of the device.
• Capacity: The total capacity of the device (in bytes).
• Manufacter: The manufacturer of the device. Not always accurate.
• Model: Model of the device. Not always accurate.
• SerialNumber: Serial number of the device.
• ParentId: Information about the device, including Vendor ID, Product ID, Serial Number (potential correlation with registry files).
• PartitionStyle: The partition scheme of the device. MBR is 0. GPT (GUID Partition Table) is 1.
• PartitionCount: Number of partitions of the device. Not to be trusted.
• Mbr: Raw dump of the first 512 bytes of the Master Boot Record of the device. Contains device’s Disk Signature and Master Partition Table.
• Vbr0: Raw dump of the Volume Boot Record of the device’s 1st partition. Contains the VSN of this partition.
• Vbr1: Raw dump of the Volume Boot Record of the device’s 2nd partition. Contains the VSN of this partition.
• Vbr2: Raw dump of the Volume Boot Record of the device’s 3rd partition. Contains the VSN of this partition.
• Vbr3: In our analysis, we found that this field is not populated with the raw dump of the Volume Boot Record of the device’s 4th partition. If someone wants to determine the existence of a 4th partition, he should examine the Master Partition Table.

위에서 볼 수 있듯 한 장치의 두 번째 및 세 번째 파티션의 VSN도 저장한다. 사용자가 자신의 장치를 포맷하더라도(할당된 VSN 손실) 이벤트 로그에서 이전 VSN을 검색할 수 있다.

- 조건 및 한계점

이 연구는 Microsoft-Windows-Partition%4Diagnostic.evtx 이벤트 로그에 대한 포렌식 분석에만 중점을 둠. 레지스트리 등의 다른 아티팩트를 조사하지 않는다.

이 연구는 할당되지않음 또는 MBR 파티션이 있는 장치로 제한됨. GPT 파티션 장치는 이 이벤트 로글르 다른 방식으로 기록함. 또한 4번째 파티션이 존재할 경우 4번째 파티션에 대한 정보는 저장되지 않음.

이 연구는 FAT32, NTFS, exFAT, EXT3 파일 시스템을 사용하는 장치만을 대상으로함. 다른 파일시스템을 사용하는 장치는 이 이벤트 로그를 다른 방식으로 기록함.

해당 이벤트 로그의 수명은 짧음. 주요한 윈도우 10 업데이트될 때 이벤트 로그가 지워짐. 다만, 19041에서 19042로의 업데이트와 같이 사소한 업데이트로는 지워지지 않음.

장치유형(SSD), 연결유형 (USB <- SATA 디스크)는 이벤트 로그를 다른 방식으로 기록함.

- 방법론

VSN은 파티션의 고유하게 하는 한 가지 기능임.

VSN은 VBR 내부에 있으며, 오프셋과 길이는 파일시스템에 따라 다름.

VSN은 LNK파일 및 점프 모곩에서 대상 파일이 있는 볼륨을 가리키는데 사용됨.

MBR 파티션 테이블이 있는 장치를 식별하는 다른 기능은 디스크 서명임.

디스크 서명은 MBR의 offset 0x1b8(4byte, little endian)에 있으며 파티션이 만들어질 때 할당 됨.

--- 직접 시연을 하기 위해서 사용된 환경 및 장비가 다릅니다. ---

OS : Windows 10 home 21H2 19044.1415
usb device : A(unknown) 64GB(MBR, 4 NTFS partition), B(unknown) 8GB (MBR, 1 FAT32 partition & 1 EXT3 partiton)
software : JLECmd 1.4.0.0, LECmd 1.4.0.0, AXIOM 4.7

• 1단계 : 이 단계에서 A 64GB USB 장치는 테스트 컴퓨터에 여러 번 연결/해제되었습니다. 장치가 연결되어 있는 동안 LNK 파일과 점프 목록을 생성하기 위해 여러 파일(4개 파티션 모두에 위치)에 액세스했습니다. 일정량의 데이터가 생성된 후 이벤트 로그, LNK 파일 및 점프 목록에 대한 포렌식 검사를 진행했습니다.
• 2단계 : 이 단계에서 A 64GB USB 장치의 모든 파티션을 삭제하고 3개의 새로운 NTFS 파티션을 생성했습니다. 1단계(연결/연결 해제, 모든 파티션의 파일 액세스)와 동일한 과정을 반복했습니다. 일정량의 데이터가 생성된 후 이벤트 로그, LNK 파일 및 점프 목록에 대한 포렌식 검사를 진행했습니다.
• 3단계 : 이 단계에서 B 8GB USB 장치는 테스트 컴퓨터에 여러 번 연결/해제되었습니다. 잠시 후 우리는 이벤트 로그에 대한 포렌식 조사를 진행했습니다.
• 4단계 : 이 단계에서 B 8GB USB 장치의 FAT32 파티션을 삭제하고 새로운 exFAT 파티션을 생성했습니다. 3단계(연결/연결 해제)와 동일한 과정을 반복했습니다. 잠시 후 우리는 이벤트 로그에 대한 포렌식 조사를 진행했습니다.

A usb의 환경 구성에 실패. 처음에 NTFS 파티션 4개로 나누고 각 파티션에 테스트용 파일까지 넣고 usb 재인식하니까 위 사진처럼 파티션 구성이 바뀌어서 인식됨. usb 자체 문제인지 특성인지 파악 못함.

B USB의 경우 FAT32와 EXT3 파티션 구성이 유지되었음.

그러나 FAT32 파티션을 exFAT 파티션으로 포맷하고 재인식하니 exFAT 파티션이 RAW로 인식되버림.

첫번째 파티션을 exFAT 대신 NTFS로 다시 포맷하여 진행함.

따라서 3~4단계만 진행.

1단계

그냥 위 사진 상태의 usb를 연결하고 파일에 접근한 뒤 로그를 확인해 보았다.

NTFS로 정상적으로 인식되는 첫 번째 파티션은 vbr이 제대로 기록되었고, 나머지는 vbr이 0000으로 기록되었지만 이를 통해 최소 4개의 파티션이 존재했음을 알 수 있다.

2단계

3단계

USB를 연결하고 FAT32 파티션 내에 있는 테스트 파일을 열어본 이후 Microsoft-Windows-Partition%4Diagnostic.evtx 해당 이벤트 로그를 확인한 내용이다.

FAT32 파티션의 vbr은 기록되었지만 EXT3 파티션은 인식할 수 없는 포맷이므로 vbr이 기록되지 않았다.

그래도 2개의 파티션이 있는 것을 확인할 수 있다.

4단계

역시 2개의 파티션이 존재함을 알 수 있고, 두 번째 EXT3 파티션은 여전히 0000으로 기록되어있으며

첫번째 파티션이 새로 포맷되었기 때문에 vbr값이 변경된 것을 알 수 있다.

mbr값은 동일하다.

- 결론

이 게시물에서 우리는 특히 장치 속성이 필요한 경우 "Microsoft-Windows-Partition%4Diagnostic.evtx" 검사의 중요성에 대해 설명했습니다. 이 유물이 몇 년 전에 발견되었지만 우리는 아직 그 풍부한 정보를 완전히 탐색하지 못했습니다. 그럼에도 불구하고 우리는 저장되어 있는 사용 가능한 모든 VSN을 수동으로 추출하는 방법과 이 프로세스를 자동화하는 도구를 개발하는 방법을 보여주었습니다. 이 이벤트 로그에 대한 추가 연구의 여지가 있지만 독자가 이 이벤트 로그에서 찾을 수 있는 주요 아티팩트 중 일부에서 가치를 찾을 수 있기를 바랍니다.

https://github.com/theAtropos4n6/Partition-4DiagnosticParser

- 앞으로

해당 이벤트 로그가 GPT 파티션을 사용하는 장치를 처리하는 방법과 다양한 파일 시스템을 처리하는 방법을 분석할 예정.

- DFIR 리뷰

 USB 드라이브에는 여러 볼륨이 포함될 수 있으며, 동일한 물리적인 USB 드라이브에서 여러 볼륨을 나올 수 있다는 사실을 간과할 수 있따는 점을 중요하게 지적함.

ASCTF에 출제한 리눅스 메모리 포렌식 문제 제작에  12시간 이상 소요된 것 같다. 사전 계획 빼고 문제 제작 자체만.

순조롭게 진행되었다면 절반도 안걸렸을테지만.. 처음 만들다보니 헤메는 것이 많았다.

그리고 만들고 보니 왜 CTF들에 리눅스 메모리 문제는 거의 없는지도 느낄 수 있었다.

리눅스 메모리 포렌식 문제 제작은 처음이지만, 최근에 한 번 풀어 본 적이 있다.

리눅스 메모리 포렌식의 특징은 분석 자체는 볼라티리티로 하면 되므로

윈도우랑 별 차이가 없기 때문에 쉽다.

그런데 이 볼라티리티를 사용하기 위한 환경 구성에 시간이 많이 소요된다.

프로필을 생성하는 방법은 쉽게 찾을 수 있다.

이 과정에 비교적 많은 시간이 소요된다. 리눅스를 가상머신에 깔고 커널버전을 맞춰줘야 하니까..

리눅스 종류랑 리눅스 커널 버전이 매우 다양해서, 볼라티리티에서 모든 종류의 프로필을 배포할 수 없고

많은 프로필들을 한 번에 볼라티리티에 적용할 경우 볼라티리티의 성능이 매우 나빠진다.

따라서 필요한 프로필만 그때 그때 만들어서 적용을 해서 사용을 해야한다.

이 부분을 노리고 문제 제작을 계획했다.

리눅스에서 메모리를 덤프할 때 사용할 수 있는 소프트웨어들에는 여러가지가 있다.

그 중에서 나는 들어본 적 있는 lime을 사용하기로 했고 관련 포스트를 찾아보았다,

위 포스트를 찾아서, 문제 시나리오대로 구성을 한 뒤에 덤프를 위해 사용방법을 따라했다.

근데 사용 예시에 format이 raw로 설정되어있다. 밑에 옵션은 처다보지도 않고, 당연히 메모리 덤프는 raw지! 하고 raw로 덤프를 떴다.

그리고 볼라티리티를 돌렸는데 여기서 문제가 발생했다.

이런 식으로 no base address space가 떴다. (사용했던 볼라티리티 버전은 2.6.1 최신이었다.)

문제 제작한 환경이 ubuntu 18.04.1 x64 linux version 5.4.0-42-generic 이었고, 동일한 환경에서 제작된 문제를 이전에 풀어본 적이 있었기 때문에 전혀 이해가 가지 않은 상황이었다.

그래서 좀 찾아보니까 

리눅스 커널 4.8 부터는 KASLR이 적용되어 있어서 저런 현상이 발생되고 분석을 진행할 수 없다는 내용이었다.

추가로 kaslr이 적용된 4.8에서 사용할 수 있는 볼라티리티 버전이 있다는 내용도 있었다.

이 시점에서 의문이 들었다.

내가 풀었었던 동일한 환경의 문제는 어떻게 제작이 되었던 것일까?

1. 나랑 다른 방식으로 메모리를 덤프하였다.

2. kaslr을 해제하고 문제를 제작하였다.

2번 같은 경우 kaslr을 해제할 수 있다는 내용을 보고 선택지를 추가하게 되었다.

난 여기서 1번에 의심을 가졌으면 금방 해결되었을 문제였지만 나는 4.8 kaslr 버전용 볼라티리티가 따로 있어? 에 흥미를 느끼고 4.8 환경에서 문제를 제작해서 해당 볼라티리티 버전만을 사용하게 해서 문제를 풀게 하면 재밌겠다는 생각이 들었다. 그리고 이게 안되면 kaslr을 해제해서 만들자로 plan b를 세웠다.

(아무 의미가 없는 행동이었다. bneuburg가 제작한 4.8 kaslr 지원 버전에는 2개가 있는데, 모두 2017년에 올라온 것이고 지금은 이미 최신버전 볼라티리티에 기본 탑재되어 있는 기능이다. 근데 난 몰랐다. (아니 나 2017년도 내용임을 확인안하고 뭐했냐..))

기존에 사용하던 18.04.1에서는 커널 버전을 4.8로 내릴 수 없어서 4.8로 탑재되어 있는 16.10을 다운받아 환경을 구성하였다.

그리고 똑같은 짓을 하고

똑같이 raw로 덤프를 떠서

볼라티리티를 돌렸고

똑같은 결과가 나왔다. No base address.

왜 안되지 하고 깃헙 페이지를 자세히 봤다. 이전엔 자세히 안보고 걍 지원되는 버전 정도만 확인 했었다.

이걸 딱 읽고 아 라임 포멧이어야 하는구나를 알게 되었다.

그리고 이전에 읽었던 lime 사용방법 블로그로 돌아와서

방법2-1에는 포멧을 lime으로 써두셨더라..

그래서 처음부터 다 잘못됐음을 깨닳고 처음 환경에서 lime으로 뽑아내서 최신버전 볼라티리티를 돌렸고

분석에 성공했다.

이렇게 메모리 덤프를 볼라티리티에 인식하게 하는 것에 성공했다.

다음 두번째 문제가 있었다.

처음 계획했던 시나리오는 크롬이나 파이어폭스 검색 기록을 확인해서 특정 시간에 검색한 키워드를 찾아내는 것이었다.

근데 문제는 일단 chromehistory firefoxhistory 플러그인이 리눅스에서는 지원되지 않았다.

그러면 히스토리 파일을 뽑아내야하는데, 파일을 추출 할때 윈도우처럼 filescan 같은 플러그인이 없고 find_file 플러그인 하나로 파일의 메모리 주소 뽑아내고 파일 추출을 다 해야한다.

find_file로 파일의 메모리 주소를 뽑아내려면 파일의 full 절대 경로를 알아야 한다. 크롬은 기본 설치 경로를 생각하고 히스토리 파일을 뽑아낼 수 있겠지만 파이어폭스는 랜덤 문자열의 profile 이름으로 생성된 폴더에 있기 때문에 해당 폴더명을 알아내야하는 과정이 필요한데, lime 포멧은 R-Studio 같은거에서도 분석이 안되서 파일 구조를 확인할 수 없고

bash에서 해당 파일명을 주고자 bash로 직접 해당 폴더까지 접근하는 것을 시나리오 넣기엔 너무 부자연스러웠다. 문제 제작을 위해 고의로 넣은 내용 느낌. 개인적으로 이런거 안 좋아한다.

뭐 어떻게 해서 풀 절대경로를 줘서 파일을 추출하더라도 내용이 제대로 들어있지 않았다.

그래서 히스토리 파일을 뽑아내는 것은 의미가 없었다.

그래서 크롬/파이어폭스 프로세스를 덤프를 떠서 찾아내야 하는데,

yarascan으로 http 뽑아내서 링크들을 뽑아내는 것은 가능한데, 시간 값을 뽑아내려면 뭐 어떻게 잘 해서 뽑아내야할건데 난 모른다.

그래서 문제 지문에 구글 검색으로 첫 번째로 검색한 내용은? 같은걸 할까 했지만 이 경우 구글 검색 링크 "https://www.google.com/search?q=" 로 yarascan 돌리면 바로 나와버리기 때문에 난이도가 매우 낮았다. 이건 볼라티리티 안쓰고 그냥 grep으로도 뽑아낼 수 있으므로 

브라우저 검색 기록을 찾아내는 것은 포기하고

어디서 많이 본 프로세스 뽑아내서 실행하기가 되었다.

근데 또 문제가 있었다. bash에 입력한 명령어는 볼라티리티 플러그인으로 확인할 수 있지만, 출력된 내용은 플러그인으로 확인할 수 없는 것으로 알고 있다.

하지만 그냥 raw로 출력 내용이 남아 있기 때문에 strings랑 grep으로 다 뽑아낼 수 있다.

grep에 키워드가 최대한 걸리지 않도록 플래그를 base64 이중으로 인코딩하는 등의 노력을 했지만

"ASCTF"가 키워드에 걸렸다. "ASCTF{"만 생각하고 이건 생각 못했다. 이건 롸업에도 써놨다.

이걸 롸업 작성하면서 알아서 해당 프로세스의 pid값을 플래그에 추가하는 걸로 문제를 수정하였다.

pid값은 볼라티리티로만 뽑아낼 수 있으니까..

혀튼 리눅스 메모리 포렌식 문제를 제작해보고 다시 풀어보면서 

리눅스 메모리 분석은 윈도우 메모리 분석이랑 비슷하거나 할 수 있는게 더 적었고

실제 분석보다 환경 구성의 비중이 크고 오래걸리고 어렵고 귀찮고 짜증나기 때문에

CTF에서 리눅스 메모리 문제를 보기 어려웠던 이유를 알 수 있었다.

분석 자체만 가지고 어렵게 만들 수만 있다면 프로필 파일은 같이 제공해줘도 되긴 하는데

음

응애

나 뉴비