foxcomplex

기본적으로 패킷을 분석하기 전에

패킷을 캡처하고 해당 캡처본을 확인한다.

1. 우선 http로 필터링을 한다.

2. 분석하려는 패킷을 follow로 tcp stream 한다.

3. 패킷을 분석한다.

http.response.code == 200

를 할 경우 응답 코드가 200인 패킷들만 필터링 해서 가져오기 때문에 패킷에서 분석을 할 때 보내는 것은 있지만 어떠한 응답이 왔는지 확인하기 위해서 필터링을 해줄 수 있다.

파일을 주고 받는 http 리퀘스트와 응답을 확인할 수 있다. dpkt를 이용해서 원하는 패킷만 따로 분류할 수도 있다.

https://apackets.com/

이 사이트를 이용해 패킷을 분석할 수도 있다 그 대신에 해당 파일 정보가 해당 사이트로 넘어가기 때문에 이를 주의하고 사용하면 된다.

1. unallocated space란? + 작성 이유

한글로 번역하자면 할당되지 않은 공간 즉 사용하지 않는 공간이라는 뜻입니다. 이는 윈도우에서 볼 수 있는데 그 예시는 다음과 같습니다.

위 사진들 처럼 할당 되지 않은 공간이 있습니다. 그런데 이게 포렌식이랑 무슨 연관이 있는지 궁금했고 이게 어떻게 동작하는지 정확한 원리를 알고 싶어서 찾아보았습니다.

2. 할당, 비할당 공간 - (여기서는 할당되지 않는 공간을 비할당 공간이라고 하겠습니다.)

윈도우 운영체제에서 내가 특정 공간에 파일을 작성하면 해당 부분은 할당된 공간이 됩니다. 그렇다면 할당되었다는 표시를 구분할 수 있는 규칙이 필요한데 파일 시스템은 1과 0으로 라벨링 함으로 구분을 짓습니다.

"1"일 경우에는 파일을 저장하는데 사용된다는 것을 의미합니다. 한마디로 해당 공간에 정보를 저장한다 라는 의미입니다.

"0"일 경우에는 파일이 삭제 되면 발생하는데 삭제를 할 때 0으로 라벨링을 하게 됨으로써 비할당 영역을 나타내는 것입니다.

중요한 것은 파일이 삭제 되었을 때를 주목해야하는데 0으로 라벨링이 되었다고 해도 해당 데이터가 완전 사라진 것이 아닙니다. 이는 데이터를 덮어쓰기를 하지 않는 이상 파일을 언제든지 복구할 수 있다는 뜻이 됩니다.

예를 들어보겠습니다.

.PDF 파일(대략 12GB), .DOC 파일(5GB)이 존재하는데 이를 내 SSD(512GB)에 저장을 하였습니다. 그리고 PDF파일이 필요가 없어져 삭제를 하였습니다.

그렇다면 할당영역은 본래 17GB였고 비할당 영역은 495GB이 됩니다. 이후 PDF를 삭제를 하였기 때문에 507GB가 비할당 영역 5GB가 할당 영역이 됩니다.

여기서 .PDF는 0으로 라벨링이 되었고, .DOC파일은 아직 할당되어있는 상태라고 볼 수 있습니다. 

.PDF는 unallocated space 에 존재하는데 이 공간에 다른 파일이 들어와 덮어쓰기가 된다면 파일을 복구할 수 없게 됩니다. 하지만 덮어쓰기 하기 이전에는 복구할 수 있습니다.

그 예는 다음 사진과 같습니다.

02067 파일은 삭제 된 파일이지만 FTK imager로 확인해 본 결과 PDF파일임을 확인해볼 수 있습니다. 이는 export로 복구가 가능하다는 이야기가 됩니다.

3. 단계별 예) - 0과 1 라벨링에 대해서 단계별로 자세히 설명하겠습니다.

1. 초기 상태

0000000000000000000000000.....으로 아무 데이터도 저장 안되어있는 0으로 라벨링이 다 되어있습니다.

2. 파일 저장

2개의 파일을 저장하면 해당 파일이 저장되는 공간에 1로 라벨링이 됩니다.

111001110000000000000000000......... 이라고 가정하겠습니다.(첫번째가 PDF, 두번째가 DOC)

