[Digital Forensic] 악성코드 포렌식

2020. 5. 20. 17:55

[Digital Forensic] 악성코드 포렌식 (Malware Forensics)

(1) 악성코드 포렌식(Malware Forensics)이란?

디지털 포렌식은 크게 두 가지로 나누게 되면 침해사고 포렌식과 법정 증거를 수집하여 분석하는 법정 포렌식으로 나눌 수 있음
일상적으로 이야기하는 디지털 포렌식은 법정 증거를 수집하여 분석하는 법정 포렌식이므로 정확하게 구분지어 이해해야 함

악성코드 포렌식은 침해사고 포렌식에 속하는 분야라고 할 수 있다.

적법 절차를 거쳐 증거를 수집한 후 여러 무결성 조치를 취해 증거를 보존하며 분석 해 법정에 제출하는 것이 주 목적이 아닌 침해사고의 원인과 침해 정도, 침해에 알맞은 대응, 침해 시스템에서 흔적을 수집 및 분석하여 침해사고를 일으킨 장본인을 추적하는 분야이다.

다음 내용은 일상적으로 악성코드 포렌식을 수행할 때의 일반적인 수행 과정이다.

1-1. 침해 시스템 발견

침해 시스템은 대부분 눈으로 보이는 피해를 가지고 있기도 하지만, 눈으로 보이지 않는 피해를 가지고 있기도 함
그러므로 분석 전 여부는 침해 시스템의 소유주와의 인터뷰를 통해 결정하는 것이 좋은 방법
만약 침해 시스템으로 의심이 된다면 악성코드에 의한 침해인지, 해킹에 의한 침해인지 판단
악성코드에 의한 침해라면 [그림 1] 과 같은 수행 과정을 수행해야 함

1-1-1. 휘발성 데이터 수집 (메모리 덤프 포함)

침해 시스템이 활성 상태라면 당연히 휘발성 데이터를 수집해야 함
간혹 악성코드들은 난독화가 되어 있는 경우가 있음
이럴 때 메모리 덤프를 수집해 두면 추후에 난독화 되어 있지 않은 악성코드를 메모리에서 추출하여 손쉽게 악성코드 분석이 가능

1-1-2. 시그니처 기반 분류

침해 시스템에 있는 실행파일들을 시그니처 별로 분류하여야 함
이는 툴로 수행하는 과정으로 해시 셋 적용 과정을 수행하기 위한 준비 단계라고 볼 수 있음

1-2. 해시셋 적용

해시 셋은 화이트 리스트 해시(White List Hash)와 블랙 리스트 해시(Black List Hash)로 나뉨
화이트 리스트 해시는 알려진 정상 파일들에 대한 해시 데이티베이스
블랙 리스트 해시는 알려진 악성 파일들에 대한 해시 데이터베이스
대표적으로 미국 국립표준원(NIST)에서 진행하고 있는 NSRL 프로젝트가 있으며, NSRL 프로젝트는 화이트 리스트 해시 데이터베이스를 기반으로 계속해서 알려진 정상 파일들의 해시 추가와 데이터베이스 관리를 진행
배포는 RDS(Reference Data Set)을 활용하여 매년 4번(3월, 6월, 9월, 12월)에 진행하며, 각 운영체제와 패치별로 데이터베이스를 생성하여 배포
하지만 NSRL의 해시 셋을 우리나라에 적용하기에는 약간의 문제가 있으며, NSRL은 미국이 주도적으로 하고 있기 때문에 국내 파일들에 대한 해시가 추가되어 있지 않으며, 다국어 운영체제에 대한 지원이 아직까지 미흡하기 때문
그러므로 화이트 리스트 해시 또는 블랙 리스트 해시를 적용한 결과에서 아무런 결과도 얻지 못했다고 하여 해당 시스템이 침해 시스템이 아니라는 판단을 하는 것은 굉장히 위험한 판단

1-3. 1차 분석

