Test

#About

크레센도 그룹의 보안담당자 A씨는 퇴사자 D씨의 정보유출 여부를 분석하는 업무를 수행 중이다. 분석 도구로 D씨의 하드디스크를 검사한 결과 대부분의 데이터가 0으로 덮어 쓰기 되어 있었다. 그러나 다행히도 IconCache 파일은 온전히 복구할 수 있었다. 주어진 IconCache파일을 통해 퇴사자 D씨가 실행한 데이터 삭제 프로그램의 이름을 추출하시오

답 포맷 : 드라이브 문자를 포함한 절대 경로

Ex) G:\tool\DataDelete.exe

#Solution

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

문제에서 제공받은 IconCache.db 파일을 확인했으며, 위 파일은 명칭 그대로 아이콘의 캐시가 쌓이는 일종의 데이터베이스 파일이다

[ + ] Thumbnail

아이콘 캐시는 썸네일 캐시와 비슷한 개념으로 정보를 캐시해둔 뒤 재방문 시에 캐시된 데이터를 보여줌으로써 속도 향상을 위해 고안되었다

썸네일 캐시는 그래픽 이미지를 축소한 것으로 많은 양의 이미지를 빠르게 탐색하기 위한 것이며 윈도우 폴더 미리보기 기능에 사용한다

또한 한번 저장된 썸네일은 원본 파일이 삭제되더라도 삭제되지 않는 특징을 가지고 있으며, 썸네일을 확인해 보았다

[그림 2] - ThumbCache 정보 확인

저장된 썸네일 캐시에서, [그림 1]의 사진을 사용하기 위해 저장해두었던 파일이 자동으로 캐시되어 있음을 확인할 수 있었으며 지웠던 개인적인 

사진이 캐싱되어 썸네일로 저장되있음도 확인했고, 이를 통해 썸네일 캐시는 포렌식에 충분히 이용될 수 있음을 생각할 수 있다

썸네일을 지원하는 확장자는 JPEG, BMP, PNG, GIF, TIF, PDF, PDF, PPTX, DOCX 등이 존재하며 썸네일은 파일 미리보기 시에 자동으로 캐시되기에 

이미지, 동영상, 문서 파일과 같은 특정 파일의 존재 유무를 판단할 수 있으며 문서 파일의 경우 첫 페이지가 캐시되기에

문서의 내용을 확인 가능하며, 음란물이 담긴 동영상일 경우 열람 시 역시 캐시되어 아청법 조사에 활용이 가능하다 

썸네일 캐시가 저장되는 데이터베이스 파일의 위치는 아래와 같다

[그림 3] - 썸네일 저장 경로

[ + ] IconCache

아이콘 캐시는 썸네일 캐시와 비슷한 기능을 하며 폴더 내용 확인 시 로드되는 아이콘이 캐시된다 따라서 아이콘 캐시는 아래와 같이 활용될 수 있다

외부저장매체 사용 흔적 확인

로컬 시스템에 USB와 같은 외부저장매체를 연결 한 뒤 탐석기를 통해 외부저장매체를 확인하면 외부저장매체에 위치한 아이콘이 로컬에 캐시된다 다만 이는 외부저장매체에 고유한 아이콘 리소스가 포함된 실행파일이 존재할 때 유효하며, 유일한 아이콘이 아닐 시 외부저장매체를 특정하기 어렵기 때문이다

안티 포렌식 도구 사용 흔적 확인

전문적인 안티 포렌식 도구는 대부분 고유한 아이콘을 가졌기 때문에 로컬 또는 외부저장매체에서 안티 포렌식 도구를 사용했다면 해당 안티 포렌식 프로그램의 아이콘이 캐시된다

악성코드 흔적 확인

악성코드에 아이콘 리소스가 있다면 캐시되므로 아이콘 캐시 분석을 통해 악성코드의 경로를 확인할 수 있지만 애드웨어류를 제외한 나머지는 아이콘 리소스를 잘 포함하지 않으므로 기대지수가 낮은게 일반적이다

프로그램 사용 흔적 확인

고유한 아이콘을 가진 프로그램이라면 아이콘 캐시의 분석을 통해 설치 또는 실행 흔적을 알 수 있다

출처 = forensic-proof.com

문제로 돌아와 해당 IconCahe.db에 담긴 정보를 Hex Editor를 통해 확인할 수 있었으며 IconCache의 구조는 아래의 링크를 참조하길 바란다

https://brunch.co.kr/@bl4cksh33p/4

[그림 4] - diskwipe.exe 확인

Answer = f:\mytools\diskwipe.exe

#About

J씨는 웹서핑을 하던 도중, 인터넷의 속도가 급작스럽게 저하되는 현상을 경험하였고, 이를 이상하게 여겨 평소에 보안을 공부하던 당신에게 

