Test

#About

[시나리오]

A사에 근무하고 있는 박보안 부장은 PM으로 협력사인 B사와 함께 프로젝트 "WHITEHGAT"을 진행하고 있다.

프로젝트를 진행하면서 자료 공유는 외부 클라우드 서비스, 관련 코드는 별도의 소스관리 솔루션, 진행 사항은 팀 채팅 솔루션을 이용해 공유하였다.

어느날 박보안 부장은 평소와 다름없이 업무를 진행하였는데, 갑자기 자신이 쓰던 PC의 모든 문서가 암호화되는 사건을 겪었다. 인터넷을 검색해본 결과, "랜섬웨어"라고 불리는 악성코드에 감염된 것으로 보였다.

감염되기 전의 상황을 되짚어보았지만 기존에 해오던 일상적인 업무 이외에 특별한 행위를 하지 않았다고 생각했다.

재부팅한 결과, 공격자는 400만원의 돈을 요구했다.

암호화된 파일에는 "WHITEHAT" 프로젝트의 주요 파일이 포함되어 있어 400만원을 지불하고서라도 복구하고 싶었지만 공격자를 믿을 수는 없었다.

주어진 파일은 박부장의 PC HDD 이미지와 현장에서 획득한 메모리 덤프 파일이다. 어떻게 감염이 되었는지? 복호화는 불가능한 것인지? 분석하라!!

1. 박부장의 PC의 문서를 암호화한 랜섬웨어 파일은 무엇인가요? (전체 경로)

2. 박부장 PC에서 랜섬웨어에 의해 암호화된 파일을 모두 몇개인가요?

3. 랜섬웨어가 사용한 암호 알고리즘과 모드는 무엇인가요? (암호 알고리즘_모드)

4. 랜섬웨어 파일은 어디에서 다운로드 되었나요? (원본 파일 URL 전체 경로, 프로토콜 포함)

5. 랜섬웨어 파일을 다운로드한 다운로더(Downloader)는 무엇인가요? (파일명.확장자)

6. 다운로더(Downloader)는 박부장 PC에 언제 다운로드되었나요? (YYYY-MM-DDThh:mm:ss)

7. 다운로더(Downloader)는 어디에서 다운로드 되었나요? (다운로드 URL 전체 경로, 프로토콜 포함)

8. 박부장 PC의 문서를 암호화한 키가 저장되어 있는 데이터베이스명, 테이블명은 무엇인가요? (DBNAME_TABLENAME)

9. 박부장 PC의 문서를 암호화한 키는 무엇인가요?

10. 박부장 PC의 IP주소는 무엇인가요?

#Solution

[그림 1] - Arsenal Image Mounter

제공받은 이미지 파일을 마운트 시키기 위해, 마운트 전용 도구인 Arsenal Image Mounter를 사용했고, 생성 시간을 기준으로 첫 번째로 암호화 된 파일을 확인 해보았다.

[그림 2] - 첫 암호화 파일 확인

첫 번째로 암호화 된 파일은 PDFSigQFormalRep.pdf_enc로 암호화 파일 생성 시점은 "2015-09-25 15:22:48"이다

파일이 암호화 되었다는 것은, 이전에 암호화 작업을 진행하는 랜섬웨어 파일이 실행되었음을 의미하고, 첫 암호화 시점을 기준으로 이전을 보았을 때, 

의심스러운 temp.exe이라는파일을 확인할 수 있고 또한 생성된 bin, js파일의 경로를 확인 결과 웹 캐시 파일임을 알 수 있으며, 

이는 암호화 작업이 진행되기 전, 웹 사이트에 접속 했고 무언가를 다운받아서 실행했다는 가설을 세우고 분석을 진행할 수 있다

[그림 3] - 웹 브라우저 아티팩트 추출

세운 가설에 입각하여 웹 브라우저 아티팩트를 추출했고 아래와 같이 WEFA로 웹 히스토리를 확인할 수 있었다.

[그림 4] - 웹 히스토리 확인

방문 횟수를 기준으로 보았더니, tenos.jandi.com/app/이라는 URL에 가장 많이 방문함을 확인할 수 있고,

이는 검색 결과 아래와 같이, 업무 협업툴을 제공하는 도메인임을 알 수 있다

[그림 5] - JANDI 확인

또한 아래의 캐시 필드에서 최근 방문 시간을 기준으로 필터링한 결과, 

암호화가 일어난 시점(2015-09-25 15:22:48)과 30초도 남짓 안되는 시간에, jandi로 부터 참고지침.hwp를 다운받음을 확인할 수 있다.

[그림 6] - 참고지침.hwp 확인

다운받은 참고지침.hwp는 [그림 2]에서 확인할 수 있듯 링크파일이 생성됐고, 이는 파일을 열람했음을 의미하며 열람 시각은 2015-09-25 15:22:34임을 확인할 수 있다.

이후 정확한 분석을 위해 파일 시스템 주요 로그들을 아래와 같이 추출 해주었다.

[그림 7] - 파일 시스템 로그 추출