해시 셋에서 만약 검색 결과를 얻지 못한다면, 이제는 침해 시스템 분석을 통해 침해사고를 일으킨 악성코드 파일을 찾아야 함

1-3-1. 아티팩트 수집 / 분석

악성코드 파일을 찾기 위하여 여러 가지 흔적들을 수집하는 과정
해당 과정에서 수집한 흔적과 침해 시스템의 소유주 또는 관리자의 인터뷰를 토대로 악성 파일을 추측 / 발견해 내야 함

1-3-2. 동적 분석

빠른 대응을 위하여 우선 동적 분석을 통해 악성 파일이 어떤 행위를 하는지 파악해야 함
대표적인 동적 분석으로는 파일 생성 / 삭제 감시, 레지스트리 변경, 네트워크 통신 등이 있음

1-3-3. IOC(침해지표)

IOC(Indicator Of Compromise)는 한 문장으로 표현하면, "여러 침해사고의 흔적들을 일정한 포맷으로 정리해 놓은 문서 또는 파일"이라고 표현
IOC 관련 표준으로는 대표적으로 CSIRTs(Computer Security Incident Response Teams)의 IODEF(The Incident Object Description Exchange Format, RFC 5070)이 있음
문서를 보면 여러 개의 그룹별로 엔트리를 나누어 해당 포맷을 작성하는 사람이나 보는 사람이 이해하기 편하도록 구성되어 있음
이와 같은 개념을 바탕으로 확장성을 겸비한 Mandiant사의 OpenIOC가 탄생했다고 볼 수 있음

그렇다면 IOC, 즉 침해지표는 왜, 어디서, 어떻게 사용을 할까?

침해 지표의 이름 그대로 사용처는 대부분 침해사고 부분이다.

보통 침해사고는 악성코드에 의한 침해사고를 생각하기 쉬운데 OpenIOC의 프로젝트 목적을 보면 악성코드 침해사고는 물론 해커에 의한 침해사고에도 IOC가 적용되게끔 설계했다고 나와 있다.

그리고 IOC를 이용해 침해사고 PC에서 흔적을 찾아내는 것 뿐만이 아닌 해당 침해지표를 이용해 여러 방화벽이나 탐지 시스템, 차단 시스템의 룰을 정의할 수 있도록 포맷 자체를 간단히 OR, AND와 Item을 직관적으로 표현해 두었다.

IOC는 XML을 이용하여 작성할 수도 있고, Mandiant사에서 제공하는 IOC Editor를 이용해 작성할 수도 있다.

그렇다면 IOC 프로세스는 어떠할까?

다음 내용은 IOC의 LifeCycle이다.

IOC의 LifeCycle에 진입을 하게 되면 먼저 IOC를 생성하게 된다. (IOC Creation)

생성할 때의 내용은 기본적인 침해사고의 흔적들인데 흔적들로는 대표적으로 파일 해시 값, 네트워크 트래픽 또는 통신 서버의 주소(Domain or IP), 레지스트르 키 또는 값, 프로세스명 등을 예로 들 수 있다.

다음으로 생성한 IOC를 여러 기관들에게 배포하게 된다. (Deploy IOCs)

배포했을 때, IOC는 독립적으로 침해사고의 지표가 될 수 있지만, 기관의 성격에 따라 IOC를 근거로 침입 관련 시스템의 룰로 재생성 될 수 있다.

배포가 되었다고 끝이 나는 것이 아니다.

현대의 침해사고는 굉장히 많은 변형을 생산해 낸다.

그러므로 추가적인 침해가 의심되는 시스템을 분석해야 한다. (Identify Suspect Systems)

추가적으로 분석해야 할 시스템이 선정되면 침해사고와 관련된 흔적들을 수집한다. (Preserve / Collect Evidence)

마지막으로, 수집 된 증거들을 분석한다. (Analyze Data)

그리고 분석한 결과를 IOC 포맷으로 작성한다. (IOC Creation)

IOC는 한 번으로 끝나는 것이 아니라 계속해서 증거 수집과 분석을 통해 IOC 자체를 확장시켜야 한다.

