스테가노그래피란 이미지 파일이나 mp3 같은 파일에 중요하거나 기밀적인 파일을 넣어 그 존재를 숨기려 하는 것이라고 간략하게 말할 수가 있다. 예를 들어 드라마 유령을 봤다면 한번쯤은 스테가노그래피에 대해 들어보았을 것이다. 사진에 특정한 파일을 숨겨놓고, 제 3자로부터 해당 파일을 은닉시키려는 방법 중에 하나이자, 일상이나 평범한 사진 안에 파일을 넣는다면 인지하기 조차 힘든 방법이다. 

대략적인 구성은 위와 같다. 커버 파일과 은닉시키고자하는 파일이 있으며 스테고어플리케이션을 통해 스테고파일을 생성할 수가 있다. 이름에서와 같이 스테고파일은 커버 파일과 같은 모양이지만 그 안에 은닉하고자했던 데이터가 숨겨져있다. 이제 밑에서 직접 실습을 통해 어떠한 방식으로 진행되는지 알아보자

Practice - Input

이를 실습하기 위해선 간단한 툴이 있으면 된다. 여기서 사용할 도구는 OpenStego로 조작 또한 간단하며 자체적으로 압축을 해주는 것 같다. 스테가노그래피에 대하여 공부를 하던 중 은닉하고자 하는 파일의 데이터가 그대로 노출되기에 HxD같이 바이너리를 보아 시그니처를 찾을 수도 있으며 문자열 또한 그대로 나타난다고 되어있었다(이미지 파일인데 문자열이 존재한다는 것 자체가 의심을 받기에 충분하다). 하지만 아래에서 보겠지만, 이 툴을 사용하였을땐 시그니처나 문자열이 그대로 나타나지 않아 은닉에 더욱 도움이 되는 것 같다. 해당 툴은 http://www.openstego.com/ 여기서 다운을 받으면 된다.

해당 툴을 열어 넣고자 하는 파일을 Message File에 경로를 설정해주고 Cover File로는 보여지고자 하는 파일을 설정해 준다. 그리고 Otput Stego File에는 파일을 은닉시킨후 저장하고자 하는 경로와 이름을 설정해주면 된다.

비밀번호 또한 설정을 할 수가 있는데 여기선 임의로 "1234"로 진행하였다. 모든 설정을 끝마치고 Hide Data를 누르면 아래와 같이 성공 메세지박스를 확인할 수가 있으며, 이제 Output Stego File의 경로로 지정한 곳에 간다면 해당 파일이 존재하는 것을 확인할 수가 있을 것이다.

아래는 해당 파일의 결과이다. 왼쪽의 사진을 보면 결산 보고서의 양식인 것을 알 수가 있으며, 이는 회사원이라면 한번쯤은 볼 수가 있다. 만약 해당 회사에서 이러한 양식이 아닐 경우 의심 받을 수는 있지만, 여기선 일반적인 실습이므로 예외 사항은 제외시키고 시나리오를 이어나간다. 결과 파일과 커버 파일의 그림이 일치하는 것을 볼 수가 있다. 하지만 이미 오른쪽 사진의 .png 파일에는 은닉하고자 했던 데이터가 들어가 있다.

하지만 HxD로 열어서 확인을 했을 때는 전혀 다른 결과를 발견할 수가 있다(물론 Hash 값도 상이하다). 파일의 시그니처는 둘다 같게 시작하지만 이후의 데이터 부분에서는 서로 다른 내용인 것을 확인할 수가 있으며, 여기서 삽입했던 readme.txt의 내용은 "Hello World!" 이지만 해당 문자열을 검색해도 발견되지가 않았으며, 이후에 추가적으로 Cover File 안에 다른 .png를 새로 넣어봤지만 .png의 시그니처인 "PNG"가 발견되지가 않았다는 것을 통해 해당 툴이 자체적으로 인코딩하여 데이터 은닉에 도움을 주는 것 같다.

Practice - Output

은닉했던 데이터를 다시 산출하는 방법 또한 간단하다. Input Stego File에 위에서 결과로 나왔던 파일을 지정해주고, Output Folder for Message File의 부분에는 산출된 파일을 저장할 경로를 지정해주면 된다. 그리고 위에서 걸었던 패스워드인 "1234"를 입력해주고 Extract Data를 눌러준다.

과정이 완료되면 성공 메세지 박스가 뜨게되며 지정했던 경로에 은닉되었던 데이터가 나오는 것을 확인할 수가 있다. 숨겨놓았던 데이터 그대로 readme.txt라는 이름부터 시작하여 "Hello World!" 라는 문자열까지 그대로 나타나는 것을 확인할 수가 있다. 이를 통해 은닉데이터의 손실이 없음을 알 수가 있다.

Conclusion

스테가노그래피에 대해서 알아보았는데, 이 기술 또한 이전에 비하여 발전이 된 것임에는 틀림없다. 예전에 작성된 글들을 보면 압축이나 암호화 되지 않아 바이너리를 확인하면 해당 시그니처를 쉽게 확인할 수가 있었지만, 이제는 툴에 의해 자체적으로 압축(혹은 암호화)이 되어 시그니처나 헤더, 문자열 등을 확인하여 은닉데이터의 존재여부를 확인하기가 어렵다. 