추출한 파일 시스템 로그를 NTFS Log Tracker를 이용하여 아래와 같이 로그 정보를 파싱해주었다.

[그림 8] - 파일 시스템 로그 파싱

파싱 된 결과 중 참고지침.hwp가 생성된 2015-09-25 15:22:24 이후의 파일 시스템 로그를 확인하기 위해 아래와 같이 쿼리를 날려 주었다.

[그림 9] - 참고지침.hwp.lnk 생성

확인 결과, 참고지침.hwp.lnk이 생성 된 이후, "EMB00000d0c32d3.PCT" 파일과 "temp.exe"가 생성 되는 것을 알 수 있고 이 후 암호화 작업이 진행 된다.

참고지침.hwp를 확인하기 위해 참고지침.hwp.lnk 파일을 분석했고 결과는 아래와 같다.

[그림 10] - 참고지침.hwp.lnk 분석

결과 Users\KAB\AppData\Local\Micorosft\Windows\Temporary Internet Files\Content.IE5\L0Z3CKRQW 경로에 위치함을 알 수 있고 해당 경로를 따라가 

확인 해보았지만 파일이 삭제되어 확인할 수 없었다. 아마 랜섬웨어가 실행되면서 다운로더 역할을 한 참고지침.hwp를 삭제했음을 유추해볼 수 있다.

이는, 랜섬웨어 파일의 실행시각과 파일 시스템상에서의 참고지침.hwp가 삭제된 로그의 시간을 비교하면 확인가능하다

[그림 11] - PCT 파일 확인

참고지침.hwp.lnk가 생성되고 나서 바로 다음으로 생긴 EMB00000d0c32d3.PCT를 확인 결과, 

/wp-includes/theme-compat/post.gif라는 주소를 확인할 수 있으며 아래에는 temp.exe를 다운로드 한다는 것을 유추할 수 있다.

temp.exe를 복구하고 싶었으나, 데이터가 지워져서 더 이상 복구를 진행할 수 없었다.

여기까지를 정리하면, 박 부장은 한글 악성코드라 여겨지는 참고지침.hwp를 다운 및 실행하였고 이는, 

EMB00000d0c32d3.PCT를 생성하고 이 PCT 파일은 temp.exe라는 랜섬웨어 파일을 다운로드 및 실행한다

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

[그림 ~] - pstree 명령 결과

vmdk와 함께 메모리 덤프를 확인 결과, Hwp.exe는 2015-09-25 06:22:24에 실행 되었고, UTC+09:00을 감안했을 때, 참고지침.hwp를 실행시킨 시각과 일치한다. 

또한 Hwp.exe는 하위 프로세스로 temp.exe를 실행하며 이는 파일의 첫 암호화 시점인 2015-09-25 15:22:48과 10초도 채 차이 나지 않으며

temp.exe의 하위 프로세스로 cmd.exe가 실행되며 당시 실행되었던 명령을 확인하기 위해 아래와 같이 cmdline를 이용했다

[그림 ~] - cmdline 명령

확인 결과, cmd.exe에서 [그림 ~]의 하위 프로세스로 존재하던 OfficeHelp.exe 파일을 실행 시키는 것을 알 수 있다

[그림 ~] - OfficeHelp.exe 추출

OfficeHelp.exe의 행위를 분석하기 위해 추출하여 일차적으로 VirusTotal에 검증을 받은 뒤, 위와 같이 실행한 결과 

전형적인 파일 암호화 행위 후, 금전을 요구하는 메세지 박스를 띄우는 역할을 하는 것을 확인할 수 있다.

( * 정확한 행위 분석을 위해서는 정적분석이 필요 합니다.)

#About

이벤트 예약 웹사이트를 운영하고 있는 "깜짝이야"사의 관리자 앞으로 한통의 협박 메일이 도착했다. 당장 10억을 입금하지 않으면, 확보한 자사의 웹페이지 소스코드를 모두 공개할 것이며, 추가적인 위협을 가하겠다는 내용이다. 관리자는 포렌식 전문가인 당신에게 침해사고 분석을 의뢰하였다. 침해된 시스템에 남겨진 흔적과 각종 로그 파일을 분석하여 다음 사항을 밝혀내시오.

A. 공격자가 웹페이지 소스코드를 유출한 시간(UTC+09:00)은? (yyyy-MM-dd_hh:mm:ss)

B. 리버스 셸(Reverse Shell)을 동작시키는 프로세스 ID(PID)는 ? (10진수)

C. 리버스 셸(Reverse Shell)에 대한 공격자 주소(IP)는?

답 입력 : md5("yyyy-MM-dd_hh:mm:ss_PID_XXX.XXX.XXX.XXX")

#Solution

제공받은 파일을 확인해보면 아래와 같이 accounts, file, network, osinfo, process, weblog의 폴더가 존재함을 확인할 수 있다

[그림 1] - 문제 파일 확인

먼저, 아래와 같이 accounts 폴더를 확인하니 history 명령의 결과가 담겨있음을 확인할 수 있었고, 아래와 같이 확인해보았다

[그림 2] - history 확인

