침해사고가 발생한 컴퓨터를 원격을 통해 검사 및 정보, 디스크 수집


이번 포스팅은 이전 포스팅으로 침해사고를 일으킨 서버를 대상으로 실습을 합니다.
fire-0.3.5b를 쓸 예정이며 fire는 포렌식에서 오래된 도구라고하는데 필자도 자세한 것은 잘 모르겠다. 
잘 아시는 분이 계시다면 알려주시면 감사하겠다. 





여기서 가상머신은 피해자 컴퓨터가 될 것이고 리얼머신은 피해자 컴퓨터의 정보를 가져오게 되는 분석자 컴퓨터가 된다.



먼저 vm에서 fire-0.3.5b.iso파일을 삽입한다.


가상머신으로 돌아와서 mount를 해준다.
mount /dev/cdrom media/cdrecorder/
여기서 잘 안될 가능성이 있는데.. 막 어떻게 하다보면 된다... 무책임한 소리지만 어쩌다보니 되었다.





위의 경로로 가면 파일이 있는 것을 확인 할 수 있다.




리얼머신으로 돌아와 nc를 통하여 포트를 오픈해두고 sh.IR로 값을 저장할 수 있도록 한다.




마지막에 있는 명령어를 입력하면 kk라고 입력한 곳 위까지 출력된다.
마지막 입력에 -w는 3초동안 응답이 없으면 timeout시키는 nc 명령어이다.



리얼머신에 nc를 보면 연결이 되었고 받은 것을 볼 수 있다.




nc가 있는 폴더로 가면 sh.IR 파일이 있고 열면 피해자 컴퓨터의 정보를 가져오는 것을 볼 수 있다.







이번에는 피해자 컴퓨터에 루트킷이 적용되었는지 검사해볼 것이다. 
위의 경로로 들어가보자.




그리고 리얼머신으로 돌아가 위의 명령어를 입력해주자
nc.exe -lvvp 4444 > rootkit.IR




그리고 가상머신으로 돌아와서 위의 명령어를 입력해준다.
./chkrootkit | ../linux2.2_x86/nc -n 192.168.56.1 4444 -w 3
chkrookit으로 검사한 결과를 nc를 통해 리얼머신으로 보내는 명령어이다.




가상머신에서 전송이 다됐을 때 결과이다.




리얼머신에서 보면 또 결과를 받은 것을 확인할 수 있다.




nc폴더에 rootkit.IR 파일을 열어보면 루트킷 체크를 한 것을 볼 수 있다.






이번에는 원격으로 덤프뜨는 것을 할것이다. 덤프에는 dd를 사용한다.
먼저 전송을 위하여 리얼머신에서 포트를 열어두고 disk.dd로 저장할 준비를 한다. 




위의 경로로가면 dd명령어가 있다. 위의 경로로 간다.




cat /etc/fstab
위에서 3번째 줄에 있는 /dev/VolGroup00/LogVol00를 복사한다.





./dd if=/dev/VolGroup00/LogVol00 bs=1024 | nc -n 192.168.56.1 4444 -w 3
bs는 한번에 읽어들일 바이트량을 표시하며 -n은 호스트와 포트를 숫자로만 받는다.




리얼머신에서 연결이 된 것을 확인 할 수 있다.
위의 상태에서 오래 진행된다.
c,c ls는 없어도 된다. 필자가 잘못 입력한 것이다. 



nc폴더에 도면 disk.dd가 생긴 것을 볼 수 있고 용량이 계속~계속~ 커가는 것을 볼 수 있다.
후에 이 파일을 가지고 분석하거나 복구하면 되겠다.




우리가 이번 포스팅을 통하여 했던 일련의 과정들을 간단히 해주는 툴이 있는데 그 툴은 autospy이다.
autospy는 FTK와 Encase를 적당히 가져온 툴로써 무료이다. 하지만 한국어를 지원하지 않는다.
autospy는 해부라는 의미를 가지고 있으며 구글에서 검색하여 이미지로 보면 상당히 혐오스러울수 있으니
절대로 누르지말고 바로 링크타고 들어가서 다운받도록하자. 


침해사고는 언제 어디서 발생할지 모른다.
 만약 침해사고가 발생한 컴퓨터가 원거리에 있으면 직접가서 조치하기가 어렵다. 그러므로 원격으로
빨리 정보를 수집하는 방법도 좋은 방법이라 생각된다. 
침해사고를 대응하려면 여러가지 방법을 알아두고 숙달해야 할 필요성이 느껴진다.


NTFS파일 시스템에서 직접 삭제된 파일 복구하기 - 2


기존의 포스팅에 이어서 작성된다. 자세한 설명은 NTFS파일 시스템에서 직접 삭제된 파일 복구하기 -1을 참고해주길 바란다.



이번에는 MFT #47번을 복구가 목표다.



MBR -> MFT 생략하고 
MFT에서
00 00 04 x 8 + 2048 + 94






86 0D * 8 + 2048 




38 47 3C 01 00 00 00 00 00만큼 블록지정 후 복사





정상적으로 복구한 것을 확인


  1. 2017.04.14 23:52

    비밀댓글입니다

NTFS파일 시스템에서 삭제된 파일 복구하기 

NTFS파일 시스템에서 삭제된 파일을 복구 해볼 것이다. 파일 시스템마다 형식이 다르기때문에 복구하는 방법도 다르다.
실질적으로 복구할려면 상용툴이나 오픈소스를 이용하는 것이 여러모로 편하다. 
이번 포스팅에서는 NTFSWalker, HxD와 계산기만으로 직접 보면서 파일을 복구해볼 것이다. 




