h32j00

랜만에 DFC 문제를 풀어보겠습니다~

영어 잘하는 제가 한번 해석을 해보자면... 큼큼 IR ... 으흠흠..... 말웨어에 감염된 pc의 $MFT 파일을 주겠다..

공격자가 $Recycle.Bin 폴더를 가지고 공격을 진행했으니 그 부분을 보면 되겠네요.

$MFT를 winhex로 열어봤습니다.

($Recycle.Bin 검색 후 살펴 봄) MFT entry 구조에 대해서 잠시 보자면

로 되어있었습니다.

$INDEX_ROOT를 좀 더 살펴보면 현재 $Recycle.Bin 폴더에는 

가 존재합니다.

생각을 해보자면 휴지통에 파일을 임의적으로 넣으면 파일명이 그대로 살아있고 ( 7.exe 처럼 )

그게아니라 일반적인 삭제라면 일반적으로 $I, $R 이라는 파일 두개가 생성됩니다. 아무래도 휴지통에만 넣는다는 것은 일반적인 삭제기 때문에 복구를 해야하니까 그에 대한 정보를 같이 생성하는 것 같습니다. 

여기까지만 보면 7.exe가 의심이 되긴합니다. 삭제한 파일이 아니라 임의적으로 옮겨놓은 파일이기 때문에..

하지만 좀 더 살펴보면 $INDEX_ROOT 속성 밑에 엔트리 속성이 깨진 속성을 확인할 수 있었습니다. $FILE_NAME이 깨진걸로 확인됨. ( time 4개, file size 2개, file name을 알 수 있는 속성은 $FILE_NAME 이기 때문에 )

이건 제가 *테스트 해본 결과 휴지통에서도 삭제된 파일임을 알 수 있었습니다.

이로써 의심되는 이유를 나열하자면 아래와 같습니다.

1. 7.exe

   1) 휴지통에 임의로 넣은 흔적(파일 이름으로 존재)

   Name: 7.exe

   Created Time: 2019-04-27 08:24:04

   Modified Time: 2019-04-27 08:24:04

   MFT Modified Time: 2019-04-27 08:25:17

   Last Accessed Time: 2019-04-27 08:24:04

   Allocated size of file: 0x90000

   Real size of file: 0x8f800

2. x.exe

   1) 휴지통에 임의로 넣은 흔적(파일 이름으로 존재)

   2) 휴지통에서도 삭제한 흔적(깨져있음)

   Name: x.exe

   Created Time: 2019-04-27 10:40:29

   Modified Time: 2019-04-27 10:40:29

   MFT Modified Time: 2019-04-27 10:40:40

   Last Accessed Time: 2019-04-27 10:40:29

   Allocated size of file: 0xf6000

   Real size of file: 0xf5098

여기서부터는 제가 따로 테스트한 과정입니다.

안쓰는 usb를 ntfs 파일시스템으로 포맷한 후 진행하였습니다.

E 드라이브 밑에 test라는 폴더를 만들고 그 안에 

aaaaa.txt, bbbbb.txt, ccccc.txt, ddddd.txt, eeeee.txt 라는 파일 5개를 추가했습니다.

그리고나서 winhex로 본 결과

test 폴더 밑에 $INDEX_ROOT 에 aaaaa.txt ~ eeeee.txt로 아주 잘 있습니다.

여기서 제가 ccccc.txt를 삭제해보겠습니다.

ccccc.txt가 없어지고 ddddd.txt가 올라온 모습을 확인할 수 있습니다.

$INDEX_ROOT는 B tree 구조로 되어있기 때문에 삭제되면 그에 맞게 구조가 변하기 때문에 ccccc 대신 ddddd가 올라온 것입니다.

여기서 다시한번 맨 뒤에 있는 eeeee.txt를 삭제해보겠습니다. eeeee.txt 뒤에는 아무 파일도 없는 데 어떤 변화가 나타날까요?

삭제를 했지만 그대로 존재하는 것을 확인했습니다. 물론 $INDEX_ROOT header에서 속성크기가 변한 것을 확인할 수 있었습니다(처음엔 eeeee.txt 까지 포함하는 크기에서 나중에는 위의 사진의 분홍색부분까지만 포함). 또한 시간이나 파일 사이즈, 파일 이름은 안깨졌지만 그 앞의 내용은 깨진 것을 확인할 수 있습니다. 이러한 테스트 결과 x.exe도 $Recycle.Bin 폴더에 존재하다가 삭제했다는 것을 알 수 있었습니다. 

문제를 읽어보니

what-is-Pooh-doing? 문제파일이랑 함께 파일이다.

7z 이용하여 압축을 풀어보니

하이브파일이랑 로그파일이 있었다.

hve 파일 먼저 "Registry Explorer"로 열어보았다.

Let's warm up. 부터 살펴보자

Let's warm up. 의 하위 키에는 숨겨진 데이터가 없다고 말한다. 믿어주도록 하지

하지만 숨겨진 데이터를 위한 힌트를 여기서 얻을 수 있다고 한다! nameless values?.. 뭐짓

엄청나게 많은 하위키들이 존재한다,, 여기서 nameless values를 가진 알파벳을 찾아라..

... 찾아보니까 nameless values 가 (default)라는 데 나는 (default) 값이 너무 많이 찾아진다.. 그래서 여기선 힌트를 얻지 못했다..

이제 One part was stored here.를 살펴보자

One of three parts.. 3개 중에 하나가 있나보다.

이 하위 키(Yes, you are almost there!)에 하나의 보물이 숨겨져있나보다.

하지만 registry explorer에서는 아무것도 찾을 수가 없었다...

이제 Two parts were buried here.을 살펴보자.