셸 history를 확인 결과, chmod 777라는 명령으로 /var/www/upload/editor/image의 경로에 모든 권한을 주는 것을 확인할 수 있고,

ahnlab이라는 계정을 생성 및 포렌식 분석 도구인 sleuthkit을 설치하는 것을 일차적으로 확인할 수 있다

확실한건 chmod 777 /var/www/upload/editor/image라는 명령으로 모든 권한을 주는 것은 일반적이지 않은 행위이며 이는 웹과 관련되었다는 것을 예상해볼 수 있다

[그림 3] - process 폴더 확인

다음으로, 휘발성이 강하며 많은 정보를 담고 있는 process폴더에 접근하여 파일을 확인해보았더니 아래와 같이 ps -eaf 의 명령의 결과가 저장되어 있었다

[그림 4] - ps_eaf 명령 확인

프로세스 정보의 출력 결과가 담긴 ps_eaf를 확인해보았더니 아래와 같다.

[그림 5] - ps_eaf 파일 확인

확인 결과 www-data라는 사용자가 셸을 sh -c을 통해 명령을 실행하고 있으며 셸의 명령을 통해 생성된 자식프로세스(PID=5248)가

php -f 명령을 통해 /var/www/upload/editor/image/reverse.php를 실행하고 있음을 확인할 수 있다.

이는 [그림 2]에서 chmod 777 /var/www/upload/editor/image의 디렉터리에 권한을 전부 주는 것과 연관 되어 있음을 예상할 수 있다.

다음으로 network 폴더에서 lsof의 결과가 저장되어 있음을 확인했다. lsof는 list open files로 시스템에 열려 있는 파일목록을 알려준다

[그림 6] - lsof 확인

cat lsof 명령을 내린 결과 수 많은 결과가 출력되어 grep으로 [그림 2]와 [그림 5]에서 의심스러운 디렉터리를 검색한 결과,

www-data라는 사용자가 apache2, sh, php 명령을 실행시켰고 이를 통해 파일이 열려 있는 상태임을 알 수 있다.

따라서 웹과 관련된 서비스가 열려 있는지 확인하기 위해 netstat_an 파일을 확인해보았더니 아래와 같은 결과를 확인할 수 있었다.

[그림 7] - netstat_an 확인

확인 결과, 192.168.184.162라는 로컬 호스트에서 해커의 IP로 추정되는 144.206.162.21이라는 원격지로 HTTP 연결이 되어 있음을 알 수 있었다.

이를 통해 이미 공격자는 리버스 셸을 통해 공격이 성공 했음을 추측할 수 있고, 리버스 셸과 관련된 행위를 찾기 위해 weblog를 확인 결과 아래와 같다.

[그림 8] - weblog 확인

웹 로그를 확인 결과, 112.220.97.29라는 IP에서 cmd.php의 cmd라는 파라미터를 인젝션 벡터로 하여금, base64로 추정되는 명령을 보냈고 응답코드 200을 통해 정상적으로 실행되었음을 알 수 있다

base64 디코딩 결과는 아래와 같다

cHdk

▶ pwd

bHMgLWFsICAvdmFyL3d3dy91cGxvYWQvZWRpdG9yL2ltYWdlLw%20%20

▶ ls -al  /var/www/upload/editor/image/ 

dGFyIC1jdmYgL3Zhci93d3cvdXBsb2FkL2VkaXRvci9pbWFnZS8xMzMwNjY0ODM4IC92YXIvd3d3Lw%20%20

▶ tar -cvf /var/www/upload/editor/image/1330664838 /var/www/

cGhwIC1mIC92YXIvd3d3L3VwbG9hZC9lZGl0b3IvaW1hZ2UvcmV2ZXJzZS5waHA%20

▶ php -f /var/www/upload/editor/image/reverse.php

1. 이를 통해 가볍게 해커는 pwd 명령을 통해 cmd라는 파라미터을 인젝션 벡터로써 가능한지 확인하고,

2. tar -cvf /var/www/upload/editor/image/1330664838 /var/www/ 명령을 통해 관리자의 웹 페이지 소스코드를 압축한 뒤,

3. GET 메소드를 통해 압축 된 소스코드를 다운받고

4. php -f /var/www/upload/editor/image/reverse.php 명령을 통해 리버스 셸을 실행시켜 압축한 소스코드를 탈취 해갔음을 알 수 있다.

A : 2012-08-25_17:23:02

B : 5248

C : 144.206.162.21

#About

먼저 소개할 시나리오는 NIST에서 제공해주는 데이터 유출 케이스로, 분석에 있어 스킬업(?)을 할 수 있는 좋은 예제이며 

시나리오를 제공하는 링크는 글의 맨 아래에 첨부했으며 제공되는 유출케이스의 종류는 다음과 같다.

[그림 1] - NIST에서 제공해주는 시나리오의 파일 시스템 종류

모든 이미지 파일을 통틀어  60개의 문제로 이루어져 있는데 다 풀 수 있을지는 나도 의문이지만 일단 시작하고 본다.

#Solution

1. What are the hash values (MD5 & SHA-1) of all images?