먼저 분석하고자하는 NTFS 이미지를 구하여 NTFS Walker와 HxD로 켜준다. 
HxD로 이미지를 열 때 디스크이미지 열기로 열어주길 바란다.
툴 사용법은 이전 포스팅에 다 올려 두었으니 참고하자!




NTFS Walker에서 MFT #값이 37번인 파일은 지워진 것을 확인 할 수 있다. 
"FP-NTFS.pdf"파일을 복구하는 것을 목표로 이 포스팅을 써내려 가보겠다. 




NTFS파일을 HxD로 열었을 때 화면이다. 
위 사진에서 드래그한 부분을 보자. MBR영역인데 MBR영역에서 파티션 정보를 표현하는 부분이다.
파티션 정보는 16Bytes로 구성되어 있다.
MBR에서는 총 4개까지만 파티션을 분할 할 수 있고 드래그한 부분은 첫번째 파티션에 대한 정보를 나타내고 있다.
주황색선 기준으로 다음 파티션에 대한 정보가 이어진다.




아까와 똑같은 부분이다. 첫번째 파티션 정보 마지막에서 5~8번부분은 VBR섹터 번호이며 드래그 한 부분이다.
0x00 08 00
이것을 Dex로 바꾸면 2048이 나온다. 2048섹터로 이동을 해보자. 




2048섹터 = VBR(Volume Boot Record)영역



VBR영역에서 4번째 줄 8Bytes를 보자. 이 부분은 Start of MFT부분으로써 계산할 때 사용하게 된다.

내가 원하는 데이터(FP-NTFS.pdf) 부분을 찾아 가기 위해 아래를 계산한다.
0x00 00 04 00 00 00 00 00 * 8 + 2048 + 74를 계산한다.
0x00 00 04 00 00 00 00 00 = Start of MFT
8 = 처리는 클러스터 단위기 때문에 클러스터가 4096일경우 섹터(512kb)*8=4096이기때문에
2048 = VBR영역까지가 2048섹터이기때문에 더해준다.
74 = FP-NTFS.pdf파일의 MFT #은 37이었다. 엔트리가 512bytes이므로 섹터 2개를 먹기때문에 x2해준 값
만약 MFT값을 모르겠다면 +2 +2 +2로 하나씩 다 찾아갈 수도 있다..
== 2099274




내가 원하는 데이터의 MFT로 왔다. 여기서 파일의 길이와 데이터위치를 찾아 낼 것이다.



MFT에서 중간쯤보면 확장자인 pdf를 확인할 수 있다. 
pdf.뒤에 0x80값이 있다. 거기 2줄 아래에 0x40값이 있고 그 아래 2줄 아래에 0x22값이 있다.
0x22값은 runlist라고 하여 데이터영역을 가르켜 주게된다. 




0x22를 통해 0x2D 08을 구할 수 있다.
만약 runlist값이 0x33이라면 0x08 00 FF값이 된다.



runlist값 기준으로 앞으로 8Bytes는 파일의 실제크기에 해당된다. 
0x5F AB 18 00 00 00 00 00



이제 MFT에서 필요한 값들을 구했으므로 데이터영역으로 가서 파일을 복구해보자



0x08 2D * 8 * 2048 == 18792
0x08 2D : runlist 값
8 : 처리는 클러스터 단위기 때문에 클러스터가 4096일경우 섹터(512kb)*8=4096이기때문에
2048 : VBR영역까지가 2048섹터이기때문에 더해준다.
18792섹터로 이동하면 우리가 원했던 pdf파일에 대한 데이터 영역을 확인 할 수 있다.




위에서 구한 18792값으로 섹터이동을 한다.
그럼 처음에 %PDF파일을 볼 수 있고 매우 그럴싸하게 PDF파일 같아보인다.
아까전에 MFT에서 파일의 실제 크기도 구했다. 
제일 처음에서 우클릭하여 블록선택을 누른다. 
그리고 파일의 실제 크기를 넣어서 수락한다.





수락을 눌렀다면 블록선택이 된것을 확인 할 수 있고 %%EOF에 딱 맞게 떨어진것을 볼 수 있다.



HxD에서 파일을 새로 만들고 블록선택한 것을 복사한다.




복사한것을 저장하며 .pdf파일로 바꿔주면 정상적으로 열리는 것을 확인 할 수 있다.
여기서 좀 더 정확히 확인해보자면 복구한 파일의 해쉬값을 구하여 기존의 파일과 비교하여 같으면
똑같은 파일이라고 할 수 있겠다(데이터 무결성) 


* 새로운 파일로 복사하여 붙여넣을 때 메모리의 크기마다 복사할 수 있는 크기가 달라진다.
따라서 메모리가 모자르면 여러번 나눠서 복사 붙여넣기로 만들어주어야 한다. 



위와 같은 경우는 파일을 지우고 그 위에 덧씌우거나
완전삭제 프로그램을 쓰지 않아서 좀 더 수월하게 데이터를 복구 할 수 있었다. 오래전에 삭제된 파일을
복구하고 싶다거나 완전삭제 프로그램을 통하여 파일을 지운다면 복구하기가 어렵거나 불가능할 가능성이 높아진다.
만약 누설되지 않아야될 파일을 지운다면 강력한 완전삭제 프로그램을 사용하여 지워 복구할 수 없도록 
조취를 취해야 할 것이다. 