그러므로 위와 같은 LifeCycle이 절대적으로 필요하며, 멈추어서는 안된다.

1-3-4. 백신 검사

백신 검사 단계를 의아하게 생각하는 사람도 있을 것이지만, 물론 침해 시스템이 백신이 설치되어 있었고 악성 파일을 탐지할 수 있었다면 침해사고가 일어나지 않았을 것이다.

백신이 탐지하지 못했기 때문에 침해사고가 일어난 것이 대부분인데 왜 백신 검사 과정이 포함되어 있을까?

이유는 실시간 분석은 대부분 악성 파일 데이터베이스 기반으로 하는 경우가 많다.

그러므로 백신에서 지원하는 휴리스틱 탐지 등을 이용해 악성 파일을 검사해보고 실제 악성 파일인지 확인해 보는 것이다.

1-4. 2차 분석

1차 분석 결과를 토대로 2차 분석을 수행하는데, 사실 흐름도에서는 표시가 되어 있지 않지만 이 부분에서 초기 대응이 이루어져도 좋음
2차 분석의 주요 목적은 침해 시스템의 손실 및 복구, 추적
요즘은 큰 사건의 경우 조직적으로 움직이는 단체에 의해 공격 받는 경우가 대부분이어서 실체를 추적한다 하여도 실체 파악까지만 가능하고, 실제 검거 등의 과정은 많은 어려움을 겪음
하지만 계속해서 이런 과정들의 절차가 간소화되고 추적 기술도 나날이 발전하고 있어 빠른 시일내에 침해사고 원인을 제공한 이들의 검거가 이루어질 것임

1-4-1. 파일 시스템 분석

침해 시스템에서 가장 많은 피해는 저장소
저장소에서는 다연히 파일 시스템이 존재하기 때문에 파일 시스템 조사를 통해 손상되거나 삭제된 파일이 있는지 파악하고 이러한 파일들에 대해서는 조금의 가능성이라도 있다면 당연히 복구 과정을 수행해야 함
또 사용자가 생성한 여러 파일들 말고 시스템이 생성한 로그 등의 유용한 정보가 저장된 파일들을 파괴했을 수도 있음
이러한 파일들도 사후 분석에 사용을 하기 위해 복구해야 함
해당 과정은 파일 시스템의 전반적 이해가 필요

1-4-2. 타임라인 분석

침해 시스템에 언제, 어떻게 악성 파일이 침투하여 침해사고를 일으켰는지 밝혀내야 함
이때 각 침해사고 단계를 정리하고 분석하여 시간별로 나열 하여 시간 별 악성 파일의 행동을 추적하고 문서화 해야 함
특히 큰 사건의 경우 타임라인 분석은 굉장히 중요
타임라인 분석에 따라 침해사고의 책임을 질 사람이 바뀔 수도 있고, 앞으로의 침해사고 전개를 잘못된 방향으로 이끌 수도 있기 때문

1-4-3. 정적 분석

이제부터는 정식 대응을 시작해야 함
그러기 위해서는 악성 파일이 정확히 어떻게 악성 행위를 하는지 밝혀내야 함
취약점으로 침해 시스템에 침투하고 장악한 것인지, 또 자신의 사본을 생성해 숨겨놓았는지 등에 대한 행위는 정적 분석을 통해 알아내는 것이 가장 정확
동적 분석으로도 이런 것들을 알아낼 수는 있지만, 동적 분석의 경우 시스템에서 동작하는 프로세스의 모든 활동을 감지하고 그 가운데 악성 파일의 행동을 추출해내야 하기 때문에 분석하는 사람이 놓치는 부분이 있을 수도 있음

1-5. 대응