Does the acquisition and verification hash value match?

먼저 제공되는(획득한) image 파일의 MD5 및 SHA-1 해쉬 값이 verification 해쉬 값과 같은지에 대해 확인하기 위해 아래와 같이 제공 받은 이미지를 마운트 했다.

[그림 2] - 이미지 파일 마운트

늘 사용하던 FTK Imager로 마운트 해도 되겠지만 Arsenal Image Mounter가 마운트를 하기에 좋은 프로그램이라 하여 한 번 사용 해보았고(개꿀 앞으로도 쓸거임)

1번 질의를 답을 하기 위해 아래와 같이 FTK Imager의 Verify Drive/Image 기능을 이용했다.

[그림 3] - 해쉬값 검증을 위한 기능 사용

[그림 4] - 검증 작업 과정

지루한 프로그레스 바를 기다리면 아래와 같은 결과를 확인할 수 있고 이는 1번 문제에서 요구하는 사항이다.

[그림 5] - 검증 해쉬 값 확인

MD5 : a49d1254c873808c58e6f1bcd60b5bde

SHA-1 : afe5c9ab487bd47a8a9856b1371c2384d44fd785

2. Identify the partition information of PC image.

[그림 6] - 파티션 정보 확인

제공받은 이미지에서 사용중인 파일시스템은 NTFS로 총 섹터 수는 41,943,040으로,

41,943,040 * 512 / 1024 / 1024 / 1024 라는 계산을 거치면 20GB임 또한 확인할 수 있다.

3. Explain installed OS information in detail.

   (OS name, install date, registered owner...)

문제에서 요구하는 OS information을 확인하기 위해 레지스트리를 확인하기로 했고,

OS information과 관련한 레지스트리는 SOFTWARE라는 하이브 파일이므로 해당 파일을 아래와 같이 추출해주었다.

[그림 7] - OS INFO 관련 하이브 파일 추출

사용하는 도구가 자꾸 바뀌거나 일관성이 없는 것은 현재 케이스를 분석해보는 동시에 다양한 도구를 써보면서 비교 분석하기 위함이다.

OS관련 정보는 [HKLM/Software/Microsoft/Windows NT/CurrentVersion]에 저장되어 있으며 분석 결과 아래와 같이 OS 정보를 확인할 수 있었다.

[그림 8] - OS INFO 확인

4. What is timezone setting?

타임존 또한 레지스트리 분석으로 확인할 수 있으며 시간은 시스템 설정에 따라 변경될 수 있으므로, 아래와 같이 SYSTEM 파일을 추출해주었다.

[그림 9] - SYSTEM 하이브 파일 추출

추출 된 SYSTEM 파일을 다시 OS INFO 분석때와 같이 Registry Explorer를 통해 로드 해주었고, Timezone이 위치하는 경로는

HKLM/SYSTEM/ControlSetxxx/Control/TimezoneInformation 으로, 해당 경로로 가서 확인해본 결과 아래와 같이 타임존 정보를 확인할 수 있었다

[그림 10] - Timezone 정보 확인

확인 결과, Eastern Standard Time으로 동부 표준시(UTC -05:00)을 사용하는 것을 알 수 있다.

5. What is Computer name?

컴퓨터 이름 또한 레지스트리에서 바로 확인이 가능 하며 경로는 아래 사진에서 확인할 수 있다.

[그림 11] - 컴퓨터 이름 확인

확인 결과, 컴퓨터 이름은 INFORMANT-PC이며, 위의 경로가 아닌 다음의 경로에서도 확인할 수 있다.

[그림 12] - 다른 경로에서의 컴퓨터 이름 확인

이 처럼 같은 정보 또는 유사한 정보가 다른 경로에 존재할 수 있기에, 가능한 하나라도 놓치지 않고 분석하는 꼼꼼함이 요구 된다.

6. List all accounts in OS except the system accounts: Administrator, Guest, systemprofile,

   LocalService, NetworkService. (Account name, login count, last logon date...)

[그림 13] - 계정 정보 확인

시스템 계정을 제외한 OS에서 존재하는 계정은 admin11, informant, temporary로 총 3개가 존재하고

Default라는 계정의 역할은 새 계정을 생성할 때 해당 폴더에 있는 내용을 복사한 것을 바탕으로 새 계정이 생기며 

가령, Default 계정에 악성코드가 담긴 프로그램 파일을 담아둔 뒤, 계정을 생성하면 새로 생긴 계정에도 같은 프로그램이 담겨 있다.

또한 단순히 디스크에서 열어보는 것이 아닌 아래와 같이 레지스트리에서도 확인할 수 있다.

[그림 14] - 레지스트리 정보를 통한 계정 정보 확인

여기서 이상한 점은 단순히 디스크를 열어서 유저 디렉터리를 확인했을 때에는 없던, "ITechTeam"라는 계정을 레지스트리에서 확인할 수 있다는 점에서, 

앞서 말했듯 가능한 하나라도 놓치지 않고 분석하는 꼼꼼함이 더욱 요구 됨을 느낄 수 있다.