이번 포스팅으로NTFS Walker, HxD와 계산기로만 파일을 복구해보았다. 
아직 공부해가는 입장이라 야매같은 느낌이 있을 수 있으며 미흡한 부분도 많을 수 있다.
앞으로 몇개 더 파일을 복구하는 포스팅을 올려보도록하며 조금 더 정리할 수 있도록 해보아야겠다.







파일 시스템 상의 파일 복구

파일시스템에 파일이 저장할 때, 파일의 이름, 시간 정보, 크기 등의 메타정보가 함께 기록되는데 보통 파일을 삭제할 경우 메타정보와 실제파일 내용을 초기화하지 않고 단순히 메타정보의 특정 플래그만 변경한다. 파일 시스템상의 파일 복구는 이와 같이 삭제된 것으로 표시된 메타정보를 이용하여 복구하게 된다.


1. FAT파일 시스템에서 파일 복구

FAT 파일 시스템은 파일의 메타정보를 유지하기 위해 FAT영역과 Directory Entry를 사용한다. 파일이 삭제될 경우 FAT영역에서는 파일에 할당 되었던 클러스터에 대응되는 FAT Entry가 0x00으로 초기화가 된다. 그리고 해당 파일의 Directory Entry의 오프셋 0x00의 값이 삭제를 나타내는 0xE5로 변경되고 이 경우 파일에 할당되었던 클러스터에는 파일의 내용이 그대로 남아 있게 된다. 따라서 해당 클러스터가 새로운 파일에 사용되지 않았다면 삭제 표시된 Directory Entry에 파일 크기와 시작 클러스터 정보를 통해 비교적 쉽게 파일을 복구 할 수 있다.


2. NTFS에서 삭제된 파일 복구

NTFS에서는 파일의 메타정보를 유지하기 위해 MFT Entry와 MFT Entry의 할당상태를 표시하기 위한 $MFT(MFT Entry 0) 파일의 $BITMAP 속성, 클러스터의 할당 상태를 표시하기 위한 $Bitmap(MFT Entry 6)파일의 $DATA속성을 사용한다.
파일이 삭제될 경우 $MFT파일의 $BITMAP속성에서 해당 파일이 사용했던 MFT Entry 비트가 0으로 설정되고 $BITMAP파일의 $DATA 속성에서 해당 파일에 할당되었던 클러스터 비트가 0으로 설정된다. 결국 파일의 MFT Entry와 실제 파일에 할당되었던 클러스터 내용이 새로운 파일의 정보로 덮여 쓰여지지 않았다면 비교적 쉽게 파일을 복구할 수 있다.



3. 파일 카빙

파일 카빙 기법은 저장 매체의 비할당 영역으로부터 파일을 복구하는 기법으로 저장 매체의 공간 할당에 따라 연속적인 카빙(continuous carving)기법 과 비 연속적인 카빙(fragment recovery carving)기법으로 나눌 수 있다. 연속적인 카빙 기법은 파일 내용이 저장 매체의 연속된 공간에 저장된 경우 수행하는 카빙 기법이고 비 연속적인 카빙기법은 파일의 내용이 저장 매체의 여러 부분에 조각이나 저장된 경우에 수행하는 카빙 기법이다.


3-1. 시그니처 기반 카빙

파일 카빙은 파일이 메타정보를 이용하지 않기 때문에 파일의 고유한 특성으로 복구해야 한다.
시그니처 기반 카빙 기법은 파일 포맷별로 존재하는 고유한 시그니처를 이용하는 방법이다. 시그니처는 파일의 시작부분에 위치하는 헤더(Header)시그니처와 파일의 마지막에 존재하는 푸터(Footer)시그니처가 있다.
따라서 헤더와 푸터 시그니처가 모두 존재하는 파일의 경우 두 시그니처 사이의 데이터가 파일의 내용이 된다.
하지만 시그니처 기반 카빙의 경우 파일을 구분하는 시그니처의 크기가 작거나 일반적인 경우 파일 내용의 바이트 스트림에서도 같은 값이 존재할 가능성이 매우 높기 때문에 많은 오탐이 생길 수 있다.  

분석, 데이터 복구를 위한 파일 시스템 구조 파악 - 2


1. 파티션과 MBR

시스템은 부팅과정에서 파티션의 크기, 위치, 설치된 운영체제 등을 파악하여 그에 맞게 구동해야 한다.
이러한 정보를 담고 있는 영역이 Boot Record(BR)영역이며 윈도우 운영체제의 경우 파티션의 첫 번째 섹터에 위치한다.

2. Boot Record

시스템은 부팅 과정에서 운영체제의 커널 파일을 불러와 구동시킨다.
이러한 역할은 BR(Boot Record) 영역의 정보를 통해 수행된다. BR은 각 파티션의 첫 섹터에 위치한다.
파티션을 나누지 않는 단일 파티션의 경우 1개의 BR 영역이 첫 번째 섹터에 위치한다. 하지만 분할된 파티션의 경우 각 파티션의 BR 영역을 관리할 필요가 있다.


3. Master Boot Record(MBR)