분석을 의뢰하였다. J 씨의 PC를 공격한 해커의 IP Address와 공격 명칭을 적시오.

(공백은 생략하며 플래그 형식은 공격명칭_IP Address 이다.)

#Solution

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

문제의 시나리오에서 제공받은 파일을 열었을 때, 총 20,824개의 패킷을 확인할 수 있었다

문제의 상황은 인터넷 속도의 급작스러운 저하이며, 이는 과도한 트래픽 또는 시스템 자원을 부족하게 하여 원래 의도된 용도로 

사용하지 못하게 하는 서비스 거부 공격을 당했을 때 나타나는 특징과 같다. 따라서 DoS Attack의 공격 종류와 그 특징을 알아야 한다

[ + ] 서비스 거부 공격의 종류

Land Attack

공격자는 타겟의 IP로 변조하여 ICMP 패킷을 브로드캐스트로 다수의 시스템에 전송 하는 것이며, 결과적으로 다수의 시스템은

타겟의 IP로ICMP 응답 패킷을 전송하게 되면서, 타겟의 PC는 다수의 시스템으로부터의 패킷을 받음에 있어 성능이 저하된다

Ping of Death

공격자는 타겟에게 ICMP Echo Request 패킷의 크기를 정상보다 크게 만들어 전송하며, 타겟 네트워크에 도달하는 동안 패킷은 

단편화되며 결과적으로 타겟의 PC에서 단편화된 패킷을 모두 처리해야하므로 정상적인 패킷보다 많은 부하가 걸리며, 성능이 저하된다

Smurf Attack

출발지 주소를 타겟의 IP로 설정 한뒤, ICMP 패킷을 네트워크 전체에 브로드캐스팅 하며 결과적으로 ICMP 응답을 처리하는 타겟의 PC는 성능이 저하된다

Tear Drop

정상적으로 패킷을 전송할 때, 데이터의 송신 한계를 넘으면 최대 전송 단위인 MTU(1500Byte)로 나누어 보내는 단편화가 발생한다. 해당 공격 기법은 

IP 패킷에 있어 offset 중첩을 이용한 공격이며 단편화 된 패킷사이에 오프셋이 붙게 되면서 패킷 재조합 과정에서 기존의 패킷의 사이즈보다 커지는 

오버플로우가 발생하게 되며 결과적으로 시스템에 오류가 생긴다

SYN Flooding

TCP 프로토콜의 3-Way Handshaking의 연결 과정의 취약점을 이용한 것으로 공격자는 IP Spoofing 과정을 진행 한 후, SYN 패킷을 타겟에게 전송한다. 

타겟은 SYN/ACK 패킷을 전송한 뒤 대기하며 공격자는 세션 성립을 위한 ACK 패킷을 보내지 않고 계속 새로운 연결만 요청한다 타겟은 자원 할당을 

해지하지 않고 자원만 소비하여 부하가 걸리며 결과적으로 속도가 저하된다

위 공격 기법이외에도 TCP Flag Flooding 또는 HTTP 데몬의 개수를 초과시키는 공격등 다양한 공격이 존재하며 서비스 거부에 해당하면 모두 DoS 공격이다

서비스 거부 공격의 흔적을 찾기 위해 패킷을 살펴보다 아래의 그림에서 포트 스캐닝 흔적에 해당하는 패킷을 확인할 수 있었다

[그림 2] - SYN  플래그를 이용한 포트 스캐닝 흔적 확인

IP주소 192.168.37.130에서 192.168.38.134로 SYN 플래그를 이용한 Half-Open 포트스캐닝을 지속적으로 진행했다

192.168.37.134의 서버는 닫혀있거나 스캐닝을 방지해두었는지 ACK+RST 패킷으로 응답패킷을 다시 192.168.37.130으로 보내고 있다

포트 스캐닝 자체에 있어서는 문제의 답과 거리가 멀 수도 있지만, 포트스캐닝이 지속적으로 이루어짐에 따라 의심이 생겼고

아래와 같이 Source IP가 192.168.37.130이며 Destination IP가 192.168.37.134인 패킷을 필터링해 보았다

 [그림 3] - 필터링 식 적용

필터링 식을 적용한 패킷만 보았더니 192.168.37.130에서 192.168.37.134로 지속적이며 대량의 SYN 패킷을 보내고 있음을 확인했고

이를 통해, J씨(192.168.37.134)는 웹서핑 도중 192.168.37.130의 IP를 가진 해커에 의해 SYN Flooding 공격받은 증거를 확인할 수 있었다

Answer = SYNFLOOD_192.168.37.130

[ + ] 공부할 겸 작성

Tiny Fragment Attack

최초의 패킷 조각을 매우 작게 만들어 네트워크 침입 탐지/방지 시스템인 IDS와 IPS(이하 패킷 필터링 장비)를 우회하는 공격을 의미한다 