문제에서 요구하는 로그인 횟수와, 마지막 로그인 시간을 확인하기 위한 방법으로는 윈도우 이벤트를 일일이 분석해도 괜찮겠지만

이 또한 레지스트리에서 확인할 수 있으며 경로와 값은 아래를 참조하자.

[그림 15] - 사용자 계정의 상세 정보 확인

해당 Users 키에서 문제에서 요구하는 사용작 계정 이름, 로그인 횟수, 마지막 로그인 시간을 모두 확인할 수 있었으며

또한 비밀번호 힌트와 같은 정보가 어디다 저장되나 싶었는데 여기에 저장되어 있음을 알 수 있었고, 

앞으로 사용자 계정 분석시에는 해당 키를 제일 먼저 참조하는게 좋을 것 같다.

+ 그냥 혹하는 마음에 교차검증을 해보고자 마음먹고 REGA로 분석을 진행하려 했지만 아래에선 [그림 15]와 같이 사용자 계정 정보를 확인할 수 없었다.

[그림 16] - REGA로 열어본 SAM 파일

이를 통해 하나의 도구만으로는 원하는 데이터를 제대로 찾는 것이 되지 않을 수 있다는 것을 알게 되었고, 

하나의 도구에서 나와야할 데이터가 나오지 않는다면 다른 도구를 사용해보자.

(내가 REGA를 제대로 사용하지 못한 것 일 수도 있음)

7. Who was the last user to login into PC?

앞서 [그림 15]에서 확인할 수 있듯, 2015-03-25 14:45:59에 informant라는 계정이 로그인 함을 확인할 수 있지만,

해당 도구는 UTC 00:00을 기준으로 보여주기에 동부 표준시인 UTC -05:00을 적용하면, 2015-03-25 09:45:59에 마지막으로 로그인 했다는 사실을 알 수 있다.

8. When was the last recorded shutdown date/time?

[그림 17] - Shutdown Time 확인

이쯤되면 레지스트리는 상당히 (개오지게) 중요한 것을 알 수 있다. 별의 별 내용이 다나오는 느낌이다.

아무튼 해당 값을 분석하기 위해 TimeLord라는 도구를 사용했으며 결과 값은 아래와 같다.

[그림 18] - 추출 된 레지스트리 값으로 부터의 데이터 변환

9. Explain the information of network interface(s) wtih an IP address assigned by DHCP.

이또한 레지스트리에서 확인할 수 있으며 경로는 다음과 같다.

HKLM/SYSTEM/ControlSet001/Services/Tcpip/Parameters/Interfaces\{GUID}

[그림 19] - 네트워크 인터페이스에 할당 된 IP 정보 확인

자세히 보면 Interfaces 키에 하위로 두개의 GUID가 있음을 확인할 수 있었고, 846ee~로 시작하는 인터페이스에는 정보가 담겨있지 않았고 

제공된 이미지 레지스트리가 아닌 현재 분석하고 있는 컴퓨터의 레지스트리를 살펴보니, 

가장 최근에 네트워크에 연결한 정보가 제일 밑에 위치한다는 사실(구라일 수도 있음)을 알 수 있었다.

10. What applications were installed by the suspect after installing OS?

22. List external storage devices attached to PC.

외부 저장 장치와의 연결 흔적은 레지스트리에 많은 영역에 남게되며 자세한 사항은 아래의 블로그를 참조하자

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

수 많은 레지스트리의 키가 있으므로 자동으로 추출해주는 도구를 이용하여 아래와 같이 확인했으며 도구의 출처는 아래와 같다.

http://orionforensics.com/w_en_page/USB_forensic_tracker.php

[그림 ?] - USB 연결 흔적 확인

[그림 ?] - USB 연결 흔적 확인 2

위의 두 그림을 확인하면 두 개의 "SanDisk Cruzer Fit" USB를 연결한 흔적을 확인할 수 있고,

특이점은 Serial Number가 593으로 끝나는 USB는 최소 두 번 연결했음을 확인할 수 있고, 501로 끝나는 USB는 한 번 연결했음을 확인할 수 있다.

[그림 ?] - 드라이브 할당 확인

HKLM/SYSTEM/MountedDevices를 확인하면 외부장치에 의한 드라이브 할당 목록을 확인할 수 있고, 마지막으로 연결한 장치의 정보가 담겨 있는데,

D는 CDrom이기에 위 [그림 ?]과 [그림 ?]에서 확인할 수 있는 USB는 동시에(두개를 같이) 사용하지 않고, 593을 연결 해제후 501을 연결했음을 알 수 있다.

https://www.cfreds.nist.gov/data_leakage_case/data-leakage-case.html

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

~

#About

MQ : 누군가 80번 포트를 통해 나의 중요한 파일을 삭제했다.

MEQ : Someone defaced my system via 80 port and deleted very important file of mine.

Hint : METHOD vulnerability. check the contents of uploaded file.

#Solution

포트번호 80이면 http 프로토콜이며 파일을 삭제했다고 하여 제일 먼저 떠오른건 http method 중 delete였다.