각 BR 영역을 찾아갈 수 있는 정보를 담고 있다.
MBR 기본적인 구조는 446바이트의 부트 코드(Boot Code)영역, 64바이트의 파티션 테이블(Partition Table)영역, 2바이트 시그니쳐(Signature)로 구성되어 있다.
부트 코드 영역에서는 파티션 테이블에서 부팅 가능한 파티션을 찾아 해당 파티션의 부트 섹터(Boot Sector)를 호출하는 코드가 위치한다. 즉 부팅 중 POST(Power On Self-Test)과정 후에 BIOS에 의해서 해석되어 동작하는 영역이다.



4. 확장 파티션(Extended Partition)

MBR 영역에서 파티션 정보를 표현하는 공간은 64Byte로 총 4개까지만 파티션을 분할 할 수 있다.
이런 한계를 극복하기 위해 나온 개념이 확장 파티션이다. 확장 파티션을 가르키는 파티션 정보는 파티션 유형을 나타내는 1바이트의 값이 0x05나 0x0f으로 설정된다.
4번째 파티션 테이블 정보의 파티션 유형 값이 0x05이나 0x0F이면 확장 파티션을 사용하고 있는 것을 알 수 있으며 해당 정보를 따라가면 또 다른 파티션 테이블 정보를 얻을 수 있는 MBR 영역을 확인 할 수 있다. 


5. FAT(File Allocation Table)

MS-DOS파일 시스템에서 파일의 위치 정보를 기록한 테이블을 지칭한다.
이후 윈도우 시스템으로 운영체제가 바뀌면서 MS-DOS파일 시스템 자체를 가리키는 용어로 확립되었다.
여기에서는 파일 시스템과 테이블을 구분하기 위해 파일 시스템은 "FAT12/16/32" 또는 "FAT 파일 시스템"이라고 표기하고, 테이블은 "FAT 영역"이라고 표기한다. FAT 파일 시스템은 크게 FAT12, FAT 16, FAT32로 나눌 수 있는데 뒤의 숫자는 파일 시스템에서 관리하는 클러스터의 개수를 의미한다.


 파일 시스템

클러스터 최대 개수 

FAT12

4,084 

FAT16 

65,524 

FAT32 

67,092,481 

5-1. FAT 영역

예약 영역은 FAT파일 시스템에서 가장 앞에 위치하는 구조로 여러 개의 섹터를 포함한다. 예약 영역의 크기는 기본적으로 FAT12/16의 경우에 1개의 섹터, FAT32의 경우에 32개의 섹터를 사용한다. FAT영역은 예약 영역 다음에 바로 위치하며, 일반적으로 두 개의 FAT영역(FAT1, FAT2)이 존재한다. FAT2는 FAT1의 복사본으로 만약의 경우를 대비해 백업한다.
FAT영역은 데이터 영역의 클러스터 할당 상태를 표시한다. FAT16은 16비트, FAT32는 32비트를 사용해 데이터 영역의 시작 클러스터부터 마지막 클러스터까지 할당 상태를 표시한다.



< 출처 : http://forensic-proof.com/archives/378 >


5-2. 데이터 영역

FAT파일 시스템 역시 트리 형태로 표현되는데 가장 중요한 요소가 최상위 루트 디렉토리이다.
FAT 12/16은 루트 디렉토리가 FAT 영역 바로 뒤, 데이터 영역의 제일 앞부분에 온다. 따라서 루트 디렉토리의 시작은 FAT Entry 2번에 해당한다. FAT 12/16은 루트 디렉토리를 위해 최대 32개 섹터인 16,384바이트 크기의 영역을 사용 할 수 있다. Directory Entry 크기가 32바이트이기 때문에 FAT12/16에서는 최대 512개의 Entry를 나타낼 수 있다. 따라서 루트 디렉토리 내에 파일 및 디렉토리를 최대 512개까지 생성할 수 있다.
Directory Entry의 구조로 파일의 이름, 확장자, 속성, 시간 정보, 시작 클러스터 위치, 파일크기 등의 정보가 포함된다.


< 출처 : http://forensic-proof.com/archives/378 >


6. NTFS(New Technology File System)

윈도우 NT부터 사용되기 시작한 파일 시스템으로 FAT파일 시스템과는 근본적으로 다른 개념으로 개발되었다.
NTFS는 VBR(Volume Boot Record) 영역, MFT(Master File Table) 영역, Data영역으로 나눌 수 있다.
VBR영역이 가장 앞에 위치하고 이어서 MFT영역과 데이터 영역이 있다.
VBR영역은 부트 섹터와 추가적인 부트코드가 저장되는 부분이다. 

6-1. MFT(Master File Table) Entry
NFTS는 모든 데이터를 파일 형태로 관리한다. 각 파일들의 위치, 시간정보, 크기, 파일 이름 등의 속성 정보는 MFT Entry(File Record)라고 불리는 특별한 형태의 구조를 사용하여 저장한다. MFT는 이러한 MFT Entry의 묶음으로 모든 파일들의 정보를 가지고 있다.
예약된 MFT Entry들은 NTFS의 다양한 특성을 지원하기 위해 사용된다. 이후 사용자에 의해 파일이 생성될 때마다 새로운 MFT Entry가 할당되어 해당 파일의 정보를 유지 관리 하게된다.
MFT Entry 0번을 사용하는 파일은 $MFT 파일이다. 이것은 다른 Entry와는 다르게 전체 파일 이름을 대문자로 표현한다. $MFT는 MFT자체를 가르키는 것으로 NTFS상에 존재하는 모든 MFT Entry정보를 담고 있다. MFT Entry 11번의 $Extend는 $ObjID, $Quota, $Reparse points, $UsnJrnl 등의 추가적인 파일 정보를 기록하기 위해 사용되고 12~15번은 예약 영역이다.
앞서 언급한 바와 같이 MFT는 파일 시스템의 여러 영역에 조각나 존재할 수 있기 때문에 MFT전체 정보를 유지, 관리하기 위한 파일이 필요한데 $MFT가 그 역할을 수행하고 있다. 따라서 각 파일들을 분석하기 위해서는 전체 $MFT정보를 획득하는 것이 선행되어야 한다. 