이러한 스테가노그래피는 물론 악용의 소지가 크다고 볼 수가 있다. 기업의 중요 문서를 유출한다던지 개인정보를 유출할때 이러한 방법을 통해 범행 사실을 확인하는데 곤란을 겪기 때문이다. 하지만 이를 반대로 개인의 데이터를 숨기는데 사용할 수도 있다. 중요한 문서의 경우 이러한 기법을 통해 원격으로 접속한 해커로부터 아무렇지 않은 파일인척 그 데이터를 숨겨 놓을 수 있기 때문이다.

결론은 이 역시 쓰기 나름이다. 그렇다고 막상 이러한 기법을 통해 개인 정보를 보관하기에는 귀찮기도 하다. 그 정도의 꼼꼼함이 존재하지 않기에 그냥 본인의 컴퓨터는 본인이 잘 관리하는 것이 최고인 것 같다.

ICON

윈도우에는 다양한 아이콘들이 존재한다. 윈도우 탐색기는 파일 형식에 따라 다양한 아이콘을 표현하며 아이콘캐시는 썸네일캐시와 비슷하게 미리 캐시해 둔 후 재방문시 빠르게 로드하므로 성능을 향상시키는 기능을 한다. 

이러한 아이콘을 캐시시키는 시점으로는 폴더 내용 확인 시 로드되는 아이콘을 캐시하며, 인터넷에서 파일을 다운받았을 경우에는 폴더내용을 확인하지 않더라도 자동으로 캐시가 되며, 폴더를 열지 않아도 "수정시간"을 기준으로 최근 2개의 아이템이 캐시된다. 흔기본적인 아이콘의 경우에는 %Systemroot%\system32\shell32.dll에 존재하고 있다.

Cache

응용 프로그램의 경우에는 서로 아이콘이 상이한데 이는 리소스 섹션에 포함된 아이콘을 읽어왔기 때문이다. 하지만 매번 해당 폴더에 들어갈 때마다 리소스섹션을 읽어 아이콘을 나타내는 것은 매우 소모적인 활동이므로 이러한 아이콘들을 캐시하므로 인하여 비효율을 줄이고자 하는 것이다.

이러한 아이콘이 저장된 캐시는 %UserProfile%\AppData\Local\IconCache.db 의 형태로 존재하고 있으며, 또한 아이콘 캐시의 경우에는 윈도우 시작 시에 메모리에 로드되며 종료 시에 아이콘 캐시를 업데이트 한다. 다시말하자면 재부팅 전까지는 새로 캐시된 내용을 확인할 수가 없다는 것이다.

Analysis

IconCache Viewer를 통하여 IconCache.db파일을 열어서 확인해보면 리시트의 형태로 출력이 되는 것을 확인할 수가 있다. 여기서 "Search"를 통하여 의심스러운 파일의 이름을 입력해서 검색을 하거나 직접 어떤 프로그램들의 아이콘이 형성되어 있는지를 확인할 수가 있다.

활용

1. 외부저장매체 사용 흔적 (External Storage Artifacts)
   로컬 시스템에 외부저장매체를 연결하고 탐색기를 통해 외부저장매체를 확인하면 저장매체에 위치한 아이콘이 로컬에 캐시된다. 이를 통해 외부저장매체의 연결 흔적을 밝혀낼 수도 있을 것이다. 다만, 그러기 위해서는 외부저장매체에 아이콘 리소스를 포함한 EXE 파일이 존재해야 한다. 유일한 아이콘이 아니라면 저장매체를 특정하기는 어려울 것이므로 다른 주장을 뒷받침 하는 용도로 사용될 수 있을 것이다.
2. 안티포렌식 도구 사용 흔적 (Anti-Forensics Artifacts)
   전문적인 안티포렌식 도구는 대부분 고유한 아이콘을 가진 무료 혹은 상용 도구이다. 해당 시스템에서 안티포렌식 도구를 사용했다면 아이콘이 캐시 파일에 캐시되었을 가능성이 높다.
3. 광학드라이브 사용 흔적 (Optical Drive Artifacts)
   로컬 시스템에 광학드라이브는 보통 고정적인 드라이브에 할당되어 있다. 따라서, 캐시된 아이콘 경로의 드라이브 문자를 확인하여 광학드라이브에서 프로그램을 실행시켰는지 여부를 알아낼 수 있다.
4. 악성코드 흔적 (Malware Artifacts)
   악성코드(EXE)에 아이콘 리소스가 있으면 캐시 파일에 캐시되므로 아이콘 경로를 통해 악성코드의 저장 경로를 알아낼 수 있다. 하지만, 애드웨어류를 제외하고는 대부분의 악성코드가 아이콘 리소스를 포함하지 않으므로 큰 효과를 기대하기는 어렵다.
5. 프로그램 사용 흔적 (Application Artifacts)
   앞서 언급한 안티포렌식 도구를 제외하더라도 고유한 아이콘을 가진 프로그램이라면 캐시 파일에서 설치 혹은 사용 흔적을 알아낼 수 있다.

Conclusion