지금까지 분석한 결과를 토대로 침해 시스템에 알맞는 대응을 해야 함
대응에는 여러 종류가 있으며, 공통적으로 대응하는 부분은 네트워크 통신 차단, 악성 파일의 서비스 등록 삭제, 원본 파일 삭제 등이 있음
만약 대응하는 기간 도중 변종이 침해 시스템에 침투한 것을 발견한다면 다시 해당 변종의 침해 여부와 침해 정도 등을 파악하고 대응하기 위해 1차 분석부터 다시 수행해야 함
해시셋 적용부터 하지 않는 이유는 변종이라는 것은 기존 악성 파일이 변형된 것이기 때문에 해시 셋에 등록되어 있지 않기 때문

1-6. 종료

모든 대응이 끝나면 지금까지의 과정들은 문서화 되고, 보고 체계에 의해 보고 되어야 함
그 후에 악성코드 포렌식 수행을 종료

여기서 중요한 것은 과연 꼭 저러한 수행 과정을 통해 악성코드 포렌식을 수행해야 하는지이다.

아직까지 악성코드 포렌식의 수행 과정은 표준화 되지 않았고 악성코드 포렌식이라는 부분도 침해사고 대응과 많이 중복되는 부분이 있어 그 정립 자체가 불분명하다.

침해 시스템에 따라 [그림 1]과 같은 수행 과정을 수행할 수 있기도 하고 수행하지 못할 수도 있다.

그러므로 침해 시스템에 따라 수행 과정을 조금씩 변경하여 해당 침해 시스템에 적합한 수행 과정을 그릴 수 있는 능력을 길러야 한다.

그리고 꼭 "침해사고는 완전히 막을 수 없다"라고 생각하여아 하며, "침해사고를 완전히 막는다"라는 의미는 불현실성이 굉장히 많은 문장이며 사람의 보안 인식을 안일하게 만든다.

그러므로 매번 대응을 할 때마다 최선을 다하여 대응하고 추후에 있을 침해사고를 예측하고 예측 침해사고에 대한 대응 방안을 수립하는 자세를 가져야 한다.

(2) 악성코드 포렌식을 하기 위해 준비해야 할 것

2-1. 악성코드 포렌식을 수행하기 위한 환경

악성코드를 로컬에서 분석하는 분석가는 아마 없을 것이며, 요즘은 가상화 환경이 굉장히 구축이 잘 되어 있어 악성코드를 자신의 로컬 환경 내부의 가상화 환경에서 분석해도 무리가 전혀 따르지 않음
그러므로 자신의 분석 시스템에 적합한 가상화 환경을 구축하고 가상화 환경 내부에 여러 가지 도구들을 저장하여 분석 수행 시 빠르고 정확하게 분석할 수 있도록 평상시에 준비하고 있어야 함
간혹 가상화 환경을 탐지하여 실행되지 않는 악성코드가 있을 수도 있으니 가상화 환경에 대한 이해도 당연히 되어 있어야 함
그래야 악성코드가 탐지하는 가상화 환경의 특징을 변경해 악성코드이 가상화 환경 탐지를 우회할 수 있기 때문

2-2. 리버스 엔지니어링 (리버싱)

리버스 엔지니어링이란, 완전한 소프트웨어 또는 문서를 역으로 분석하여 원래의 소스코드 또는 데이터를 얻는 기술을 말함
우리말로는 흔히 역공학이라고 하며 해당 기술을 익히기 위해서는 굉장히 많은 시스템 지식이 필요
대표적으로 어셈블리어, 운영체제, 파일 구조(PE, ELF 등), 프로그래밍 언어 등이 있음
악성코드 정적 분석 과정에서 리버스 엔지니어링 기술이 사용된다고 보면 됨
흔히 말하는 디버깅과는 개념에서 약간의 차이가 존재하므로 정확하게 이 둘을 구분하고 구사하는 것이 중요

2-3. 흔적(아티팩트) 수집 / 분석 능력

원본 악성코드를 찾고 해당 악성코드가 어떻게 생성되었는지 파악하기 위해서는 악성코드가 운영체제가 생성한 흔적을 찾을 수 있어야 함
악성코드의 대부분은 Windows 이므로 Windows에서 생성되는 여러 흔적들에 대해 알고 있어야 함
수집할 수 있는 능력과 분석할 수 있는 능력도 준비되어 있어야 함