패킷 필터링 장비는 최초 유입 패킷의 포트 번호를 확인한다. 하지만 포트번호가 포함되지 않을 정도로 단편화 된 패킷의 첫 번째 조각을 

통과 시키게되면 실제 포트번호가 포함되어 있는 두 번째 패킷은 필터링을 거치지 않고 통과하게되며 결과적으로 목적지에서 재조립되면서 

패킷이 정상적으로 전달된다.

Fragment overlap Attack

단편화 된 패킷의 첫 번째 조각에는 패킷 필터링 장비에서 허용하는 포트와 같은 포트를 전송하고 두 번째 조각에선 오프셋을 매우 작게 

하여 전송한다. 패킷 필터링 장비에서 첫 번째 조각은 허용된 포트이므로 통과 시키고, 두 번째 조각은 이전에 이미 허용된 조각의 ID를 

가지므로 역시 통과시킨다. 목적지에 도달한 두 개의 패킷 조각이 재조합 될 때 두 번째 조각의 포트번호가 첫 번째 조각의 포트번호로 

overwrite 하게 되며, 이는 Tiny Fragment Attack 보다 정교한 공격 기법에 속한다 

SYN FLOODING 공격 예방 => http://blog.pages.kr/460

Update : 2017-11-28 AM 03:12

[그림 3]의 간단한 필터식 이외에도 아래와 같이 조금 더 구체적으로 필터링을 적용 시켜줄 수 있음

[그림 4] - 구체적인 필터식 적용을 통한 SYN FLOODING 확인

#About

당신은 당신의 친구인 A씨가 요즘 무언가를 열심히 찾는 모습을 발견하였고, 무엇인가 궁금하여 패킷을 캡쳐 해 내었다.

패킷 분석을 통하여 A씨가 검색한 키워드를 찾아내시오.

(검색 키워드간의 구분은 : 문자로 한다.)

#Solution

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

패킷 파일의 확장자는 pcapng이며 해당 파일의 구조가 궁금하다면 http://croas.tistory.com/1?category=265614 를 참조하길 바란다

해당 파일의 분석은 와이어샤크와 NetworkMinor라는 도구 및 파이썬과 파이썬 기반의 scrapy로도 할 수 있지만 Network Minor는 

Professional 버전일 경우에만 pcapng 파일을 분석할 수 있으며 파이썬은 시도해보았지만 무슨 이유에서인지 

dpkt 모듈을 이용한 패킷 파일 구조 분석이 되지 않았으며 스카피는 별도로 설치 과정을 거쳐야하므로 무난하게 와이어샤크로 분석하도록 하겠다

[그림 2] - 패킷 파일 열람

위 그림은 패킷 파일을 와이어샤크로 열었을 때의 화면이며 문제에서 요구하는 것은 A씨가 검색한 키워드이므로 A씨는 검색을 할때 서버에게 자원을 요청하기 위해 HTTP Request에서 GET 방식을 사용했을 것이므로 아래와 같이 필터링을 해주었더니 A씨가 검색한 키워드를 확인할 수 있었다

[그림 3] - Method GET 필터링

Method GET만 이용한 패킷만 보았을 때 패킷번호 16,075번에서 확인할 수 있었으며 검색한 키워드는 아래와 같다

[그림 4] - 검색 키워드 확인

Answer = forensics_site:CTF_site

사실 이렇게 단순 노동으로 찾기에는 대량의 패킷이 있을 때에는 상당히 비효율적인 방법이므로 추후에 

패킷 분석에 있어 파이썬을 이용할 때 추가 업로드를 진행할 예정이다. 현재는 진행하고 싶어도 잘 되던 dpkt 모듈이 되질 않음

[ + ] Pcapng File Analysis Using Python

update : 2017-11-24

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

'''
Title   : pcapng file analysis
Author  : Loddy
Date    : 2017-11-24 01:20
'''

import dpkt
import socket
import urllib

f = open("C:/packet_file_VXYbsJw.pcapng",'rb')
packet = dpkt.pcapng.Reader(f)
pcapng = packet.readpkts()

for timestamp,buf in pcapng:
    try:
        eth=dpkt.ethernet.Ethernet(buf)
        ip=eth.data
        tcp=ip.data
        http_req = dpkt.http.Request(tcp.data)
        src = socket.inet_ntoa(ip.src)
        dst = socket.inet_ntoa(ip.dst)
        if http_req.uri.find('m?') >=0:
            print '[+] src : {} --> dst : {}'.format(src,dst)
            print '[+] {}'.format(urllib.unquote(http_req.uri))
            print '\n',
    except:
        pass

[그림 5] - 코드 결과

파이썬을 이용하여 와이어 샤크에서 모든 패킷을 보았을 때와 달리, A씨가 검색한 쿼리의 uri만 추출했더니 간단히 확인할 수 있었다