이러한 아이콘 캐시의 경우 찾고자 하는 파일이 고유한 아이콘을 가지고 있을때 해당 시스템에서 실행이 된 적이 있는지를 확인할 수 있게 해준다. 최근에는 안티포렌식 기법이 널리 알려져 공격자 혹은 범죄자들이 이를 적극 이용하고 있다. 이에 따라 포렌식 조사관은 조사에 있어 일부 흔적만 가지고 판단할 것이 아니라 시스템의 다양한 아티팩트를 적극적으로 활용해야 한다. 이런 관점에서 아이콘 캐시 파일은 매우 유용한 아티팩트일 것이다

Reference

http://forensic-proof.com/archives/5168

Thumbnail

썸네일이란 어떠한 파일이 존재할때, 그 파일의 미리보기를 나타내어주는 것으로 파일을 탐색할 때 알아보기 쉽게 나타내는 것으로 흔히 동영상이나 사진의 경우 작게 캡처가 되어 미리보기의 형태로 나타내어진다. 그로 인해 우리는 원하는 파일을 하나씩 모두 열어볼 필요가 없이 썸네일을 통하여 찾을 수가 있다. 모든 파일에서 지원하는 것은 아니며 운영체제 마다 차이가 있지만 JPEG, avi 등 같은 파일에서 흔히 쉽게 볼 수가 있다.

그래픽 이미지를 축소하였기에 많은 양의 이미지를 빠르게 탐색할 수 있게 해주며, 초기 방문시 썸네일을 캐시해두고 재방문시 캐시된 데이터를 보여줌으로 인하여 성능을 향상 시킨다.또한 한번 저장된 썸네일은 원본 파일이 삭제되더라도 삭제되지 않기에 어떠한 행위에 대하여 흔적을 지웠지만 썸네일 흔적을 지우지 않는다면 알아차릴 수가 있다.

썸네일의 저장 경로는 %UserProfile%\AppData\Local\Microsoft\Windows\Explorer 에 각 형태에 맞는 곳에 캐시의 형태로 저장이 된다. 미리보기를 한번이라도 했다면 썸네일이 형성이 되며, 이 썸네일의 경우 원본 파일이 삭제되더라도 따로 저장이 되어있다. XP 까지는 각 폴더에 해당 썸네일이 Thumbs.db에 존재(숨김파일형태)하고 있지만, 그 이후의 운영체제부터는 Thubmcache_**.db의 형태로 저장이 된다.

Structure

thumbcache_##.db 파일은 헤더에 이어서 "CMMM"으로 시작하는 시그니처를 단위로 각각의 썸네일을 저장하고 있다. 다음은 각 썸네일의 엔트리 형식이다. 엔트리에 저장되는 Unique ID를 "thumbcache_##.db에서 검색해보면 해당 썸네일의 인덱싱 정보가 저장된 부분으로 이동한다.

Analysis

썸네일 캐시를 분석하기 위하여 Thumbcache Viewer를 사용할 것이다. 이를 통하여 thumbcache_##.db 파일을 열어서 목록을 확인해보면 본인이 여지껏 봤었던 사진이나 문서, 동영상 등의 썸네일을 확인할 수가 있다. 하나 하나 확인을 해보면 예전에 봤었던 문서나 동영상의 썸네일도 존재해 뭔가 신기할 따름이다.

Conclusion

이러한 썸네일을 통하여 포렌식의 많은 면에서 사용이 가능하다. 그래픽이나 동영상, 문서같은 파일들이 존재했었는지의 여부를 파악할 수가 있으며 문서파일의 경우 첫 페이지가 썸네일이 되기 때문에 문서의 내용을 확인하여 저작권에 위배되는지 확인이 가능하다. 마지막으로는 이러한 썸네일을 통하여 음란물 등의 존재여부 또한 확인할 수가 있다.

추가적으로 썸네일이 삭제된 경우에는 데이터 복구나 카빙을 통하여 파일을 복구시켜서 삭제를 했더라도 어느정도의 희망을 가지고 확인해보는 것도 괜찮을 것같다고 생각한다. 이처럼 여러 방식들을 염두하고 분석을 해야할 것 같다.

Reference

http://forensic-proof.com/archives/2092

파일의 삭제

컴퓨터를 사용하다가 파일을 복구하고자 할 때가 존재한다. 본인도 그러한 경험으로 인해 컴맹일때에도 파일을 복구시켜주는 프로그램을 찾아보곤 했었다. 보통 파일을 복구하는 원리에 대해서는 관심이 없고 단지 복구가 되냐 안되느냐에만 관심이 있었지만 현재에는 어떻게 진행이 되는 것인지 궁금하므로 공부해보았다. 이제 이에 대하여 알아보자.

아래의 그림은 파일 시스템의 추상적인 구조를 나타낸다. 여기서 크게 메타영역과 데이터 영역이 존재하는데, 어떠한 파일이 하나 존재할 경우 두 영역에 모두 존재하게 된다. 프로그램을 실행시킬 경우 PC에선 메타영역에서 해당하는 파일에 대한 정보를 참고한 후 가리키는 데이터 영역으로 가서 프로그램을 실행하게 한다.

아래와 같이 두개의 파일이 데이터 영역과 메타영역에 존재하는 것을 확인할 수가 있다. 이러한 상태에서 b.txt라는 파일을 삭제한다면 b.txt의 데이터영역과 메타영역은 비할당 영역을 표시가 된다. 하지만 데이터가 삭제되는 것은 아니다. 단지 나타나있지 않아 우리가 사용을 할 수 없을 뿐이다.