< 출처 : http://kali-km.tistory.com/entry/NTFS-File-System-4



< $MFT 파일 획득 방법 > 


6-2. MFT Attribute

Fixup 배열에 이어 여러 개의 속성이 뒤 따라 오는 것을 알 수 있다.
파일의 시간 정보, 이름, 데이터 등은 각각 하나의 속성으로 표현되는데 파일의 종류에 따라 하나 이상의 다양한 속성들이 저장된다. 속성의 이름은 미리 예약된 MFT Entry이름과는 다르게 ${uppercase}와 같이 표현된다. [[단, $MFT제외]]
각 속성 앞부분에는 공통적으로 속성 헤더(attribute Header)이 존재한다. 


< 출처 : http://forensic-proof.com/archives/378 >



< 출처 : http://kali-km.tistory.com/entry/NTFS-File-System-5



※ 출처에 있는 사이트를 가면 좀 더 자세하고 친절한 설명이 있다. 더 많은 정보를 원하면 가보도록 해보자.

파일 시스템 분석, 데이터 복구를 위한 구조 파악 


1. 파일 시스템 구조

- 운영체제는 어떠한 파일이 있는지, 해당 파일이 저장된 위치는 어디인지, 파일의 이력은 무엇인지 효과적으로 파악할 수   있어야 한다.
- 새로운 파일을 생성하여 저장할 때는 저장 매체에 빈 공간을 찾을 수 있어야 한다.


2. 파일 시스템의 주요 요소

2-1. 주소지정방식(Addressing)
CHS는 실린더(Cylinder),해드(Head),섹터(Sector)를 의미, 디스크의 물리적인 구조에 기반한 주소지정방식 CHS방식은 초기 ATA표준에서 정의한 주소 지정 비트와 BIOS에서 지원하는 주소 지정 비트의 차이로 인해 최대 504크기까지만 주소지정이 가능
이후 디스크 용량의 증가로 인해 BIOS의 주소 지정 비트수를 확장시켰지만 8.1GB까지만 주소 지정이 가능하였기때문에 대용량 디스크를 지원하지 못하고 결국 CHS주소 지정 방식은 ATA-6부터는 표준에서 제외되었다.

2-2. LBA(Logical Block Address) 방식
LBA주소 지정 방식은 물리적인 구조를 고려할 필요 없이 디스크의 0번 실린더, 0번 해드, 1번 섹터를 0번으로 하여 디스크의 마지막 섹터까지 순차적으로 주소를 지정하는 방식이다.
따라서 LBA방식을 사용하는 경우 관련 소프트웨어들은 물리적인 구조에 대한 정보 없이도 접근하고자 하는 섹터의 번호만으로 쉽게 접근이 가능하다.
물론 LBA방식을 사용하는 경우에도 선형적인 섹터 번호가 실제 디스크의 물리적인 구조로 변환한다. 하지만 이러한 변화는 ROM BIOS에 의해 자동적으로 수행되므로 CHS방식에서와 같이 물리적인 구조를 고려해야 하는 복잡함이 줄어든다.

2-3. 클러스터(Cluster)
하드 디스크의 물리적인 최소 단위는 섹터(512 Bytes)이다.
따라서 디스크와 관련된 읽기 쓰기 작업은 모두 섹터 단위로 이뤄진다. 그러나 섹터 단위로 입출력을 처리하면 큰 파일의 경우 많은 시간이 요구되기 때문에 대부분 여러 개의 섹터를 묶어 한꺼번에 처리한다. 윈도우 운영체제에서는 여러 개의 섹터를 묶은 클러스터가 데이터의 입출력 단위이다. 따라서 파일의 크기와 상관없이 클러스터의 배수로 파일이 할당이 된다.
클러스터 크기를 4,096바이트(4KB)로 할당하였을 때, 100바이트의 데이터를 저장하는 경우 클러스터 크기(4KB)만큼 지정된다. 실제로 파일을 생성한 후 파일의 속성을 살펴보면 실제 파일의 크기는 100바이트이지만 디스크 할당 크기는 4KB인 것을 확인 할 수 있다. 이 경우 3,996바이트의 공간이 낭비되는데, 낭비되는 공간이 있음에도 불구하고 클러스터 단위를 사용하는 이유는 디스크 입출력의 횟수를 줄이기 위함이다.




2-4. 램 슬랙(RAM Slack)
램 슬랙은 램에 저장되어 있는 데이터가 디스크에 저장될 때 512바이트씩 기록되는 특성때문에 발생하는 공간으로 섹터 슬랙(Sector Slack)이라고한다.
파일의 크기가 512바이트의 배수가 아닐 경우에 램 슬랙이 발생한다.
램 슬랙은 윈도우 운영체제에서 사용하는 메모리 관리 정책 때문에 0x00의 값으로 기록한다.
예를 들어 1,500바이트의 데이터를 기록할 경우 3개의 섹터가 사용되며 512의 배수가 되지 않는 여분의 36바이트는 0x00의 값으로 기록된다. 파일의 크기는 대부분 512바이트이 배수가 아니기 때문에 거의 모든 파일에서 램 슬랙이 발생한다.
따라서 램 슬랙을 이용하면 파일의 끝을 알 수 있기 때문에 삭제된 파일을 복구할 때 유용하게 사용한다. 


