흔히들 로카르트의 원리(Locard's exchange principle)라고 불리는 법칙이 있다. 접촉하면 흔적이 남는다는 것이다.

Every contact leaves a trace.

이는 법의학의 근간을 이루고 있는 이론이며, 디지털 포렌식에서도 동일하게 적용된다. 


리눅스 시스템에서 diff 라는 명령어가 있는데, 이는 특정 파일이 변동되었을 때 어떻게 변경되었는지를 보여주는 유용한 도구이다. github 같은 형상관리 소프트웨어에서도 특정 시점에 소스코드의 어떤부분이 삭제되고 추가되었는지를 편리하게 보여주는 기능이 있다. 모두 diff 에서 착안한 기법이다.


메모리포렌식을 연구하면서 이러한 생각을 갖게 되었다. 악성코드가 유입되기 전과 후에는 당연히 확연한 차이가 발생하게 된다. 이것을 diff로 비교하면 어떻게 될까?


이 생각을 내가 최초로 한 것이었다면 더 좋았겠지만, 안타깝게도 이미 누군가가 시도한 것 같다 ㅋㅋ 그것을 공유하고자 한다. 관련된 연구로는 VolDiff: Malware Memory Footprint Analysis based on Volatility 라는 윈도우즈 환경에서 악성코드의 메모리 변조내역을 추적하는 프로젝트가 있었고, 이후 비슷한 아이디어로 linux_mem_diff_tool 이 공개되었다. linux_mem_diff_tool에 대한 더 자세한 소개는 Linux Memory Diff Analysis using Volatility 블로그 글을 참고할 것.


악성코드를 분석할 때마다 분석가가 직접 악성코드에 의한 데이터 변동을 일일이 분석하기에는 굉장한 시간과 노력이 소요된다. 하지만 이 도구를 사용하면 clean한 상태의 메모리 스냅샷과 infect 상태의 스냅샷을 비교하여, 어떠한 내용들이 변경되었는지를 빠르게 파악할 수 있게 된다.


본 포스팅에서는 리눅스 환경을 기준으로 설명한다. 먼저 해당 툴을 다운로드하자. python 2.7에서 작성된 코드이다. 

해당 파일을 열어서 몇몇 부분의 환경설정을 수정해야 한다.

python_path = r'' 부분을 수정하여 자신의 리눅스 시스템의 파이썬 경로를 지정하고, vol_path에는 볼라틸리티가 설치된 경로를 지정한다. 반드시 vol.py 까지 맞추어주어야 한다. 그 아래에는 메모리 이미지 파일과 프로파일, 그리고 리포트 보고서를 저장할 경로를 지정하는데 굳이 지정안해도 실행시에 arg 파라미터로 지정해도 되므로 그대로 두자.


참고적으로, 현재 psxview 플러그인에서 오류가 발생하고 있다. 그래서 해당 부분을 주석처리(#) 하였다.


다음으로는 악성코드 샘플을 준비하였다. 샘플은 공개하기가 어려운점 양해 부탁드린다. 파일명은 md5 해시함수를 따서 ELF_3A30B8B1CA5DCBE986815A635918483E으로 명명되어있으며, Vadim v.Ibeta by Luciffer 라는 이름의 리눅스 악성코드이다. 실제로 바이러스 토탈에 조회해보면 아래와 같이 악성임이 확인된다.

이미 악성임을 알고 실험하는 것이라 좀 그렇지만, 어쨌든 이 파일은 대상 시스템에 다량의 패킷을 전송하여 시스템에 부하를 가하는 일종의 DoS(Denial-of-service attack)을 수행하는 악성코드이며, 실행 방법은 아래와 같다.

그래서 직접 개인이 가지고 있던 라즈베리 파이를 대상으로 때려(?)보았다.

으어.. 정말로 라즈베리 파이에서 tcpdump로 관찰을 하니 초당 1000패킷이 넘게 공격이 들어왔다. (이상한 점은 아이피를 200.123.21.2 로 스푸핑을 하였으나, 실제로 적용되지 않은 것으로 보인다. 공격했던 리눅스 192.168.0.11의 아이피가 그대로 노출되는 것을 보면 말이다. 아무래도 샘플 멀웨어다보니 ..)


자 그렇다면 본론으로 돌아와서, 만약 분석가 입장에서 해당 멀웨어의 기능을 제대로 파악하지 못한 상태라면 어떨까?


linux_mem_diff 는 악성코드 실행 전과 후를 나누어서 메모리 덤프를 뜨고, 그 내용을 volatility로 분석 한 후 비교분석하는 방법을 제시하는 것이다. 한번 수행해보자. 참고적으로 리눅스 포렌식 분석을 위한 메모리 추출 - LiME, Linux 메모리 분석을 위한 프로파일 생성하기 등을 확인하여 메모리 덤프를 뜨고 프로파일을 생성해두기 바란다.


악성코드를 실행하기 이전의 메모리 덤프를 떠서 clean.lime 으로 저장하였다. 그리고 악성코드를 실행한 상태에서 메모리 덤프를 다시 떠서 infect.lime으로 저장하였다. 간격은 약 30초정도였다. 이제 아래와 같이 linux_mem_diff를 실행해보자.

-c 옵션은 clean한 상태의 메모리, -i 옵션은 감염된 상태의 메모리 덤프의 경로를 의미하며, -p는 볼라틸리티의 운영체제 프로파일 정보를 의미한다. 그밖에 다른 옵션은 특별히 입력하지 않아도 된다. 이것을 실행하면 분석작업이 진행되는데, 시간이 꽤 소요된다.

출처 : http://malware-unplugged.blogspot.kr/2015/09/linux-memory-diff-analysis-using.html
출처 : http://malware-unplugged.blogspot.kr/2015/09/linux-memory-diff-analysis-using.html

분석작업이 완료되면 final_report.txt 라는 이름으로 저장된다. 


프로세스와 관련한 정보이다. 본인이 직접 실행했던 멀웨어 프로세스가 실행되었음을 확인할 수 있다. 이것은 사실 당연한 결과겠지만, 혹여 해당 프로세스가 기타 여러 하위 프로세스를 호출했을 때에도 정확히 간파할 수 있을 것이다.

결정적으로 네트워크 상태를 비교해보면 해당 프로세스가 192.168.0.3 을 향해 5353 포트로 UDP 연결을 수립하는 것이 포착되었다. 네트워크 관련 행위를 하는 것임을 분명히 확인할 수 있는 것이다.

또 한가지 흥미로운 점은 Library 호출과 관련한 내용이다. 이는 볼라틸리티의 linux_library_list 플러그인과 linux_ldrmodules 플러그인의 결과를 비교분석한 결과이다. 각각 프로세스의 shared object(.so) 내용을 확인할 수 있는데, 기존 clean 상태에 비해 infect에서 공통적인 부분은 제외하고, 추가적으로 실행된 것만 선별하여 보여주므로 해당 악성코드가 호출한 라이브러리 목록만 골라서 볼 수 있는 것이다. i386-linux-gnu/libc.so를 사용하는 것을 보면 아마 공격자는 해당 악성코드를 C언어를 사용해서 GCC 컴파일러를 사용해 프로그래밍한 것으로 보인다. 보다 정확한 분석은 정적분석을 해보아야 알 수 있다.

그 밖의 Kernel 의 변화, Hidden module, System call 호출이력 등 변경된 다양한 정보들을 손쉽게 비교분석할 수 있다는 큰 장점이 포인트이다.


물론, 해당 악성코드가 아닌 다른 기본 프로그램에 의해 해당 시간에 메모리 변조가 발생할 여지도 충분히 있다. 예를 들어, 메모리 덤프를 추출하는 과정에서 발생한 커맨드나 VMware Tools 에 의한 변화는 무시해야 하는데 이러한 오탐은 사람의 판단이 필요한 영역일 것이다.


본 예제에서는 악성코드를 직접 구하기가 어려워서 아주 간단하고 단순한 것으로 설명하다보니 결과가 아주 화려해보이지는 않았다. 하지만 제작자의 블로그에 보면 Tsunami, Xingyiquan Rootkit, Average Coder Rootkit 등 실전 멀웨어 대해 Mem Diff 를 사용해서 분석한 내용이 자세히 기술되어 있으니 참고하기 바란다. 

출처 : http://malware-unplugged.blogspot.kr/2015/09/linux-memory-diff-analysis-using.html
출처 : http://malware-unplugged.blogspot.kr/2015/09/linux-memory-diff-analysis-using.html
출처 : http://malware-unplugged.blogspot.kr/2015/09/linux-memory-diff-analysis-using.html
출처 : http://malware-unplugged.blogspot.kr/2015/09/linux-memory-diff-analysis-using.html


참고 :http://malware-unplugged.blogspot.kr/2015/09/linux-memory-diff-analysis-using.html

CPUU님의 창작활동을 응원하고 싶으세요?