이러한 상태에서 파일을 복구하는 방법으로는 크게 2가지로 나눌 수가 있다. 하나는 메타 데이터를 이용하여 파일을 복구하는 방법(데이터 복구)이고, 다른 하나는 파일 카빙을 통하여 복구를 하는 것이다. 이에 대하여 알아보자.

데이터 복구

데이터 복구란 메타 데이터를 이용하여 파일을 복구하는 것으로 메타데이터에 대해 알아보자면,속성정보라고도 하며 대량의 정보 가운데서 찾고 있는 정보를 효율적으로 찾아내서 이용하기 위해 일정한 규칙에 따라 콘텐츠에 대하여 부여되는 데이터이다. 여기에는 콘텐츠의 위치와 내용, 작성자에 관한 정보, 권리조건, 이용조건, 이용내력등이 기록되어 있다.

아래의 그림과 같이 파일을 삭제 되었지만 메타 영역과 데이터 영역에 있는 데이터가 덮어씌워지거나 변질되지 않는한 메타영역은 올바른 데이터 영역을 가리키고 있다. 따라서 이러한 메타 영역의 데이터가 잘 보존되어있다면 파일의 복구는 별도의 전문지식이 필요없이 메타데이터가 가리키는 곳을 따라가 데이터를 복구하면 되기에 비교적 비전문적이라 할 수 있다.

하지만 만약 메타 영역의 데이터가 변질되거나 삭제되었을 경우 이러한 방법은 사용을 할 수가 없게 된다. 그러므로 파일을 올바르게 복구하기 위해서는 두 영역에 있는 데이터들 모두에게 손실이 없어야 한다.

파일 카빙

메타영역에 있는 데이터가 손실되었을때 우리는 위의 방법을 통해서는 복구를 할 수가 없다. 더이상 메타영역이 올바른 데이터 영역을 가리키고 있지 않기 때문이다. 이럴때 사용하는 방법이 바로 카빙이다. 카빙은 하나의 시그니처나 문자열 등 파일의 내부 구조를 통하여 파일을 복구하는 방법이다.

카빙을 통하여 데이터를 복구하려면 파일의 구조에 대해 알아야 한다. 하지만 각 파일마다 구조가 상이하며 그 종류 또한 매우 다양하게 존재한다. 파일의 각 시그니처에 대해서는 여기를 참고하자. http://kali-km.tistory.com/entry/File-Signature 

파일 카빙에는 연속적으로 데이터가 저장된 형태와 비연속적인 형태가 있는데 비연속적인 형태의 경우 더 많은 지식을 필요로 하기에 다루지 않을 것이며 연속적으로 저장된 파일의 카빙에 있어서도 4가지 방법 중 2가지 방법에 대하여 알아볼 것이다.

헤더/푸터 카빙

헤더와 푸터를 통한 카빙의 경우 데이터가 연속적으로 저장되어있을 경우 손쉽게 찾아 복구가 가능하다. 여기서 헤더란 파일의 시작점을 알리는 값이며 푸터란 파일의 종료지점을 가리키는 값이다. 아래의 그림을 보면 연속적으로 저장되어 있는 두개의 헤더들과 푸터들을 볼 수가 있다.

이 방식을 사용할 수 있는 대표적인 구조에는 JPEG가 있다. JPEG의 경우 FFD8로 시작하여 FFD9로 끝나는 값을 가지고 있기에 카빙 툴을 직접 만들려고 한다면 이에 해당하는 값에서 데이터를 복구하도록 하면 된다.

파일 크기 카빙 방식

데이터에 헤더는 존재하지만 푸터가 존재하지 않을 경우, 위의 방식을 통하여 사용할 수가 없다. 하지만 헤더에 파일의 크기를 나타내어 준다면 우리는 어디까지가 이 프로그램에 해당하는지를 확인할 수가 있다. 이러한 방법을 통하여 복구하는 것이 파일 크기를 이용하는 방식이다.

PE 구조의 경우 MZ를 통하여 파일의 시작점을 확인할 수가 있으며, 0x38에 존재하는 값을 통하여 PE 시그니처를 확인한 후 헤더의 크기와 섹션헤더들을 참고하여 전체적인 파일의 크기를 구할 수가 있다.

카빙의 제한

이러한 카빙 또한 제한이 되는 경우가 존재하는데 바로 데이터 영역이 손실되었을 경우이다. 이러한 경우에는 이미 기존의 데이터가 사라지거나 손실되었기에 당연히 복구가 불가능하다.

또 다른 경우는 바로 분할되어 있는 경우이다. 분할 저장되어있는 경우에는 포렌식에 입문 한지 얼마 안된 나에게는 복구가 불가능하다는 문서가 많이 보이긴 하지만 딱 하나의 문서에서는 복잡하게나마 복구를 할 수 있다고 나와 있다. 이는 초보 확실히 초보자의 영역이 아니기에 제한적이라고 표시하였다.

Foremost