3. 파일 삭제 - (PDF 복구 가능)

00000111000000000000000000..........으로 원래 라벨링 0으로 돌아가게 됩니다.

4. 새 파일 추가 - (PDF 복구 불가능)

110001110000000000000000000........이렇게 000자리에 덮어쓰기가 되면 복구가 불가능합니다.

4. 마무리 - 내 생각

윈도우 파일 시스템 구조는 전체적인 큰 틀에서 벗어나지 않는다는 점에서 안좋을 수도 있겠지만 개인적으론 좋다고 생각합니다.

이와 관련된 궁금한 것들을 찾아보는 과정 속에 문득 공부를 할 때마다 제대로 된 정리 문서가 영어로 되어있기 때문에 이를 번역해서 이해하고 찾아나가는 과정이 번거롭고 시간이 걸린다는 생각이 들었습니다. 

앞으로 이러한 분야, 해당 부분들을 한글로 번역 및 딱 요점만 정리해서 빠르게 이해하기 위해 작성해 나갈 것입니다.

참조 : 

https://www.thomsonreuters.com/en-us/posts/legal/understanding-e-discovery/

https://threat.media/definition/what-is-unallocated-space/

https://whereismydata.wordpress.com/2008/10/03/what-is-unallocated-space/

0. 준비 

준비물 :

실습 도구 - volatility 2.6.exe, Sysinternal suite

분석 파일 - cridex

다음은 메모리 포렌식 도구 volatility 2.6 win64 exe 입니다.

https://sourceforge.net/projects/forensiczone/files/PTFinder2018/volatility_2.6_win64_standalone.exe/download

다음은 스트링 값 추출을 위해 Sysinternal suite 설치 사이트입니다.

https://learn.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite

다음은 분석할 파일입니다.

https://github.com/volatilityfoundation/volatility/wiki/Memory-Samples

strings 쓸때에는 반드시 strings 먼저 한번 입력해서 동의(agree) 해주어야 제대로 사용할 수 있다.. 이렇게 간단한 것 때문에 시간 뺏기지 말자 나처럼

작업하려는 폴더에서 간단하게 작업을 하기 위해 다음과 같이 volatility 를 시스템 환경 변수 설정을 해주면 좋습니다.

기본적인 volatility 2.6 기본 명령어 및 사용법은 다음과 같습니다.

정석? 분석 순서

1. imageinfo 로 먼저 환경을 확인한다. -> --profile=환경

2. pstree, psscan, pslist, psxview 로 프로세스 정보 확인

3. cmdline, cmdscan, consoles로 커맨드 입력 확인

4. connections, netscan으로 네트워크 확인

5. filescan, dumfiles 로 오프셋값 찾아서 해당 파일 덤프

6. memdump, procdump 로 메모리 덤프와 프록 덤프로 해당 영역의 의미있는 값 추출, 파일 덤프

위와 같은 순서로 진행하겠다.

1. 시작

1.1우선 다음 사진과 같이 해당 메모리의 운영체제(환경)을 알기 위해 imageinfo 를 사용한다.

volatility_2.6_win64_standalone.exe -f .\cridex.vmem imageinfo

WinXPSP2x86, WinXPSP3x86이라는 것을 알아내었다. 이 두가지 중 WinXPSP2x86을 사용하겠다.

사용 방법은 간단하다 --profile=WinXPSP2x86을 해주고 그 뒤에 명령어를 입력하면 된다.

1.2이제 ps 프로세스 정보를 확인해볼 차례이다.

다음과 같이 명령어를 입력해서 프로세스 정보들을 확인해 볼 수 있다. 지금은 간단하게 나와 한번에 볼 수 있지만 여러 정보들을 보고 취합 및 정리 해보려면 커맨드 창에서 보기에는 무리가 있다

위처럼 커맨드 창에서 그냥 봐도 되지만 효율적으로 리다이렉션 > 을 이용해 해당 명령어를 입력한 정보들을 .log 파일에 옮겨줄 것이다.

다음과 같이 입력할 수 있다.

volatility_2.6_win64_standalone.exe -f .\cridex.vmem --profile=WinXPSP2x86 psscan > psscan.log