2-4. 여러 가지 도구 사용법

디지털 포렌식 분야 자체가 시스템의 굉장히 낮은 레벨의 데이터들을 다루기 때문에 사람이 수동적으로 접근할 수 있는 부분에는 한계가 존재
악성코드 포렌식도 이와 마찬가지로 사람이 수동적으로 접근하거나 모니터링 할 수 있는 부분이 굉장히 극소수
그러므로 악성코드를 분석할 때에는 여러 기능들을 지원하는 도구들을 미리 사용해보고 그 방법을 숙지하고 있어야 함
악성코드 분석 툴이란 카테고리는 정해진 것이 없으므로 자신이 필요한 기능을 지원하는 도구들을 찾아 그 사용법을 익혀야 함

2-5. 여러 가지 보안 지식

분석을 할 수 있지만 그에 맞는 대응 방안을 수립하지 못한다면 완전한 악성코드 포렌식을 수행할 수 없음
그러므로 보안 뿐만이 아닌 IT 분야 전체의 기본이 되는 시스템, 네트워크 등의 지식을 갖추고 있어야 함
보안 대책 수립 방법(서버 설정, 네트워크 트래픽 설정, 장비 설정 등) 등에 대한 지식도 갖추고 있어야 함

지금까지 나열한 여러 가지 요소들 말고도 전반적으로 보안 분야와 IT 분야에 대한 지식이 많아야 한다.

악성코드는 꼭 우리가 생각하는 시스템, 네트워크만 공격하는 것이 아니기 때문에 언제 어떤 시스템이 공격당하고 우리가 그 시스템을 대응조치 해주어야 할지 모르기 때문에 평상시에 차근차근 준비해야 한다.

(3) 결론

악성코드 포렌식은 침해대응 업무에 거의 속하는 분야이기 때문에 꼭 디지털 포렌식을 전문으로 하는 사람이 아니더라도 관제, 침해대응, 악성코드 분석 등의 업무를 하는 사람도 모두 할 수 있는 극히 드문 포렌식 분야 중 하나이다.

디지털 포렌식 분야는 일전에도 언급하였지만, 디지털 포렌식 분야만의 새로운 기술은 많지 않다.

그렇기 때문에 누구나 관심을 갖고 공부만 한다면 누구나 디지털 포렌식을 수행할 수 있지만, 누구낙 디지털 포렌식을 수행한다고 하여 디지털 포렌식 전문가라고 할 수는 없다.

디지털 포렌식 전문가와 일반 보안 전문가의 차이는 숙달과 훈련, 지식의 차이에 있다.

모든 분야가 그렇겠지만, 디지털 포렌식은 특히나 더 그렇다.

숙달되지 않은 자가 어중간하게 디지털 포렌식을 수행한다면 수행하지 않은 것만 못하다.

악성코드 포렌식도 이러한 이유에서 침해대응이 아닌 악성코드 포렌식으로 따로 분류되는 것이며, 숙달되지 않은 자가 침해사고 시스템을 분석하면 실수로 중요한 원인 프로그램이나 유출 흔적 등을 훼손 시킬 수 있다.

그러므로 악성코드 포렌식이 어떤 전문가나 누구든지 할 수 있다고 하여 가볍게 생각하지 말고 정확하고 깊게 공부해야 한다.

# Reference

http://www.yes24.com/Product/Goods/8511539

저작자표시

'Digital Forensics > Forensic Theory' 카테고리의 다른 글

[Digital Forensic] 이미지 포렌식 (0)	2020.05.18
[Digital Forensic] 클라우드 보안과 디지털 포렌식 (0)	2020.05.17
[Digital Forensic] 디지털 포렌식 관련 법규 (0)	2020.05.11
[Digital Forensic] 디지털 포렌식 어카운팅 (0)	2020.05.11
[Digital Forensic] 디지털 포렌식 준비도 (0)	2020.05.11

Yum_Yum