카빙을 실습해보기 위하여 선택한 툴로는 foremost이다. 직접 카빙툴을 만들어보는 것도 매우 좋지만, 해당 파일의 구조에 따라 다른 방법을 사용하여야 하기에 모든 것을 구현하기는 번거로울 것같다. 실습을 위해서 자주 사용하는 USB를 FTK Imager를 통하여 이미징을 하였고 분할된 파일 중에서 하나를 Test_data.005라 명명하였다. 이제 이 파일과 foremost를 가지고 실습을 진행해보자.

Foremost는 아래의 사진에서 왼쪽의 콘솔창과 같은 파일 구조의 복구를 지원하며 이 툴은 http://foremost.sourceforge.net/ 에서 다운로드 하거나 Kali Linux의 경우에는 기본적으로 내장되어 있으니 활용하면 된다.복구할 파일의 타입을 이 중에서 선택하면 된다.

사용 방법은 비교적 간단하다. foremost 와 함께 인자로 복구할 타입을 설정해주며 input 파일과 output 경로를 설정해주면 된다. 해당 과정을 보고 싶다면 -v를 추가로 인자로 넘겨주면 진행과정을 아래와 같이 지켜볼 수가 있다. 오른쪽의 2장의 사진은 복구를 한 결과이다. 

결론

이러한 데이터 복구는 일반 사용자들에게도 좋은 기능을 하지만, 포렌식적 관점에서 또한 중요하다고 생각한다. 어떠한 대상자의 디스크를 이미징하여 조사를 할때 삭제된 파일 중에서 범법행위를 증명할 만한 자료들이 충분히 발견될 수 있기 때문이다. 하나의 파일이 전체적인 분석의 실마리를 제공하기도 하는 만큼 카빙을 통해 파일을 복구하고 분석하는 것은 포렌식에 있어 매우 중요하다. 특히 최근 자주 등장하는 공격이후 자기 자신을 삭제하는 악성코드를 카빙을 이용해 복구할 수도 있으므로 카빙을 이용해 분석하는 것을 강력히 추천한다.

위와 같은 방법들을 통해 파일 시스템에서 이미지 파일을 카빙한다면 삭제되거나 현재 존재하는 이미지 파일을 복구할 수 있다. 이때 복구된 파일이 사진이라면 사진이 찍힌 위치나 시간, 카메라 기종에 대한 정보를 확인해 사건을 검증하는 자료로 활용할 수도 있다. 데이터 유출 사고라면 스테가노그라피 기법을 이용해 데이터를 점검할 수 있다.

특히 카빙을 수행하면 더미 파일에서 패턴에 맞는 내용을 무작위로 추출하게 되는데 이때 '내보내기'된 파일의 내용도 확인할 수 있어 보유하고 있던 불법적인 데이터의 수를 파악할 수 있다. 또한 아이콘이나 기타 이미지로 설치된 어플리케이션이나 장치 사용자의 프로필 정보 등의 로그도 확인할 수가 있다. 이외에도 이미지 파일은 대표적인 악성코드 유포의 수단이자 악의적인 데이터 유출의 수단으로 이용될 수 있다는 점에서 카빙은 포렌식에 있어 상당히 중요한 가치를 가진다.

출처 : http://forensic-proof.com/archives/300

예전 기준인 것 같기는 하나 어느정도의 틀을 알고 있어서 나쁠건 없기에 일단 업로드

Prefetch File

프리패치는 부팅할 때나 응용프로그램을 실행할 때 속도를 높이기 위해 사용한다. 윈도우에서 메모리를 효율적으로 관리하기 위한 한 방법이기도 하다. 실행파일이 사용하는 시스템 자원을 프리패치 파일에 저장해두고 부팅, 응용프로그램 실행시 미리 저장된 정보를 메모리에서 실행하여 속도를 향상시킨다. 부팅시에는 120동안 모니터링하고, 응용프로그램 시작시에는 10초를 모니터링 한 후, 모니터링한 정보로 프리패치 파일을 생성한다. 경로는 %Systemroot%Prefetch 에 저장이 된다.

응용프로그램의 경우 프리패치 파일이 남기 위해서는 10초간 메모리에 올라가있어야한다는 말이며, 개수에 있어서도 제한이 있는데 128개의 프리패치를 갖으며, 이 개수를 초과할 경우 오래된 프리패치 파일부터 삭제가 되어 새로운 pf 파일이 형성이 된다.

Windows 10 

프리패치 파일에 공부를 하기 위하여 자료를 찾던 중 Prefetch Format을 내 PC에서 확인하기 위하여 파일을 HxD로 확인하였을 때 많이 당황하게 되었다. SCCA 시그니쳐가 보여야하는데 보이지 않고 이상한 MAM 시그니쳐만 확인이 되었다.

이에 대하여 알아보니 이전에는 바로 내용들이 보였지만 최근의 운영체제에선 압축을 하여 바로 원하는 문자열들을 확인할 수가 없다. 하지만 간단한 툴들이나 코드를 이용해 바로 확인이 가능하도록 할 수가 있다.

아래는 Python으로 Decompree 한 상태이다. 이제서야 본격적인 공부를 시작할 수가 있다. 이를 해제하기 위한 Python 코드는 블로그에 올렸으니 확인을 한 후 어떤 코드가 사용되었는지 한번 보는 것이 좋다. 참고로 GrtHub에서 퍼온 것이다.             http://kali-km.tistory.com/entry/XPRESS-Decompress-by-Python