필자는 notepad++를 사용하여 다음과 같이 확인해볼 수 있었다.

다른 명령어를 써보기 전에 해당 로그에 올라와있는 파일들이 얼마 되지 않음으로 해당 파일들 먼저 분석해보겠다.

- svchost.exe : 윈도우 NT 계열의 운영체제에서 서비스를 관할하기 위한 프로세스의 이름이며 관련 이미지이다.

- lsass.exe : 로컬 보안 기관 하위 시스템 서비스에서 사용하는 프로세스로 보안 정책을 강화를 위한 윈도우즈 프로세스이다.

- services.exe : 서비스 제어 관리자로 윈도우 서비스 프로세스와 시작과 정지 및 상호작용하는 특별한 시스템 프로세스이다.

- reader_sl.exe : 어도비 아크로뱃 스피드 런처 유형의 파일로 PDF뷰어 Adobe Reader의 빠른실행을 도와주는 프로그램이다.

- spoolsv.exe : 윈도 xp에서 인쇄와 관련된 일을 함 즉 프린트 스풀러 서비스를 위한 프로세스이다.(간단히 프린터 관련 프로세스)

- wuauclt.exe : 윈도우 업데이트를 확인, 업데이트를 다운로드 하고 설치하는 서비스이다.

- alg.exe : 윈도우 OS의 구성요소로 타사 방화벽, 인터넷 연결 공유를 사용하는 경우 필요합니다.(보안과 관련된 프로세스)

- explorer.exe : 파일 탐색기로 윈도우 환경에서 쉽게 볼 수 있는 GUI 셸이다.

- winlogon.exe : 윈도우 로그인 관리자로 로그인시 프로필 로드, 컴퓨터를 잠그는 역할을 하는 프로세스이다.

- csrss.exe : 클라이언트/서버 런타임 하위 시스템으로 통신을 담당하는 프로세스이다.

- smss.exe : 세션 관리자 하위 시스템으로 컴퓨터 세션에 관할하는 프로세스이다.

- System : 말그대로 시스템이다.

여기에서 의심스러운 것은 PDF를 이용한 악성코드일 수도 있는 reader_sl 파일이다. 일단 멀쩡한 프로세스일 수도 있으니 의심정도만 한다.

psscan.log에서 나타난 오프셋은 프로그램 시작 위치이고 Name은 해당 프로세스 이름을 나타낸다.

PID, PPID는 자식, 부모 프로세스를 뜻하는데 말 그대로 부모가 자식 프로세스를 낳는다고 표현하면 부모가 자식프로세스를 만든다라고 대충 이해하면 된다.

Time은 만들어진 시간 즉 해당 프로세스가 올라온 시각을 뜻한다. 시각별로 나타나있다.

이제 다른 psscan을 제외한 나머지 프로세스 명령어는 pstree, pslist, psxview임으로 한번에 입력하여 정보를 가져오겠다.

volatility_2.6_win64_standalone.exe -f .\cridex.vmem --profile=WinXPSP2x86 pslist > pslist.log
volatility_2.6_win64_standalone.exe -f .\cridex.vmem --profile=WinXPSP2x86 pstree > pstree.log
volatility_2.6_win64_standalone.exe -f .\cridex.vmem --profile=WinXPSP2x86 psxview > psxview.log

각각 살펴보길 권장한다.

pslist는 프로세스를 시각을 기준으로 볼 수 있고

pstree는 트리 형태로 볼 수 있고

psxview는 숨겨진 프로세스와 pslist, psscan에 True인지 False인지 확인해볼 수 있다.

1.3 커맨드 입력

이제 cmdline, cmdscan, consoles를 확인해볼 차례이다.

다음과 같이 한번에 입력한 후 확인해본 결과이다.

volatility_2.6_win64_standalone.exe -f .\cridex.vmem --profile=WinXPSP2x86 cmdline > cmdline.log
volatility_2.6_win64_standalone.exe -f .\cridex.vmem --profile=WinXPSP2x86 cmdscan > cmdscan.log
volatility_2.6_win64_standalone.exe -f .\cridex.vmem --profile=WinXPSP2x86 consoles > consoles.log

위 결과 cmdline을 제외한 나머지는 내용물이 아무것도 없었다.