두개는 여기서 찾을 수 있나보다.

아마 Golden-Chamber에서 2개를 찾을 수 있는 것 같다.

하지만 registry explorer에서 찾을 수 없었다.

위에서 얻은 힌트들을 토대로 010 editor를 사용해서 찾아보기로 했다.

* 힌트

1. Yes, you are almost there! 에서 하나

2. $$$Golden-Chamber$$$ 에서 둘!

010 editor를 사용하기전에 hve 파일의 구조를 잠시 살펴보자면

여기서 nk는 아까 registry explorer에서 본 디렉터리 같은 느낌이면

vk는 그 안에 value name, value type, data 를 담고 있다.

Golden-Chamber 안에 value값이 보인다. 1. Bitmapfileheader라는 문자열과 BM... 이것은 BMP 파일 시그니처이다.

vk 셀을 더 자세히 살펴보면

data 길이는 14, offset은 23184(0x5a90) 이다. offset을 따라가면 실제 데이터가 존재한다. 거기서 14만큼만이 bmp파일의 헤더인가 보다.

offset은 0x5a90이지만 여기에 0x1000을 더해야한다. 이 offset은 첫번째 hbin가 기준이기 때문이다. 첫 hbin은 0x1000부터 시작하니 그 값을 더해주면 된다.

0x5a90+0x1000 = 0x6a90에서부터 14 길이만큼 이지만 첫 4바이트는 셀의 길이이기 때문에 0x6a94부터 14 만큼이 되겠다. ( 셀의 시작 4바이트는 항상 그 셀의 크기이다. )

첫 번째 조각!!

그 밑을 보면 2: bitmapinfoheader+palette 라는 문자열이 보인다.

이게 뭔가 싶어서 bmp 파일 구조를살펴보니

이렇게 되어있었다. fileheader는 bitmapfileheader에서 찾았고, image header와 color palette는 bitmapinfoheader+ palette에서 찾으면 될것같다. (위에서 찾은 방법과 같은 방법으로 찾으면 된다.)

2번째조각을 찾았다!!

이제 pixel data를 찾으면 되는데 한 부분을 안봤었다. 바로 Yes, you are almost there! 이 부분이다.

아까 아무런 value를 찾지 못했었는데 여기선 찾았다.

누가 봐도 pixel data이다.

0x3244(0x2240+0x1000+0x4(cell 크기부분))에 가서 0x1650 만큼 파싱하자.

3번째 조각이다!!

1,2,3 번 조각을 합쳐서 bmp 파일로 저장해서 봤더니

두두둥.. 푸는 여기 없단다..

hve 파일 말고 로그파일을 다시 봐보자.

모든 증거를 vk 기준으로 얻었으니 vk라는 문자열을 찾아서 보았다.

여기까진 이전과 다를게 없다. 그렇다면 마지막 남은 곳으로...

이 모든 것을 합치고 다시 bmp 파일을 보면

숨겨진 그림 파일을 찾아냈다..

생각하라는 푸......

그럼 다음 문제에서 또 봅시닷!

AF( Anti Forensics ) 100점은 생각보다 난이도가 쉬웠던 것 같습니다.

Zip 파일의 Central Directory와 End of Central Directory를 수정하여 은닉된 파일 하나를 얻으면 해결되는 문제였습니다!

m20190501.zip

문제의 zip 파일!! 두둥,,,

HxD로 까보기 전에 zip파일의 구조를 간단히 살펴보겠습니다.

제일 잘 이해되었던 그림을 살펴보자면

zip 구조 (출처: https://jmoon.co.kr/48)

"End of Central Directory"는 Central Directory의 정보를 간략히 담고 있고 

"Central Directory"의 값들을 참조해보면 Local File Header에 접근할 수 있습니다.

큰 틀은 여기까지이고 HxD로 zip파일을 까보도록 하겠습니다.

1. End of Central Directory

"End of Central Directory"

"End of Central Directory" 구조

<주요 필드>

Signature: 50 4B 05 06 -> 시그니처

Disk entries, Total entries: 04 00 (0x4) -> 개수

Central directory size: 17 01 00 00 (0x117) -> central directory 크기

Offset of cd: 33 DA 2D 00 (0x2DDA33) -> central directory 시작 주소

total entries 가 4인걸 보면 zip 파일안에 4개의 파일이 있다는 것을 알 수 있었습니다.

2. Central Directory

Central Directory를 보면 Local File Header와 거의 동일한 정보를 가지고 있다는 것을 알 수 있습니다.

이 헥스값을 바탕으로 정리해보자면 Local File Header가 총 4개라는 것을 알 수 있습니다.

3. Local File Header

"Local File Header" 구조

Local File Header의 Signature은 50 4B 03 04 이다.

ctrl + F4를 이용해 찾아봤더니 총 5개 나온다. 누군가 숨겨놓은 것이 분명하다!!

Central Directory와 비교하며 본 결과 Central Directory에서는  "0x1CCC70"에서 시작되는 친구의 정보가 없는 것이 확인되었다.

숨겨진 파일의 Local File Header 정보

header 구조를 보면서 알맞은 정보를 얻어서 Central Directory와 End of Central Directory를 조금만 수정해주면 됩니다.

여기서 Extra Field length가 0x10 즉 16바이트인것을 확인해보면 이름뒤에 16바이트를 읽을 수 있습니다.

  --> 9tBcZXF8X7^nMcYd (어딘가에 쓰일 것 같은 느낌~)

그리하여 복구를 한 결과

숨겨진 파일 복구!!

7z를 이용하여 압출을 푸는 모습(아까 얻은 암호 사용!!!)

Secret Document.jpg 를 얻었다.

비밀 문서를 손에 쥐게 되었군!

끝~