하지만 패킷 분석 스크립트에서 method가 delete인 패킷을 검색해보았으나 나오지 않았고 

최소 GET과 POST는 아니라고 생각이 들어 다음과 같이 스크립트를 작성해 보았다

# -*- coding:utf-8 -*-

'''
Author : Loddy
Date : 2018-03-21 (UTC + 09 : 00)
Purpose : To Analyzing Packet
'''


import socket
import dpkt
import datetime

def mac_addr(address):
    return ':'.join('%02x' % ord(mac) for mac in address)

def extract(pcap):
    for timestamp,data in pcap:
        try:
            eth = dpkt.ethernet.Ethernet(data)
            ip = eth.data
            tcp = ip.data
            src,dst = socket.inet_ntoa(ip.src),socket.inet_ntoa(ip.dst)
            http = dpkt.http.Request(tcp.data)
            if tcp.dport==80 and (http.method!="GET" and http.method!="POST") and len(tcp.data)>=0:
                print "[+] Method       : ",http.method
                print "[+] Timestamp    : ",datetime.datetime.fromtimestamp(timestamp).strftime('%Y-%m-%d %H:%M:%S')
                print "[+] MAC Address  : ",mac_addr(eth.src), ' --> ', mac_addr(eth.dst)
                print "[+] IP Address   : ",src+" --> "+dst
                print "[+] Data         : ",data
        except:
            pass

def main():
    p = open('C:/2013_Hack_The_Packet_Online_PreQUAL_PROB.pcap','rb')
    pcap = dpkt.pcap.Reader(p)
    extract(pcap)

if __name__=='__main__':
    main()

위 스크립트를 실행하면 아래와 같이 OPTIONS와 PUT method를 확인할 수 있다

[그림 1] - HTTP METHOD 필터링을 통한 패킷 확인

확인된 패킷의 METHOD 정보가 두 패킷 밖에 없으므로 아래와 같이 와이어샤크에 METHOD 필터식을 이용하여 확인 결과 플래그를 확인할 수 있었다

[그림 2] - HTTP METHOD 필터링 식을 통한 패킷 확인

패킷을 확인 후 스트림을 따라가 확인해보았더니 문제에서 요구하는 파일을 삭제한 범인을 확인할 수 있었다.

[그림 3] - 플래그 값 확인

FLAG = W26d@v@ttack

#About

LQ. telnet은 다보여...

LEQ : telnet

Hint : Key is telnet Password

주어진 문제에서 요구하는 것은 단순히 텔넷통신을 한 패킷을 찾는 것임

+ 텔넷은 데이터가 암호화 기능이 없으므로 SSH를 사용하는 것을 권장.

#Solution

# -*- coding:utf-8 -*-

import socket
import dpkt
import datetime

def mac_addr(address):
    return ':'.join('%02x' % ord(mac) for mac in address)

def extract(pcap):
    for timestamp,data in pcap:
        try:
            eth = dpkt.ethernet.Ethernet(data)
            ip = eth.data
            tcp = ip.data
            src,dst = socket.inet_ntoa(ip.src),socket.inet_ntoa(ip.dst)
            if tcp.dport==23 or tcp.sport==23 and len(tcp.data)>=0:
                # request = dpkt.http.Request(tcp.data)            
                print "[+] Timestamp : ",datetime.datetime.fromtimestamp(timestamp).strftime('%Y-%m-%d %H:%M:%S')
                print "[+] MAC Address  : ",mac_addr(eth.src), ' --> ', mac_addr(eth.dst)
                print "[+] IP Address   : ",src+" --> "+dst
                print "[+] Data         : ",data
                print "\n",
        except:
            pass

def main():
    p = open('C:/2013_Hack_The_Packet_Online_PreQUAL_PROB.pcap','rb')
    pcap = dpkt.pcap.Reader(p)
    extract(pcap)

if __name__=='__main__':
    main()

텔넷 통신이므로 텔넷의 포트번호에 해당하는 23번을 기준으로 출발지 또는 도착지가 23번인 즉, 

텔넷과 관련된 모든 패킷을 필터링 했을 경우 아래와 같은 결과를 확인할 수 있다

[그림 1] - 포트번호를 기준으로 한 패킷 분석 결과

(위 그림에서 확인할 수 있는 Data 필드의 값이 깨진 이유를 아는 분 댓글로 적어주시면 감사하겠습니다...!!)

위 그림에서 확인할 수 있듯 IP 주소 192.168.163.1에서 192.168.163.154에 패킷을 전송하는 것을 확인할 수 있다

따라서 위 IP를 기준으로 아래와 같이 와이어 샤크에 패킷 필터링을 했을 경우 아래와 같이 TELNET 패킷을 확인할 수 있다

[그림 2] - 패킷 필터식을 통한 패킷 확인

위 그림에서 확인할 수 있듯 TELNET을 사용하여 데이터를 주고 받는 것이 보이며 TELNET은 암호화가 되지 않는다고 앞서 언급했기 때문에 패킷이 원문으로 보일 것이므로 위 TELNET 패킷의 TCP 흐름을 따라가 보았더니 아래와 같이 플래그를 확인할 수 있었다.