그런데 이 부분에서는 딱히 의미있는 정보를 찾기는 잘 모르겠다. 그래서 다음으로 넘어간다.

1.4 네트워크 확인

이제 어떠한 네트워크 통신이 있었는지 확인해볼 것이다.

connections, netscan을 이용해서 찾아본다. 그런데 XP에서는 netscan이 지원하지 않는 모양이다.. 어쩔 수 없이 connections로 확인해본다.

volatility_2.6_win64_standalone.exe -f .\cridex.vmem --profile=WinXPSP2x86 connections > connections.log

다음 사진으로 결과가 나왔는데 누가 봐도 이게 너무 수상하게 한 개만 통신(Local <-> Remote)이 되고 있고 PID또한 확인해볼 수 있었다.

위에서 보았던 프로세스 정보를 토대로 1484가 뭔지 찾아보면 파일탐색기로 이걸로 연게 reader_sl.exe 인것을 알 수 있었다.

그렇다면 의심스러워 했던 해당 파일을 제대로 확인해볼 때가 되었다.

reader_sl의 PID 는 1640이다.

1.5 reader_sl 오프셋 값 찾기

filescan, dumfiles로 reader_sl 의 정확한 오프셋 값을 알아보겠다.

volatility_2.6_win64_standalone.exe -f .\cridex.vmem --profile=WinXPSP2x86 filescan > filescan.log

이렇게 다음 사진처럼 reader_sl 을 ctrl + f 로 해당 문자열을 찾았고 해당 위치의 정확한 offset 값인 0x00000000023ccf90을 알아내었다.

이제 reader_sl파일을 덤프해서 바이러스 토탈에서 바이러스인지 한번 판단해보자

1.6 reader_sl 파일 바이러스 체크

다음과 같이 dumpfiles로 -Q 옵션을 주고 offset값 그리고 -D 옵션 주고 files 디렉터리에(내가 추가로 만듬) -n 옵션을 주겠다라는 뜻이다.

volatility_2.6_win64_standalone.exe -f .\cridex.vmem --profile=WinXPSP2x86 dumpfiles -Q 0x00000000023ccf90 -D .\files\ -n

이제 다음과 같이 두가지 파일 .img, .dat 파일이 존재하는데 둘다 똑같으니까 그냥 아무거나 바이러스 토탈에다가 넣어주도록 하겠다.

위 사진처럼 떴는데 이정도면 바이러스일만 하다고 추측이 가능하다. 하지만 더 확실하게 검증해주기 위해서 메모리 덤프도 진행해주고 최종적으로 확인해보도록 하겠다.

1.7 메모리 덤프 악성코드 파일 확인

memdump로 덤프 확인을 다음과 같이 진행하였다

volatility_2.6_win64_standalone.exe -f .\cridex.vmem --profile=WinXPSP2x86 memdump -p 1640 -D .\dumps\

dumps는 내가 따로 디렉터리를 만들어 해당 공간에 저장해서 따로 볼려고 만든 것이다.

그냥 메모리 덤프한 것을 보면 쓰레기값이 상당하기에 strings를 이용해 문자열을 가져올 것이다.

다음과 같이 입력한다.

strings .\dumps\1640.dmp > strings_1640.log

시간이 꽤 걸릴 것이다. 만약 여기서 그냥 바로 나온다면 잘 안된 것이다. 바로 나올 때 해결 방법은 커맨드 입력을 strings 한번 입력해준다

strings

이후 어떤 창이 뜨는데 무슨 규칙? 법? 뭔지 모르겠지만 일단 agree해준다 그래야 정상 작동된다.

이제 확인해보니 이전에 확인해보았던 네트워크 통신에 있는 IP를 검색해주었더니 IP 흔적이 남아있었다.

또 다음과 같이 살펴보니 bank관련된 문자열이 굉장히 많이 있는 것으로 보아 bank관련된 악성파일인 것을 추측해볼 수 있었다.

1.8 진짜 바이러스 토탈 확인

이제 진짜 악성파일일 것 같기에 procdump로 확인해본다 다음과 같이 입력해준다.

volatility_2.6_win64_standalone.exe -f .\cridex.vmem --profile=WinXPSP2x86 procdump -p
1640 -D .\dumps\