*winprefetchview를 통하여 확인할 경우 위와 같은 디컴프레스 과정이 필요없이 바로 내용을 확인이 가능하다. 

Registry

프리패치에 대한 설정은 레지스트리를 통하여 변경할 수가 있다. 아래에 보면 EnablePrefetcher라는 키가 있는데 값이 0x3으로 설정되어있다. 이 값에 따라 사용하지 않거나 어플리케이션이나 부트 프리칭만을 사용하거나 둘다 사용하도록 설정 할 수가 있다.

기본값으로 0x3이 설정 되어있기 떄문에 별도의 수정을 하지 않는 이상 프리패치 파일들이 형성되며 이를 통하여 추가적인 분석이 가능하다.

외장 저장장치 사용흔적 확인

프리패치 파일에는 실행한 프로그램의 경로 또한 나타내어진다. 이를 통하여 해당 프로그램의 위치를 알 수가 있는데, 만약 프로그램이 USB에 담겨있던 프로그램이라면 이 또한 확인이 가능하다. 아래 사진에서와 같이 다른 프로그램들은 C:\로 시작하지만 이 경우에 있어선 독특하게 \VOLUME으로 시작하는것을 확인할 수가 있다. 이를 통해 우리는 외부저장장치에 있던 프로그램이 실행되었단 흔적을 찾을 수가 있다.

Format

운영체제에 따라 해당 오프셋의 위치가 다르긴 하지만 항목은 같다는 것을 알 수가 있다. 우선 첫 4바이트는 운영체제에 따른 Prefetch 버전을 나타내며 윈도우 XP의 경우 0x11이며 윈도우7의 경우 0x17등 버전은 아래의 표와 같다.

그 후SSCA 시그니처와 pf파일의 크기와 이름이 나오며 0x4C에 있는 4바이트의 값은 파일의 경로에 대한 MD5 해시값이다. 그리고 0x58의 위치에는 파일을 실행하기 위해서 메모리에 올라가야할 파일의 수를 나타내며 이 파일들의 목록은 0x64에서 가리키는 값의 오프셋에서 확인할 수가 있다. 그리고 0x6C에는 봄륨에 대한 정보 블록을 가리키는 오프셋이 나와 있다.

프리패치 파일을 통하여 확인할 수 있는 것들은 아래와 같이 정리해볼 수가 있다. 외장저장장치 사용흔적은 위에서 언급을 하였으니 확인을 할 수가 있다. 또한 SCCA 시그니처를 통해 파일 카빙을 할 수가 있으며, 삭제된 pf 파일이더라도 카빙이 가능하다. 악성코드의 흔적은 이름과 응용프로그램 실행 과정 등 종합적으로 고려하여 여부를 파악할 수가 있다.

추가

http://kali-km.tistory.com/entry/Windows-10-Prefetch-Parser  ; 윈도우 10 프리패치 분석 도구

참고

https://github.com/libyal/libscca/blob/master/documentation/Windows%20Prefetch%20File%20%28PF%29%20format.asciidoc

http://www.forensicswiki.org/wiki/Windows_Prefetch_File_Format

http://maj3sty.tistory.com/857

http://forensicswiki.org/wiki/Prefetch

http://blog.digital-forensics.it/2015/06/a-first-look-at-windows-10-prefetch.html

http://forensic-proof.com/wp-content/uploads/2013/07/FP-%ED%94%84%EB%A6%AC%EC%8A%88%ED%8D%BC-%ED%8C%A8%EC%B9%98-%ED%8F%AC%EB%A0%8C%EC%8B%9D-Pre-Superfetch-Forensics.pdf

http://forensic-proof.com/archives/6103

전통적인 컴퓨터 포렌식 방법론에서는 컴퓨터를 조사하기 전에 우선 전원 플러그를 뽑고 하드 드라이브의 이미지를 복사하는 것이 가장 기본적이었다. 하지만 최근에는 컴퓨팅 환경의 변화로 인해 저장 매체의 이미지 복사에 앞서 휘발성 정보를 먼저 수집하고 분석하는 쪽으로 방법론이 빠르게 이동하고 있다.

휘발성 정보에는 시스템 시간, 네트워크 연결 정보, 로그온 사용자 정보, 실행되고 있는 프로세스 정보 등이 있는데, 이런 정보는 컴퓨터가 꺼지고 나면 증발하듯 사라지기에 우선적으로 수집하여야 한다. 다시 말해 살아있는 시스템에서 수집 가능한 모든 정보의 수집과 분석, 그리고 이를 바탕으로 한 사고 처리까지가 담당범위이다.

1.1    라이브 리스폰스의 중요성

-       휘발성 저장장치에서만 찾을 수 있는 정보가 있다. 프로세스 목록, 열려있는 파일목록, 클립보드, 사용자 정보, 임시파일, 비밀번호 등을 포함하고 있으며 비휘발성 장치를 거치지 않고 바로 메모리에 로드되는 악성프로그램들이 존재하기에 이는 중요하다.

-       수집한 휘발성 정보를 우선적으로 평가함으로써 시스템의 대략적인 상태 파악 가능, 이를 통하여 조사의 세부 방향을 잡는데 기초적인 밑그림을 제공한다.