[그림 3] - 플래그 값 확인

FLAG = HTPLEO!!!

#About

L_03

Q : 착이가 POC 사이트에 접속했을 때, 웹서버의 시간은?

EQ : What time is web server when ChackYi visited POC site.

Key Format : Thur, 3 Nov 2011 09:00:00 GMT

주어진 지문에서 찾아야하는 것은 POC 사이트에 접속했을 때의 시간대 이므로 패킷 분석을 통해 

http 헤더의 Host 필드에 POC 사이트를 의미하는 http://www.powerofcommunity.net/을 확인하면 된다

#Solution

# -*- coding:utf-8 -*-

import socket
import dpkt
import datetime

def mac_addr(address):
    return ':'.join('%02x' % ord(mac) for mac in address)

def extract(pcap):
    for timestamp,data in pcap:
        try:
            eth = dpkt.ethernet.Ethernet(data)
            ip = eth.data
            tcp = ip.data
            src,dst = socket.inet_ntoa(ip.src),socket.inet_ntoa(ip.dst)

            if tcp.dport==80 and len(tcp.data)>=0:
                # request = dpkt.http.Request(tcp.data)
                print "[+] Timestamp : ",datetime.datetime.fromtimestamp(timestamp).strftime('%Y-%m-%d %H:%M:%S')
                print "[+] MAC Address  : ",mac_addr(eth.src), ' --> ', mac_addr(eth.dst)
                print "[+] IP Address   : ",src+" --> "+dst
                print "[+] Host         : ",data[data.find("Host")+5:data.find("Connection")].replace(data[data.find("User-Agent"):data.find("Keep-Alive:")+15],'')
        except:
            pass

def main():
    p = open('C:/2011_HTP_PreQual_PROB.pcap','rb')
    pcap = dpkt.pcap.Reader(p)
    extract(pcap)

if __name__=='__main__':
    main()

위 코드를 실행하게 되면 아래와 같이 Host 필드에서 powerofcoummunity.net을 확인할 수 있다

[그림 1] - Host 필드 확인을 통한 패킷 정보 확인

위에서 확인할 수 있듯 Host 정보로 poc를 가지는 IP 주소를 기반으로 아래와 같이 와이어샤크에 필터링을 걸었더니

HTTP 프로토콜의 GET 방식을 통해 패킷을 전달하는 것을 확인할 수 있었다

[그림 2] - IP 기반 패킷 필터식을 통한 패킷 확인

해당 패킷의 TCP 흐름을 따라가 보았더니 아래와 같이 문제에서 요구하는 서버의 시간을 확인할 수 있었다

[그림 3] - 플래그 값 확인

파이썬을 사용하지 않고 와이어샤크에서 제공하는 필터링 기능으로만 찾고자 하면 아래와 같은 필터식을 통해서도 찾을 수 있다.

[그림 4] - host 정보를 찾기 위한 패킷 필터식

#About

L_01

Q : 지성이는 홈쇼핑을 하다 이상한 페이지에 접속하여 악성코드에 감염되었다! 악성 스크립트에 포함되어 있는 쉘코드를 다운로드 하는 URL을 찾아라!

Q : J.S Park was surfing a home shopping site and got infected by malware code! Find out the URL that the shellcode(contained in the malware script) attempts to download content from.

# -*- coding:utf-8 -*-

import socket
import dpkt

def extract(pcap):
    for ts,buf in pcap:
        try:
            eth = dpkt.ethernet.Ethernet(buf)
            ip = eth.data
            tcp = ip.data
            src = socket.inet_ntoa(ip.src)
            dst = socket.inet_ntoa(ip.dst)
            # http_req = dpkt.http.Request(tcp.data)
            # if http_req.uri.find('<script>') >=0:
            #     print http_req.uri
            if buf.find("<script>") != -1:
                print "[+] 출발지 : "+src+"도착지 : "+dst
                print buf
                # print buf[buf.find("<script>"):buf.find("</script>")+1],
        except:
            pass

def main():
    p = open('C:/2011_HTP_PreQual_PROB.pcap','rb')
    pcap = dpkt.pcap.Reader(p)
    extract(pcap)

if __name__=='__main__':
    main()

주어진 문제에서 키워드는 악성 스크립트이기에 find 명령을 이용하여 <script>로 시작하는 값이 있으면 출력하도록 만든 것이며 

주석의 내용은 임의로 작성해본 코드라 이 코드를 보고 있는 분께서는 생각안하셔도 되는 부분임.

[그림 1] - 악성 스크립트로 추정되는 스크립트 확인

출력결과를 확인하다 보면 <script>가 아닌 <SCRIPT>로 시작하여 의심을 사기에 충분한 스크립트가 확인되며 

자세한 결과를 확인하기 위해 출발지와 도착지 아이피를 기준으로 아래와 같이 패킷을 확인해보았다

[그림 2] - 필터링을 통한 패킷 확인