해당 파일을 바이러스 토탈에 올려보니 다음과 같은 결과가 나왔다.

이건 이제 바이러스가 확실하다. 이는 확실한 증거임으로

악성파일임이 증명이 되었다.

목차
1. Amcache.hve 파일 소개
2. Amcache.hve 파일 위치 및 구조
3. Amcache.hve 파일 분석(방법)
4. Amcache.hve SHA-1 값 
5. 결론
 

1. Amcache.hve 파일 소개

Amcache.hve 파일은 본래 윈도우 7에서 사용하던 'RecentFileCache.bcf' 아티팩트를 윈도우 8이상의 운영 체제에서 사용되는 아티팩트로 계승되었습니다. 이 파일은 Application Compatibility Cache의 줄임말입니다.
시스템에서 실행된 프로그램과 관련된 정보를 저장합니다.
레지스트리 일부는 아니지만, 하이브 구조를 가지고 있어 하이브 형식으로 저장되며, 프로그램 실행 기록, 파일 경로, 타임스탬프 등 다양한 정보를 가지고 있습니다.
 

2. Amcache.hve 파일 위치 및 구조

Amcache.hve 경로 : C:\Windows\AppCompat\Programs\Amache.hve (%systemroot%/appcompat/Programs/Amcache.hve)
이 파일은 하이브 형식으로 저장되며 주요키로는 다음과 같습니다.
 
- Root\File : 실행된 프로그램의 파일 경로, 크기, 타임스탬프 등의 정보를 저장
- Root\Programs : 실행된 프로그램의 이름, 버전, 언어 등의 정보를 저장합니다.
- Root\InventoryApplicationFile : 설치된 프로그램의 파일 정보를 저장합니다.
- Root\InventoryApplication : 설치된 프로그램의 이름, 버전, 언어 등의 정보를 저장합니다.

3. Amcache.hve 파일 분석
 

파일을 분석하는데 Registry Explorer 를 사용하였습니다. 이 도구를 이용해 Amcache.hve 파일에 접근합니다(관리자 권한 실행)

위 사진 처럼 내 디바이스의 OS가 언제 설치 되었는지 그 OS의 언어 Pro인지와 같은 정보들도 확인 가능합니다.

위 사진처럼 인벤토리 응용파일 폴더 안에서 확인 해본 결고 언제 내가 Dism 파일을 설치 했는지와 경로까지 다 나오는 것 또한 확인이 가능했습니다.
맨 오른쪽에 있는 값은 SHA-1 해시를 나타내는데 SHA-1은 해시값이 이미 알려진 악성프로그램과 비교해서 악성프로그램의 여부도 확인 가능합니다.
 

4. Amcache.hve SHA-1 값 

Amcache.hve 파일에는 실행된 프로그램의 SHA-1 해시값이 저장될 수 있는데 이는 프로그램의 "무결성" 을 확인하고 변조 여부를 판단하는데 큰 역할을 합니다. 하지만 이러한 해시값에 제한 사항이 존재하는데 그 사항은 다음과 같습니다.
- 프로그램의 크기가 일정 크기(약1MB)이상인 경우, SHA-1 해시값이 부정확하게 기록될 수 있습니다.
- SHA-1해시는 Windows 성능상의 이유로 전체 파일을 해시하지 않고 파일의 처음 31,457,280Byte만 저장됩니다. 따라서 파일이 해당 바이트를 넘어버리면 처음 바이트만 해시값에 사용됨으로 그 이후의 값은 무결성은 체크가 되지않는다는 것을 알 수 있습니다.
 
 
 

5. 결론

 
Amcache.hve 파일은 윈도우 8 이상의 시스템에서 실행된 프로그램과 관련된 중요한 정보를 저장하는 아티팩트입니다.
이러한 아티팩트는 포렌식 조사에 필수적인 정보를 얻을 수 있기에 포렌식을 하면 반드시 알아야하는 아티팩트입니다.
물론 만능은 아니기에 4번에서 말한 제한 사항 SHA-1해시 값의 부정확성, 사용자가 수정할 수도 있다는 점을 사전에 알고 있어야 한다는 것입니다.
 
 
 
지금까지 Amcahce.hve 파일에 대해서 알아 보았습니다.