2-5. 파일 슬랙(File Slack)
파일 슬랙은 클러스터의 사용으로 인해 낭비되는 공간 중 램 슬랙을 제외한 나머지 부분을 나타내는 것으로 드라이브 슬랙(Drive Slack)이라고 한다.
512바이트보다 작은 데이터가 기록되는 경우 하나의 섹터만 사용하고 나머지 3개의 섹터는 사용하지 않는다.
이 영역을 파일 슬랙이라고 하는데 0x00으로 기록되는 램 슬랙과 다르게 파일 슬랙은 이전의 데이터가 그대로 남아 있다. 그 이유는 최하단의 디스크 입출력은 섹터 단위로 진행되기 때문이다.
파일 슬랙을 이용하면 특정 파일이 해당 저장 매체에 존재하였는지 규명할 수 있다. 즉 존재 여부를 알아야하는 파일이 있다고 하자. 그 파일을 클러스터 단위로 나눈 후 각 클러스터의 마지막 부분과 파일 슬랙 중 일치하는 부분이 있는지 확인함으로써 해당 파일이 존재 했었는지 확인할 수 있다. 범죄 관련 파일이 저장 매체에 있었다가 삭제되었음을 입증할 때 이러한 방법을 사용한다.


2-6. 파일 시스템 슬랙(File System Slack)
파일 시스템의 크기는 파일 시스템을 생성할 때 결정한다. 그런데 파일 시스템은 클러스터 크기의 배수만큼 사용할 수 있기때문에 파일 시스템 끝 부분에 남는 공간이 발생한다. 예를 들어 1,026KB의 볼륨에 4KB의 클러스터를 사용하는 파일 시스템을 구성한 경우 마지막 2KB는 사용할 수 없음 이렇듯 파일 시스템 할당 크기와 볼륨 크기간의 차이로 인해 발생되는 공간을 파일 시스템 슬랙이라고 한다.


2-7. 볼륨 슬랙(Volume Slack)
볼륨 슬랙은 전체 볼륨 크기와 할당된 파티션 크기의 차이로 인해 발생하는 공간이다.
볼륨 슬랙은 다른 슬랙과 다르게 파티션 크기의 변경을 통해 임의로 생성이 가능하다.

Hex editor(HxD) 다운로드 / 사용방법

파일에 대한 Hex 값을 볼 수 있도록 도와주는 프로그램이다.


HxDSetupKOR.zip

https://mh-nexus.de/en/downloads.php?product=HxD

최초 실행화면





왼쪽 상단에 파일 -> 열기로 파일을 열 수 있으며, 드래그앤 드롭으로도 열 수 있다.






HxD에서도 해쉬값을 구해준다. 분석 -> 체크섬에 들어가면 MD-n, SHA-1,2등 선택하여 값을 구할 수 있다.
다재다능한 프로그램이다. 





앞으로 포스팅할 때 이 기능을 쓸 예정인데 디스크 이미지도 분석하기 편하게 열 수 있다.
이미지 열기로 이미지를 열면 된다.





512크기로 섹터를 나눠준다. (하드디스크 / 플로피디스크 선택시)







파일 복구 실습을 위한 NTFSWalker 설치 / 사용방법 


1

NTFSWalker.exe

http://dmitrybrant.com/ntfswalker



실행하면 위와 같은 창을 볼 수 있고 Physical과 Logical로 나누어져 있다.




Advanced로 가면 이미지 파일을 열 수 있다.






윈도우즈(Windows)에서 볼라틸리티(volatility)를 사용하여 메모리 분석 - 2

이번 포스팅에는 윈도우즈(Windows)에서 볼라틸리티(volatility)를 사용하여 메모리 분석 - 1

에서 알아본 명령어를 통해 실습 덤프 파일을 사용하여 분석을 해 볼것이다. 

실습 덤프 파일은 zeus와 stuxnet을 사용 할 것이며, 이전 포스팅과 연관하여 진행할 예정이므로 
되도록 순서대로 읽어주면 좋겠다.



1. Zeus

먼저 네트워크 통신하고 있는 프로세스부터 알아보자. connscan을 했더니 856번이 통신하고 있는 것을 확인 할 수 있다.




pslist에서 856을 확인해보면 svchost.exe가 856번을 쓰는 것을 확인 할 수 있다. svchost.exe파일은 공격자들의
좋은 먹잇감이 된다. svchost는 보통 통신을 하지 않는데 conncan과 pslist로 파악 할 수 있다.



856번을 malfind한 결과이다. 어셈블리코드를 보면 무언가를 쓰는 것을 알 수 있다.




processdump를 이용하여 프로세스에 대한 dump파일을 구한다.





위에서 구한 덤프 파일을 바이러스 토탈 사이트에 드래그 앤 드랍 등을 이용하여 분석을 한다.






덤프를 분석하여 결과를 준다.





이 결과는 936프로세스에 대한 결과이다.


2. Stuxnet


기존의 pslist에서 특정 프로세스만 출력하고 싶다면 위와 같이 | findstr 을 사용하면 해당되는 값만 출력해줄 수 있다.
위의 명령어는 findstr lsass.exe를 통하여 pslist에 있는 lsass.exe값만 가져오게 된다.