-       종료를 하기에 곤란한 상태에 있는 서버 컴퓨터와 같은 컴퓨터를 조사할 때 어쩔수 없이 라이브러리 상태에서 모든 증거를 수집하고 문제를 해결해야 한다.

1.2    시기

-       시간이 촉박하지만 않다면 항상 라이브 리스폰스를 수행하는 것이 좋은 판단이다.

-       비휘발성 저장장치에서 증거가 수정되거나 삭제되고 있는 상황에서 수행하는 것은 옳지않다. 예로 Secure Deletion & Secure Erase, Wiping과 같은 방법이 있다. 이런 의심이 들 경우 전원 플러그를 뽑는 것이 좋다. 이는 해커가 삭제하려는 파일보다 휘발성 증거들이 덜 중요할 수 있기 때문이다. 제한적인 휘발성 정보만 수집하고 싶다면 네트워크 연결정보와 메모리 덤프를 우선적으로 수집할 것을 권장한다.

-       사용하려는 도구들이 조사하고자 하는 윈도우 버전에서 충분한 검토가 이루어지지 않은 때에는 라이브 리스폰스를 수행하지 않는 것이 좋다. 이는 시스템에 미치는 영향을 전혀 예측할 수 없기 때문이다. (단, 이는 상황에 따라 조사관의 판단에 의해 용인 가능하다.)

1.3    원칙

-       휘발성 증거를 수집할 때 최우선으로 적용되는 원칙은 “원본에 대한 영향을 최소화 한다”는 것이다. 이는 동작중인 컴퓨터를 대상으로 하기 때문에 조사자의 휘발성 정보 수집행위가 시스템에 미치는 영향을 완전히 배제할 수 없다.

.

1.4    영향

-       메모리 : 도구를 실행하면 프로세스가 생성되고 실행 코드와 오브젝트드링 메모리에 적재된다. 이때 두 영역에서 수정 및 삭제가 발생한다. 첫째로, 프로세스는 메모리의 일정 영역을 점유하고 그 영역에 있던 이전 데이터를 덮어쓴다. 그 부분은 종료된 다른 프로세스가 사용하던 영역이거나, 임시데이터가 저장되어 있던 영역일 수 있다. 둘째로, 커널 오브젝트를 과리하는 시스템 테이블이 갱신된다. 테이블이 가득차 있다면 가장 오래된 항목이 자동 삭제된다.

-       네트워크 : 도구가 네트워크 기능을 이용한다면 시스템은 지정된 소켓을 열고 외부와 네트워크 연결을 맺는다. 방화벽 기능 활성화시 관련 로그가 기록되고 로그 파일이 쌓이면서 이전에 사용치 않던 HDD 영역을 사용하게 된다.

-       프리 패치 파일 : 윈도우는 새로운 프로그램이 실행될 때마다 Prefetch 파일을 만든다. 여기서 윈도우 XP에선 프리패치파일의 개수에 제한(120개)가 있기 떄문에 초과시 오래된 파일을 삭제한다.

-       레지스트리 : 라이브 리스폰스 도구들은 레지스트리에 접근하여 그 값을 사용한다. 윈도우 설치 정보를 찾아보거나, EULA(End User License Agreement)가 사용자에 의해 승인되었다는 것을 기록하기도 한다. 레지스트리에 대한 쓰기 작업은 레지스트리 키의 마지막 쓰기 시간 변경을 의미한다. 도구들은 이곳에 다양한 기록들을 남기게 된다.

-       DLL : 포렌식 도구가 DLL 파일을 필요로 한다면 해당 파일을 찾아서 읽을 것이며 파일의 접근 시간을 갱신할 것이다. 하지만 DLL 파일의 접근 시간 갱신은 크게 신경 쓸 필요가 없어 보인다. 하지만 사용하는 시스템 DLL이 이미 변조되거나 교체되었다면 문제는 달라진다.

-       로그 파일 : 도구가 에러를 발생시켰다면 기본적으로 그 정보는 이벤트 로그에 기록된다. 에러가 아니더라도 도구 자체가 이벤트 로그에 스스로 로그 기록을 남길 수 있다. 앞에서도 말했지만 이러한 로그들이 생성 될 때 하드 드라이브의 미할당 영역을 사용할 것이고, 이는 오래된 로그를 삭제할 수도 있다.

명심해야 할 것은 어떤 식으로 노력하든 라이브 리스폰스 도중에 실행하는 여러 도구와 조사관의 행위가 시스템에 전혀 영향을 미치지 않을 수는 없다. Write-Protection Device에 연결해서 하드를 카피하는 것과는 달리, 라이브 리스폰스는 중간에 어떤 보호 장치도 없으며 동작 중인 시스템을 대상으로 한다. 이 과정만으로도 시스템의 메모리, 레지스트리, 파일 시스템에 영향을 미친다. 따라서 영향의 배제가 아닌 최소화를 목적으로 해야 한다.

포렌식에서 여러 사전 준비 단계가 있고 하드웨어 준비, 소프트웨어 준비, 절차에 대한 준비로 나눌 수 있다. 하드웨어에는 분석용 컴퓨터나 장비들도 속하지만 증거물을 만질 때 사용할 장갑이나 사진기, 시계 등도 포함되며 소프트웨어엔 분석용 도구들과 라이브 리스폰스에서 사용할 도구가 포함된다. 절차는 증거의 수집과 분석, 그리고 최종 보고서 작성에 이르기까지의 일련의 합의된 과정을 의미한다.