패킷 번호 6568번에서 [그림 1]에서 찾았던 페이로드를 확인할 수 있었으며 TCP stream을 통해 아래와 같이 페이로드를 확인할 수 있었다

[그림 3] - 페이로드 확인

페이로드가 유니코드로 되어 있음을 확인 후 온라인 컨버팅을 제공하는 사이트에서 hex 값을 아래와 같이 추출해 낼 수 있었다

[그림 3] - 헥스 값 확인

.... 나중에 이어 씀

#About

[그림 1] - cruel.c 소스 코드 확인

#Solution

해당 문제는 아래의 두 그림처럼 스택 영역에서의 실행권한이 없는 NX bits 설정과 메모리 영역을 랜덤하게 바꾸는 ASLR이 설정되어 

있다는것 이외에는 기본적인 BOF 문제이며, 문제를 해결하기 위해선 hint에서 주어진 RET sleding과 RTL 을 이용해야할 것 같다

[그림 2] - NX bits 설정

(스택 영역에 실행을 의미하는 x 권한이 없는 것을 확인할 수 있음)

[그림 3] - ASLR 설정

( [그림 2]와 [그림3]의 메모리 주소를 살펴보면 ASLR의 영향으로 메모리 주소가 다른것을 확인할 수 있음 )

RET Sleding을 사용하기 전, RTL에 사용할 함수는 execl이며 execl의 함수의 특성상 인자의 끝이 NULL로 끝나야한다 따라서 아래와 같이 

ret에 중단점을 걸어 둔 뒤, 두 번의 실행을 통해 비교분석 결과, 변하지 않는 부분을 다수 찾을 수 있지만 그 중 아래와 같이 0x008caff4를 확인할 수 있다

[그림 4] - 두 번의 실행을 통한 결과 비교

또한 0x008caff4는 아래와 같이 NULL값을 가지는 것을 확인할 수 있다

[그림 5] - NULL 값 확인

따라서 RET Sleding 기법을 통해 7번의 ret과 그 후 오게 될 4바이트는 execl 함수의 주소가 되어야 하며, 

0x008bad44에 담긴 값인 0x008cad3c는 execl 함수가 실행할 파일명이 된다

[그림 6] - 링크 파일 생성

실행할 주소인 0x008cad3c를 위와 같이 셸을 띄우는 코드를 작성 후 링크파일을 걸어주고 

마지막으로 페이로드에 필요한 execl함수와 ret의 주소를 아래와 같이 구해주었다

[그림 7] - execl 함수 주소 확인

[그림 8] - ret 명령 주소 확인

모두 구해주었으니 최종 페이로드는 | buffer 260 | ret 4 * 7 | execl | 이 될 것이고 아래와 같이 셸을 획득할 수 있다

[그림 9] - 셸 획득

#About

[그림 1] - 문제 파일 확인

Find Key

#Solution

문제로부터 192MB의 메모리 덤프 파일을 확보했으며, 시스템의 운영체제 정보를 먼저 확인해보았다

[그림 2] - 운영체제 정보 확인

확인 된 정보를 인자로 하여금 아래와 같이 프로세스 목록을 살펴 보았다

[그림 3] - 프로세스 목록 확인

프로세스 목록을 확인 결과, 이전 문제와 비슷한 이름의 프로세스인 KeePassX.exe가 상주하고 있었으며 곧 바로 메모리 덤프파일로 추출했다

[그림 4] - 메모리 덤프를 통한 KeePassX.exe 파일 추출

프로세스 덤프 작업을 진행 후 , 이전 문제와 같이 strings 명령을 통해 아래와 같이 결과 값을 result.txt로 추출해주었다

[그림 5] - strings 명령을 통한 결과 값을 result.txt로 리다이렉션

[그림 6] - Key 값 확인

FLAG = md5('7cU6QQKCqxCoHp6ii5WrBCUzVzUGzuS5')

#About

[그림 1] - 문제 파일 확인

Find the Key

#Solution

문제로부터 191MB의 메모리 덤프 파일을 확보했으며, 먼저 디스크 덤프를 뜬 시스템의 운영체제 정보를 확인해보았다

[그림 2] - 운영체제 정보 확인

Suggested Profile 필드로부터 WinXPSP2x86, WinXPSP3x86임을 확인했고, 프로세스 정보를 확인하기위해 아래와 같이 인자로 넣어주었다

[그림 3] - 프로세스 목록 확인

프로세스 목록 확인 결과, [그림 1]에서 확인할 수 있듯 문제 파일명을 미루어 봤을 때 Key 값을 가지고 있는 것으로 

의심되는 PassKeep.exe라는 이름의 프로그램이 실행되고 있었으며, 아래와 같이 메모리로부터 추출해냈다

[그림 4] - 프로세스 덤프

프로세스 덤프 후, 해당 덤프 파일에 존재하는 스트링 값을 확인하기 위해 아래와 같이 텍스트 파일로 추출해주었다

[그림 5] - strings 명령을 통한 결과 값을 result.txt로 리다이렉션

[그림 6] - Key 값 확인

FLAG = md5('J5XfFsmdrBkRE')