위에 인덱스가 짤렸지만 PID, PPID 순이다.
시간을보면 680번은 2010년 10월에 시작된 것을 알 수 있고 868번과 1928번은 2011년 6월에 시작 됐다.
그리고 868번과 1928번은 같은 PPID(668)을 가진다.




각 프로세스마다 dlllist을 출력한다.




1928이 사용하는 dlllist인데 ASLR을 사용하는 것을 볼 수 있다. ASLR은 악성코드에서 많이 사용된다고 한다.
※ ASLR(Address Space Layout Randomization)
주소를 랜덤하게 배치해주는 기법



1928번 프로세스가 무언가를 쓰는 것을 알 수 있다. 868번도 마찬가지이다. 
680번 프로세스를 열어보면 아무것도 안뜨는 것을 알 수 있다.




3개 프로세스를 procexedump를 한다. 





1928번 프로세스에 대한 결과이다.
680번 프로세스는 4개 정도 탐지된다고 뜨는데 4개정도는 감안할 수 있을 정도라고 보면 되겠다.
868번 프로세스를 검사해도 많이 탐지되는 것을 알 수 있다.




3. 마치며

이번 포스팅과 저번 포스팅을 통하여 볼라틸리티를 사용하여 메모리포렌식하는 것을 알아보았다.
필자도 배워가면서 하는 입장이라 자세히는 모르겠지만, 포렌식은 필수적인 스킬이라고 생각된다.
이번 글을 쓰면서 위의 예제는 기본적으로 다 분석이 된 경우라서 악성코드를 금방 찾을 수 있었지만
실제로 제로데이 공격이나 신종 공격기법같은 경우 쉽사리 찾을 수 없다고 생각되었다.
악성코드를 얼마나 빨리, 정확히 찾아내는게 고급 인력이 되는 지표가 될 것같은 생각이 들었다.
틀린 내용이 있고 더 나은 방법이 있을거라 생각되는데 있다면 필자에게 알려주면 좋겠다.






  1. 1123 2018.08.04 15:18

    덤프 명령어를 뭐 사용하셨나요

윈도우즈(Windows)에서 볼라틸리티(volatility)를 사용하여 메모리 분석 - 1
윈도우즈(Windows)에서 볼라틸리티(volatility)를 사용하여 메모리 덤프 뜬 것을 분석해보는 시간을 가져보자.

vol.zip

윈도우즈에서 volatility를 사용하려면 위의 파일이 필요하다. 다운로드를 받으면된다.
volatility를 사용하려면 넷프레임워크 아니면 파이썬이 필요한데 정확히 뭐였는지 기억이 안난다.
혹시 실행이 안된다면 파이썬이나 넷프레임워크를 설치해보자.


 이번 포스팅에서는 볼라틸리티(volatility)에 대해 자주 사용할 법한 명령어들 몇개를 실제로 실습을 해볼 예정이다.
 여담으로 Volatility(휘발성)와 vulnerability(취약성)와 혼동하면 안된다.



vol.exe -f [분석하고자 하는 이미지(zeus.vmem, XXXX-20161229-112527.raw)] imageinfo
위에는 zeus에 감염된 메모리에 대한 이미지정보를 나타내는 것이고 아래 명령어는 필자의 컴퓨터(Windows 10)를
덤프 뜬 것을 본것이다. 윈도우에서 메모리 덤프뜨는 방법은 기존의 포스팅에 있으니 참고하면 되겠다.
imageinfo에서는 Suggested Profile(s)의 정보가 중요하다. 앞으로 분석하는데에 사용되는 값이기 때문이다.




vol.exe -f zeus.vmem --profile=[imageinfo의 Profile값(WinXPSP2x86)] pslist 
pslist 명령어는 시스템의 프로세스들을 보여주기 위해 사용한다.
오프셋, 프로세스 이름, ID, 부모 프로세스 ID(PPID), 쓰레드의 수, 핸들의 수, 프로세스 시작 시간과 종료 시간을 보여준다.
다만 프로세스가 은닉되었거나 연결이 끊어진 프로세스는 출력해주지 않는다. (psscan 명령어는 통해 파악)





vol.exe -f zeus.vmem --profile=[imageinfo의 Profile값(WinXPSP2x86)] pslist > pslist.txt
위와 똑같은 pslist의 출력인데 " > pslist.txt " 명령어를 통하여 텍스트 파일로 나타낼 수 있다. 





vol.exe -f zeus.vmem --profile=[imageinfo의 Profile값(WinXPSP2x86)] pstree > pstree.txt
pstree 명령어는 프로세스를 트리 형태로 출력해주는 것을 보기 위해 사용한다. pslist와 유사하며 마찬가지로
은닉되었거나 연결이 끊긴 프로세스는 보여주지 않는다. 자식프로세스는 마침표를 통하여 구분하게 된다. 





vol.exe -f zeus.vmem --profile=[imageinfo의 Profile값(WinXPSP2x86)] psscan > psscan.txt
psscan은 pslist, pstree와 유사하지만 풀 태그 스캐닝을 사용하여 프로세스를 출력해준다. 따라서 종료된 프로세스나
비활성화 되어있는 프로세스, 루트 킷에 의해 숨겨지거나 연결이 끊긴 프로세스들을 찾을 수 있게된다.