2.1    도구 선택 단계

라이브 리스폰스에서 사용하는 도구는 적법한 절차를 통해 구해야 하고, 임의로 수정되거나 바이러스에 감염되지 않은 파일임을 증명할 수 있어야 한다. 컴퓨터 포렌식은 언제나 소송 같은 법적인 절차를 대비해야 하기 때문에 사용하는 도구들도 항상 법의 테두리 안에 있는 것들만 사용해야 한다.

2.2    도구 테스트 단계

도구를 선택했다면 다음은 그 도구들이 과연 예상했던 것처럼 잘 동작하는지 테스트하고, 시스템에 어떤 영향을 미치는지를 모니터링 할 차례이다. 한 버전에서 잘 동작하는 도구가 다른 버전 혹은 다른 서비스 팩에서도 잘 동작하리라는 보장은 없다. 따라서 라이브 리스폰스에 사용할 도구들은 다양한 버전과 서비스 팩에서 반복적으로 실행해 보고 확인해볼 필요가 있다.

2.3    문서화 단계

문서화는 포렌식 전반에 걸쳐 항상 적용되어야 하는 필수 사항이다. 선택한 도구들의 목록을 만들고 그것의 출처와 해시 값을 기록하라. 도구들을 테스트하고 테스트한 시스템의 환경과 그 결과, 그리고 그것이 시스템에 미치는 영향을 꼼꼼히 기록하자.

특히 도구가 시스템에 미치는 영향에 대한 문서화는 필수적이다. 이것을 게을리하면 실제 분석 과정에서 악성 프로그램이 시스템에 미친 영향과 사용한 도구가 미친 영향을 구별하지 못해서 큰 혼란을 겪게 된다.

2.4    모니터링과 문서화

라이브 리스폰스 도구들이 시스템에 어떤 영향을 미치는가를 문서화할 때 가장 중점을 두어야 하는 부분에는 세가지가 있다. 하나는 실행될 때 로드되는 DLL 파일 목록, 다음은 레지스트리 접근 정보, 마지막은 프로그램이 수정 및 생성하는 파일 목록이다. 이는 프로세스 모니터로 확인이 가능하다.

2.5   시스템 DLL 파일 사용하지 않기

앞에서 말한 바와 같이 라이브 리스폰스가 시스템에 미치는 영향을 완전히 없애는 것은 불가능하며, 최소화하는 방안에도 많은 걸림돌이 있다. 대상 시스템에 미치는 영향 중에서 가장 최소화하기 쉬운 것이 DLL파일이다.

이러한 DLL을 최소화 하기 위하여 상대적으로 적은 DLL을 로드하는 CLI 프로그램들로 도구들을 구성하는게 좋다. GUI의 경우 CLI에 비하여 많은 DLL을 로드하기 떄문이다. 이에 더해 시스템 DLL 파일을 사용하지 않는 방법에는 크게 3가지가 있다.

-    DLL 파일들을 실행 파일이 있는 폴더로 모두 복사

-      Dynamic-Link Library Redirection 기능을 이용

-      실행 파일의 코드를 수정

세가지 방법 중에서 로드되는 DLL 파일들을 실행 파일과 같은 폴더로 복사해 넣는 방법이 가장 간단하다. 그러나 별 효과가 없기에 실무에선 적합하지 않다. 프로세스가 필요한 DLL 파일을 찾기 위해 검색하는 폴더의 순서는 다음과 같다.

가장 높은 순위에 있는 SxS는 프로그램을 만들 때 컴파일러에서 별도의 옵션을 지정해야만 만들 수 있으며, 3번의 경우 코딩 시에 SetDllDirectory 함수를 넣어주어야만 한다. 따라서 이미 컴파일이 끝난 도구는 이를 응용할 수 없다. 그러므로 가장 간단하고 편리한 것이 2번의 방법이다.

2.6    파일 이름 변경

사용할 도구들이 확정되었다면 파일 이름을 원래의 것과 구별되는 것으로 변경하는 것이 좋다. 그렇지 않으면 기존 프로그램과 별도의 도구가 혼동될 경우가 있기 때문이다.

휘발성 정보에도 여러 종류가 존재하기에 어디에 우선순위를 두고 먼저 수집을 해야 할지 결정을 해야 한다. 이는 어떻게 기준을 잡느냐에 따라 다르므로 주관적이라 할 수 있다. 이제 이에 대하여 알아보자.

물리적 메모리는 수집하는데 시간이 가장 오래 걸림에도 불구하고 다른 정보들보다 먼저 수집하려는 이유는 대부분의 휘발성 정보들이 모두 메모리에 들어있기 때문에 물리적 메모리를 수집함으로써 그것들을 한번에 수집할 수 있고, 물리적 메모리 이외의 휘발성 정보들은 변조나 은폐가 가능하기 때문에 그 신뢰성이 물리적 메모리에 비해 떨어지기 때문이다.

표 출처 : 서강대 박종석 선임 - 활성 시스템 분석.pdf   2013.11.14