vol.exe -f zeus.vmem --profile=[imageinfo의 Profile값(WinXPSP2x86)] dlllist > dlllist.txt
프로세스에서 Load된 DLL들을 보기위한 명령어이다. -p 명령어를 통하여 특정 프로세스 DLL을 볼 수 있으며
이는 PEV의 InLoadOrderModuleList에서 가르키는 LDR_DATA_TABLE_ENTRY 구조체들의 이중연결리스트를 지닌다.
DLL들은 한 프로세스에서 LoadLibrary(또는 LdrLoadDll과 같은 몇몇 파생함수)를 호출할 때 이 리스트에 자동으로 추가되며
FreeLibrary가 호출되거나 레퍼런스 카운트가 0이 될 때까지 제거되지 않는다.






vol.exe -f zeus.vmem --profile=[imageinfo의 Profile값(WinXPSP2x86)] hivelist > hivelist.txt
메모리의 레지스터 하이브(hives)의 가상메모리 주소들의 위치를 파악하고 디스크에 관련된 하이브에 전체 경로를
표기하기 위해 hivelist명령어를 사용한다. 만약 특정 하이브로부터 값을 표기하기 원한다면, 이 명령어를 실행시켜서
해당 되는 하이브 주소 값을 볼 수 있으며, 이 명령어를 통하여 Windows password를 크랙할 수 있게 된다.







Windows password는 SAM에 속해있으며 값을 추출하기 위해 위에 표기 되어있는 값을 알아야 한다. 



vol.exe -f zeus.vmem --profile=[imageinfo의 Profile값(WinXPSP2x86)] hashdump -y [시스템의 Virtual(0xe101b008)] -s [샘의 Virtual(0xe1544008)]
이 사진 이전의 hivelist.txt 결과에서 값을 적으면 된다. 그럼 linux에서 보던 passwd, shadow파일처럼 생긴 것을 볼 수 있다.






vol.exe -f zeus.vmem --profile=[imageinfo의 Profile값(WinXPSP2x86)] connections > conn.txt
메모리 덤프를 뜰 때 활성화 되어 있는 TCP연결들을 보기 위한 명령어이다. 현재 이 덤프파일에는 안나와 있지만
네트워크의 pslist와 비슷하다고 생각하면 될 듯 싶다.
오프셋은 기본적으로 가상 오프셋으로 출력되지만 물리적인 오프셋을 얻고 싶다면 -p 명령어를 추가적으로 사용한다.





vol.exe -f zeus.vmem --profile=[imageinfo의 Profile값(WinXPSP2x86)] connscan > conn2.txt
connscan은 프로세스로 따지자면 psscan과 유사하다.
풀 태그 스캐닝을 사용하여 _TCPT_OBJECT 구조체를 찾기 위해 사용된다. 이 명령어는 32bits와 64bits Windows XP와
Windows 2003 Server에서만 동작한다고 한다. 
이 명령어는 이미 종료되어버린 연결들로부터 아티팩트를 찾아 낼 수 있고 게다가 활성화된 것들도 찾아 낼 수 있다.
부분적으로 덮여쓰여진 필드를 발견 할 수 있지만 전체적으로 신뢰할 수 있는 정보이다.
따라서 오탐이 발견될 수 있지만 많은 정보를 찾을 수 있다는 장점이 있다. 






vol.exe -f zeus.vmem --profile=[imageinfo의 Profile값(WinXPSP2x86)] malfind -p 856 > 856.txt
malfind 명령어는 VAD 태그와 페이지 권한들 같은 문자들을 기반으로 사용자 모드 메모리에 숨겨져 있거나 삽입되어 있는 코드나 DLLs를 찾아내는데 도움을 준다. 참고로 malfind는 CreateRemoteThread -> LoadLibrary로 사용되는 프로세스에 삽입되는 DLLs은 탐지하지 않는다.
이 기술로 삽입된 DLLs는 숨겨지지 않으며 CommandReference21#dlllist에서 이것들을 확인할 수 있다.
malfind의 목적은 기본적인 메소드/도구들이 보지 못하는 것을 DLLs의 위치를 찾아내는 것이다. 
malfind에 의해 인식되는 메모리 세그먼트의 압축된 복사파일을 저장하고 싶다면, -D 옵션과 결과가 저장될 dir를 지정해주면 된다. 






vol.exe -f zeus.vmem --profile=[imageinfo의 Profile값(WinXPSP2x86)] -p 856 impscan -b [Malfind의 프로세스 결과 값의 Address(0xb7000)] > impscan.txt
메모리 덤프에서 찾은 코드를 Reverse engineering(역공학)을 하기 위해선 코드가 import하고 있는 함수를 보는 것이 필수적이다.
다른 말로 말하자면 그것이 가르키고 있는 API함수들을 의미한다. 

Impscan은 PE의 IAT(Import Address Table)를 파싱할 필요 없이 API들을 불러와 정의 할 수 있다. 만약 악성코드가
완벽하게 PE Header를 지우고 커널 드라이브에서 실행되고 있다면 여기엔 나오지 않게 될 것이다. 







vol.exe -f zeus.vmem --profile=[imageinfo의 Profile값(WinXPSP2x86)] -D [경로(C:\Users\Moon\Desktop\run)] procexedump
프로세스의 실행(슬랙 공간은 미포함)을 덤프하기 위해서 사용되는 명령어이다. 
프로세스을 실행하는 실행파일을 뽑아낸다. 

test




참고 문헌 : Volatility Command 2.1(번역 문서) - www.boanproject.com 


+ Recent posts