1. 요약

분석 대상은 tigger.exe가 실행 된 후의 메모리이며 환경은WinXP SP2 x86이다. 전체적인 분석 내용은 이후에 좀더 상세히 다루며, 본인이 여기선 조사했던 내용을 간략히 요약하고자 한다.

• Tigger.exe.pf, 329000.exe.pf, tmryqyrznr2.sys라는 의심스러운 MFT 흔적 발견
• Svchost.exe(pid=936)이 tmryqyrznr2.sys라는 문자열을 포함
• Svchost.exe(pid=936)과 관련된 파일에서 방화벽, 후킹에 대한 문자열과 함수 존재
• 329000.exe는 특정 파일, 드라이버, 지속성 위한 레지스트리 관련 함수와 문자열 존재
• 329000.exe는 Virustotal에서도 여러 엔진에서 악성코드가 판정

이와 같이 요약을 할 수가 있으며 이러한 내용에 대해 상세히 설명할 것이다. 순서는 위의 요약과는 다소 다를 수 있다.

2. 분석

분석 대상 환경은 WinXP SP2 x86이다. 분석 시작과 함께 Userassist를 통해 어떠한 프로그램이 실행되었는지 확인을 하여 대상을 좁혀보자. 결과는 아래의 그림과 같으며 tigger.exe가 2010년 8월 15일 19:25:52에 실행된 것을 확인할 수 있다.

Figure 1. Rekall - UserAssist

Pstree를 통해 메모리에서 실행 중이던 프로세스의 목록을 트리 형태로 확인해보자. 위에서 확인했던 tigger.exe가 보이지 않는 것을 확인할 수가 있다. 대신 비슷한 시간대에 실행된 wmiprvse.exe(pid=828)을 확인할 수가 있다. 그 부모프로세스와 그 상위 까지를 대상으로 진행하겠다.

* 추가 : svchost.exe (936)은 추후에 분석을 통해 의심되는 부분이라 생각되어 추가

Figure 2. Rekall - pstree

실행 중인 프로세스 외에 Volatility의 MFTparser Plugin을 통해 MFT 변화 또한 확인해보자. 아래의 그림은 시간대로 정렬하여 나타낸 결과이다.

Figure 3. MFT parser

Tigger.exe가 실행되고 10초 후 pf 파일이 생성되었으며 15초후 329000.exe와 329000.exe.pf가 생성되는 것을 확인할 수가 있다. 17초 후에는 Perfilb_Perfdata_33c.dat파일, 19초 후는 Netsh.exe의 pf파일이 마지막으로 tigger.exe를 실행하고 20초 후에는 tmryqyrznr2.sys가 MFT로 존재하는 것을 확인할 수가 있다.

Figure 4. MFT parser

Tigger.exe와 329000.exe, Netsh.exe는 위의 pstree에서 보았듯이 메모리에 같은 이름의 프로세스로 존재하지 않는 것을 확인할 수가 있다. sys파일의 경우 이름에서 나타나는 불규칙성에서 의심의 여지가 있다. 하지만 관련이 없을 수도 있으므로 추후에 확인을 해보자.

Figure 5. Rekall – unloaded_modules & modscan

우선 tmryqyrznr2.sys를 확인하기 위하여 메모리에 있는 모듈의 리스트를 modscan Plugin을 통해 확인을 하였지만 존재하지 않았다. 따라서 루트킷과 같은 악성코드의 경우 악성 행위를 하고 바로 언로드 시키는 경우도 있기에 언로드된 모듈을 unloaded_modules를 통해 확인했지만 보이지 않았다.

Figure 6. Volatility – yarascan

Volatility의 yarascan Plugin을 통해 해당 문자열(tmryqyrznr2)을 검색해보았다. 그 결과 pid 936인 svchost.exe에서 확인할 수가 있었다. 해당 프로세스를 추출하여 악의적인 행동을 하는지 확인해보자.

Figure 7. Rekall – procdump

Procdump를 통해 해당 프로세스를 추출하였다. 이제 이를 통해 VirusTotal의 백신 엔진들을 통해 악성코드로 의심되는 행위가 있는지를 확인해보자.

Figure 8. Virustotal – svchost.exe(936)

Virustotal을 통한 결과는 위의 그림과 같다. 56개의 엔진 중에서 한 곳에서만 악의적인 행위로 검출이 되었다. 별로 의심의 여지가 없어 보이지만 좀 더 살펴보고자 dumpfiles를 통해 pid 936에 해당하는 파일들을 추출해보았다.

Figure 9. Volatility – dumpfiles

여러 개의 파일이 추출된 것을 확인할 수가 있다. 이 파일들 중 .dat 파일을 위주로 살펴보았는데 의심스러운 문자열이 나타난 부분들을 뽑아 아래와 같이 정리하였다.

0x80fcb6c.dat의문자열은 Hookimports라는 문자열을 통해 후킹과 관련된 문자열들이 여러 부분 존재하는 것을 확인할 수가 있고 0xff3696b0.dat를 통해 Firewall과 관련된 문자열을 확인할 수가 있었다.

Figure 11. Rekall – filescan

이번에는 MFT를 통해 확인 했듯이 PF파일이 생성되었던 329000.exe를 분석해보자. 우선 filescan Plugin을 통해 해당 파일이 메모리에서 추출할 수 있는지를 확인해보았다. 그 결과 위와 같이 Offset이 나오는 걸 볼 수 있다.

Figure 12. Volatility – dumpfiles

Filescan을 통해 얻은 Physical Offset을 지정해주고 dumpfiles Plugin을 통해 추출해보자. 그 결과 2개의 파일이 추출에 성공하는 것을 확인할 수가 있다. 추출된 2개의 파일에 대한 정보는 아래의 표에 정리한 바와 같다.

32900.exe와 관련된 파일에 대해 추출을 성공하였으므로 이제 악의적인 행위를 하는지 확인을 해보자. 여기선 위에서와 같이 Virustotal을 통해 그 결과를 먼저 확인해보자.

Figure 14. Virustotal – 329000.exe

위의 결과와 같이 많은 부분에서 악성코드라 진단되는 것을 볼 수 있다. 어떠한 기능의 파일인지 확인하기 위해 간단하게 문자열과 포함하는 API에 대하여 확인해보자. 확인 결과 문자열과 API 모두 같은 것으로 나타났다.

위의 표를 보면 우선 API에서 파일을 찾기와 관련된 함수들과 읽고 쓰고 이동하는 것까지 확인할 수가 있다. 문자열을 보면 흥미로운 점이 있는데, 지속성을 유지하기 위한 레지스트리 키와 회사 이름이나 저작권에 있어 "Microsoft Corporation"이라는 것을 볼 수가 있다. 이는 윈도우의 일반적인 파일처럼 보이고자 Microsoft의 이름을 사용했다고 볼 수가 있다.

Figure 16. Rekall - filescan

이번에는 filescan을 통해 tmryqyrznr2.sys에 대해 Offset을 알아보자. 그 결과는 위와 같으며 이제 이 주소를 통해 해당 모듈을 추출하여 추가적인 분석을 진행해보자.

Figure 17. Volatility – dumpfiles

여기선 dumpfiles Plugin을 통해 추출을 시도하였다. 그 결과 화면은 위의 그림과 같지만 해당 파일이 생성되지 않는 현상이 나타났으며 그 이유 또한 알 수가 없었다. 따라서 추출이 불가능하므로 메모리에서 해당 파일의 흔적을 찾아보자.

Figure 18. Rekall – driverirp

위에 32900.exe 문자열에서 드라이버와 관련된 문자열이 존재하기도 하므로 driverscan을 통해 확인을 해보자. 그 결과 tmryqyrznr2.sys가 보이는 것을 확인할 수가 있다. 좀 더 상세히 확인하기 위하여 driverirp를 통해 확인한 결과는 아래와 같다.

Figure 19. Volatility – driverirp

출력된 결과를 보면 모든 부분이 0x00000000로 되어 있는 것을 확인할 수가 있다. 이는 해당 모듈이 메모리에 남아있지 않기에 사라진 것으로 보인다.

  3. 결론

위의 분석 작업을 통한 결과를 전체적으로 종합해보자. 우선 tigger.exe를 실행하고 MFT를 통해 근처 시간대를 확인한 결과 tigger.exe외에 329000.exe와 tmryqyrznr2.sys도 조사범위에 넣었고 분석 결과 329000.exe는 virustotal에서 본 것과 같이 악성코드라 판단할 수가 있다.

329000.exe는 어떠한 파일과 관련된 동작, 드라이버와 지속성을 위한 레지스트리 등과 관련된 함수와 문자열들을 포함하고 있다. tmryqyrznr2.sys는 메모리에 더 이상 존재하지 않기 때문에 추가적인 분석을 진행할 수가 없었다.

하지만 tmryqyrznr2이란 문자열을 yarascan을 통해 확인한 결과 svchost.exe(pid=936)에 해당 문자열이 존재함을 알 수가 있었고, 이를 토대로 해당 svchost.exe와 관련된 파일들을 dumpfiles를 통해 추출하였다. 그리고 몇 개의 파일에서 hookimports와 같은 후킹과 관련된 직접적인 문자열을 확인할 수가 있었다. 또한 Firewall과 관련된 문자열이나 함수 등을 통해 해당 프로세스가 방화벽과의 연관성을 가지는 것도 알 수가 있었다.

prefetch_parser.exe

1. 개요

1.1 동기

Prefetch 분석 도구를 제작하고자 현재 프리패치와 관련된 툴로 WinPrefetchView를 사용하고 있지만 불편한 점을 느꼈다. 실행 시 프리패치 파일에 대하여 상세히 분석을 해주지만 현재 실행시킨 시스템에서의 파일만 분석을 한다는 것이다.

Figure 1. WinPrefetchView

그렇기에 다른 PC의 프리패치 파일을 분석하기 위해선 그 해당 PC에서 실행을 하거나 해야한다. 하지만 모든 상황에서 실행이 가능한 것은 아니기 때문에 최대한 흔적을 적게 남기는 것을 목표로 하고자 한번 만들게 되었다.

1.2 구상

우선 어떻게 만들지 구상을 해보았다. 여러 가지 고려 해야 할 사항은 매우 많지만 가장 크게 뽑는 다면 다음과 같다.

• 제작에 사용할 프로그래밍 언어 - Python
• 윈도우 버전 – Win10의 경우 압축이 되어있음
• GUI vs CLI – 흔적을 최소화 하기 위하여 CLI

이와 같이 3가지 사항에 대하여 크게 고민을 하였다. 프로그래밍 언어의 경우 다룰 수 있는 것이 파이썬 밖에 없었기에 결정하는데 큰 고민이 없었지만 윈도우 버전의 경우 압축 해제 과정이 들어가야 하기에 어느 버전으로 할 것 인지 고민했다.

하지만 WinPrefetchView에서는 두 가지 모두 지원을 하고 있었다. 그러므로 하나로 통합은 힘들 테니 각 버전에 맞는 2개를 만들어보자 라는 생각을 하게 되었다.

GUI의 경우 사용에 있어 편의성을 향상 시키겠지만, 우선 내가 아직 GUI를 한번도 만들어보지 않았다는 점이 크게 작용하여 결국 CLI로 택하였다.

1.3 전체적인 흐름

어떻게 프로그래밍을 해야 할까 고민을 해보았다. 어떻게 동작을 해야 하나 고민을 하고 다음과 같이 생각하였다.

1. 우선 파일을 읽어야 한다. f=open('.pf','rb'). 그렇다면 이 파일은 어떻게 지정할 것인가?
2. sys라이브러리를 통해 인자로 받는 것이 별 힘이 안 들 것 같음
3. 읽은 파일이 압축 된 것일 경우 압축을 해제 – 압축 해제에는 다른 분의 소스를 사용
4. 해제된 데이터를 읽어 .pf파일의 포맷에 맞게 읽음
5. 이름, 사이즈, 마지막 실행시간, pf파일생성시간, pf파일 수정시간, 런카운트, 실행에 포함되는 파일의 이름들
6. 5의 사항들을 출력

이렇게 전체적인 흐름을 생각하였고 이에 맞추어 코드를 하나하나 타이핑 하였고, 하면서도 많은 부분 분노와 슬픔이 있었다.

2 코드 쓰기

2.1 경로 인자 받기 & 압축 해제

우선 파일의 경로를 인자로 받아야 한다. Sys 모듈을 사용하고 인자로 받은 pf파일이 있는 경로에서 .pf 확장자를 찾아 선별하여야 한다.

Figure 2. 인자받기 & PF확장자 찾기

위의 코드와 같이 첫 번째 줄에서 sys.argv[1]로 인자를 받는다. 그리고 그 해당 경로에서 .pf 확장자를 갖는 file을 찾는 코드이다.

이제 인자로 받은 파일이 XPRESS 압축이 되어 있는 경우 압축을 해제하여야 한다. 이는 francesco.picasso@gmail.com 분의 소스를 가져왔으며 원래는 인자로 2개를 받아 input file과 output file을 지정해주어야 하지만, 이를 수정하여 output을 파일이 아니라 bytearray의 형태로 압축 해제된 데이터를 반환하도록 하였다.

Figure 3. XPRESS 압축해제

2.2 Pf 파일 이름 읽기

이제 윈도우 10의 경우에도 압축이 해제된 데이터를 가질 수가 있다. 그러므로 포맷에 맞게 간단히 데이터를 읽기만 하면 되는 줄 알았다. F.read()의 데이터를 buf라 했을 때 Pf 파일의 이름은 buf[16:49]이다. 그대로 읽기만 하면 되는데 문제가 생겼다. 아래의 그림을 보자.

Figure 4. NULL이 포함된 이름

파일의 이름이 Unicode의 형태처럼 2바이트씩 쓰여 있는 것을 알 수가 있다. 따라서 이를 그냥 출력하면 'M E L O N . E X E'와 같이 출력이 된다. 그냥 써도 별 문제는 없겠지만 나중에 해당 파일의 이름을 복붙하는 과정에 있어 저 공백 부분을 매번 지우기가 귀찮을 것 같아 공백 없이 출력되도록 하였다.

Figure 5. NULL 없애기

함수의 인자로 buf[16:49]와 같이 주면 buf[16]부터 buf[49]까지 하나 하나 읽으며 \x00을 buf배열에서 제거한다. 그리고 \x00이 제거된 부분만 반환을 하는 부분이다.

Figure 6. 출력된 파일 이름

이렇게 성공적으로 이름이 출력되는 것을 위의 그림과 같이 확인할 수가 있다. 이제 뭔가 쉽게 잘 풀리는 것 같아서 좋다.

2.3 파일 사이즈 출력

파일 사이즈도 출력을 해보자. 파일의 사이즈는 아래의 그림과 같이 12:15에 존재하고 있다. 이 부분을 10진수로 읽어 출력을 하면 된다.

Figure 7. 파일 사이즈

16진수를 10진수로 나타내기 위해서는 해당 부분을 읽은 다음에 10진수로 변환하여 출력을 해주어야 한다. 하지만 %d로 출력을 바로 하면 아래와 같은 결과를 볼 수가 있다.

Figure 8. 파일 사이즈 출력 오류

Bytearray형식으로 읽었기 때문에 %d의 형식으로 출력을 할 수가 없다는 것이다. 그렇다면 %s로 출력을 하면 어떨까?

Figure 9. 파일 사이즈 출력 오류

위의 그림과 같이 이상하게 출력되는 것을 확인할 수가 있다. 그렇다면 어떻게 해야 할까 고민을 하던 중 아는 분이 mft와 관련하여 분석하는 Python 코드를 보았는데 리틀엔디언을 십진수로 출력해주는 코드가 있기에 가져왔다.

Figure 10. LittleEndianToInt

이 함수를 통하여 리틀엔디언으로 나타난 부분을 바로 10진수로 출력해주는 것을 확인할 수가 있다. 참 편리한 부분이다.

Figure 11. 파일 사이즈 출력

원하는 바와 같이 204910이 제대로 출력되는 것을 확인할 수가 있다. 이렇게 파일의 이름과 사이즈의 출력에 성공하였다.

2.4 마지막 실행 시간 출력

포렌식 툴인 만큼 가장 중요한 부분은 바로 시간과 관련된 부분이다. 0x80~0x88까지의 부분이 프리패치 파일이 마지막으로 실행된 시간(Last Run Time)이다.

Figure 12. 마지막 실행시간 위치

시간과 관련하여 꽤 시간을 소모하였다. 시간을 출력하는데 datetime 모듈을 사용하였으며 필요한 코드는 아래의 그림과 같다.

Figure 13. 시간 변환 함수

우선 리틀엔디언을 빅엔디언 10진수로 변환해주고 그 다음 time_convert라 써있는 부분의 함수를 호출하여 알맞은 형태로 출력되게 하고자 하였다. 여기서 애를 먹은 부분은 3번째와 5번째라인이다. 우선 5번째 라인의 마지막 timedelta에 hours=9를 해주므로 한국 기준 시간인 UTC 9:00을 맞출 수 있었다. 만약 저 부분을 쓰지 않는다면 한국 시간과 9시간 차이가 나는 값을 얻게 된다.

Figure 14. 시간 출력 오류

3번째 라인의 경우 쓰지 않을 경우 위와 같이 에러가 출력이 되는데, 3번째 라인을 써주므로 문자열의 형태로 만든 다음 원하는 결과를 제대로 나타낼 수 있게 해주므로 나의 코드에서는 반드시 써주어야 했다.

Figure 15. 시간 출력 성공

위의 과정들을 통하여 코드를 완성하였다. 그리고 위와 같이 올바른 값을 출력하도록 할 수 있었다.

2.5 pf파일 생성시간 & 수정시간 출력

생성시간과 수정시간의 경우 실행한 원래의 파일에 대한 것이 아니라 프리패치 파일이 생성된 시간과 수정된 시간에 관하여 출력을 나타낸다.

Figure 16. 생성시간 & 수정시간

이 둘은 datetime 모듈과 os.path의 getctime과 getmtime을 통하여 쉽게 얻을 수가 있었다. 이에 대한 출력 결과는 아래와 같다.

Figure 17. 생성시간 & 수정시간 출력 성공

2.6 실행 횟수 출력

프리패치 파일에는 해당 파일을 몇 번 실행했는지 또한 나타나있다. 이는 pf 파일의 0xD0에서 0xD3까지에 위치해 있다.

Figure 18. Run Count 위치

이 경우도 2.3에서 파일의 사이즈 출력과 비슷한 작업을 거쳐 출력을 해주면 된다. 우선 리틀 엔디언의 형태로 되어있으므로 빅엔디언으로 변환하고 10진수로 출력을 해주면 된다. 여기선 위와 같이 LittleEndianToInt 함수를 사용하였다.

Figure 19. Run Count 출력 성공

2.7 포함되는 파일 목록

프리패치 파일에는 해당 프로그램이 실행 될 때 로드하는 파일에 대하여 목록을 가지고 있다. 이러한 파일의 목록은 분석을 하는 입장에서도 중요한데, 만약 잘못된 위치에서 의심스러운 파일이 로드 되는 등의 행위는 분석에 있어 시간을 단축할 수 있게 해주는 중요한 단서가 된다.

Figure 20. 파일 목록 & 크기

0x64~0x68까지는 로드되는 파일의 이름이 있는 위치를 나타내며 0x68~0x6C는 파일 목록이 저장된 위치의 크기를 나타내어 준다. 따라서 offset은 0x64~0x68이며 size는 0x68~0x6C이므로 로드된 파일의 목록이 나타나는 마지막 위치는 offset+size이 된다.

Figure 21. 로드된 파일 목록 함수

우선 file list의 offset을 0x64에서 확인을 해주고 size는 0x68에서 확인을 해준다. 그리고 이를 통해 마지막 위치를 알 수가 있으니 해당 부분을 읽으면 된다. 하지만 여기서 아래의 그림을 확인하자.

Figure 22. 유니코드와 NULL 구분

표시한 부분이 바로 로드된 파일의 나누는 기준이 된다. 전체적으로 유니코드로 나타나기에 \x00\x00을 통해 파일을 나누어야 한다. 그렇기에 위의 코드에서 Unicode_split를 추가한 것이다.

이렇게 \x00\x00을 통해 각 파일들을 나눌 수가 있다. 하지만 유니코드의 형태를 그대로 읽었기에 출력을 할 경우 "V O L U M E . . ."처럼 2.2에서 파일의 이름에 공백이 추가되어있듯이 나타난다. 하지만 이번에는 bytearray의 형태가 아니라 문자열의 형태로 파일의 목록을 읽었기 때문에 다른 방식으로 접근해야 했다.

Figure 23. 로드된 파일 목록 공백 제거

"V.O.L.U.M.E …"와 같이 파일 경로를 하나 하나 인자로 remove_uni_null 함수에 주게 되면 임시로 만든 tmp배열에 \x00이 아닌 경우에만 추가된다. 그러므로 \x00은 자연히 떨어져 나가게 되며 이렇게 만들어진 새로운 tmp 배열은 join(tmp)를 통해 일반적인 문자열과 같이 출력되는 결과를 확인할 수가 있다.

Figure 24. 출력 결과

이렇게 전체적인 내용을 모두 완성하였으며 출력 결과 또한 만족스럽다.

3. 후기

일단 원하는 내용의 프로그램은 만들었기에 매우 뿌듯하다. 하지만 다 만들면서 또는 만든 후에 느끼는 점이 매우 많은데 이에 대해 정리하면 다음과 같다.

첫째, 확실히 프로그래밍은 많이 해보아야 하는 것 같다. 전체적인 구성을 하는 것보다는 유니코드에 포함된 NULL을 제거하거나 리틀엔디언을 10진수로 출력하거나 시간을 변환하고자 하는데 해당 형식은 안된다는 등의 오류를 해결하는데 오히려 훨씬 더 많은 시간을 지체하였다. 결국 오랜 시간 끝에 하나하나 해결을 하였기에 이와 유사한 프로그램을 만들 때에는 내가 만든 소스를 보므로 시간을 훨씬 단축할 수 있을 것 같다.

둘째, 원하는 내용을 만들었지만 아쉬운 점이 많이 느껴진다. 예를 들어 CLI의 형태이므로 어떠한 컬럼을 기준으로 정렬을 할 수 없다는 점이 가장 크다. 내가 만든 프로그램의 경우 지정된 폴더에 이름 순서에 따라 나타나는 정도이기에 다소 불편함이 있기는 하다.

셋째, 전체적으로 코드에 대한 이해가 부족한 느낌이 크다. 왜 굳이 bytearray를 사용했는지, 왜 bytearray는 변환이 되고 str은 안되는지 등에 대하여 자세한 이유를 모른다는 점에서 부족함을 많이 느꼈다.

넷째, 부족한 프로그램이지만 내가 만든 프로그램은 내가 애정을 가져야 하는 것 같다. 다른 사람이 더 잘 만들 수 있지만, 만들면서 많은 고민을 했다는 것 자체만으로도 큰 도움이 되는 것 같다.

참고

http://www.forensicswiki.org/wiki/Windows_Prefetch_File_Format   프리패치 파일 포맷

http://devanix.tistory.com/306  datetime 모듈

http://tt-share.blogspot.kr/2015/05/python_35.html    파일 mac 시간 구하기

https://gist.github.com/dfirfpi/113ff71274a97b489dfd#file-w10pfdecomp-py   XPRESS 압축 해제

https://gist.github.com/craSH/393155/19cb41b9f536593cb16a978af8ebeb00ffae500f 프리패치 해시 값

http://www.forensicfocus.com/Forums/viewtopic/p=6542386/#6542386

4. 첨부

완성된 코드

압축해제에 참고한 코드

1. 개요

BlackEnergy는 러시아 해커에 의해 제작된 인기 있는 DdoS 공격을 위한 트로이 목마로 2008년 러시아 그루지아 사이버 공격에서 사용된 것으로 보고되어 악명을 얻었다.

얼마 후 BlackEnergy2가 개발 되었으며, 코드를 재작성하여 기존의 것과는 다르게 루트킷, 프로세스 인젝션, 강한 암호화와 모듈 구조를 가지고 있다. 주로 산업 공정, 기반 시설, 설비 등의 산업 제어 시스템을 대상으로 공격하고 있으며, 현재 원격 코드 실행, 네트워크 탐색, 데이터 수집 등의 기능을 수행하는 다양한 변종이 발생하고 있다.

  2. 분석

해당 이미지를 통해 어떠한 의심스러운 프로세스가 있는지를 확인해보자. 우선 pslist는 EPROCESS 구조 에 있는 ActiveProcessLinks를 통하여 어떠한 프로세스가 동작 중인지를 보여준다. 이에 따른 결과는 아래의 그림과 같다.

Figure 1 Rekall – pslist

크게 3가지의 프로세스에 대하여 붉은 선으로 표시하였다. 각 항목을 표시한 이유는 다음과 같다.

• 1e0f—(476) : 프로세스의 이름, 생성시간에서 의심스럽다 할 수 있음
• Cmd.exe(1572) : pid-476의 하위 프로세스라는 점에서 의심
• Explorer.exe(1724) : Explorer.exe의 부모 프로세스인 PID-1708이 존재하지 않음

이제 이를 기준으로 다른 부분을 확인해가며 점차 확인해야 할 범위를 줄여나가보자.

Figure 2 Rekall - Userassist

Userassist는 사용자가 어떠한 프로그램을 실행시켰는지를 확인할 수가 있으며, 위의 결과를 확인해보면 2010-08-15 19:21:25에 1e0f--.exe를 실행하였다는 것을 확인할 수가 있다. 이와 관련된 아티팩트로 MFT 또한 확인해보자.

Figure 3 Volatility - mftparser

여러 MFT 중에서 시간을 기준으로 의심스러운 3가지 항목이 나열되어있다. 우선 lkndcaccmjqb.sys, str.sys, 그리고 1e0f1b--.exe의 prefetch파일을 발견할 수가 있다. Prefetch파일은 해당 프로그램이 실행되었다는 것을 알려주는 것이며, 그 외에 두 개의 sys가 추가로 의심된다고 볼 수 있다.

Figure 4 Rekall – modscan

하지만 위의 모듈들을 확인하기 위하여 modscan을 통해 확인해본 결과 보이지가 않았다. 일단 이에 대해서는 아직 확인할 방법이 없으므로 다른 쪽에 기준을 맞추어 분석을 다시 진행해보자.

Figure 5 Rekall – Procdump

현재 프로세스 목록 중 가장 의심스러웠던 1e0f—에 대하여 분석을 해보기 위하여 추출하고자 하였다. 이에 쓰인 플러그인은 Rekall의 procdump로 해당하는 pid를 지정해주면 손쉽게 해당 프로세스를 추출할 수가 있다.

Figure 6 HxD – 1e0f1b--.exe

HxD로 열어서 확인을 해본 결과 해당 프로세스는 이미 종료되었기 때문에 해당하는 핸들 등이 메모리에서 해제된 상태이다. 따라서 모든 부분이 NULL로 채워져 있는 것을 확인할 수가 있다. 따라서 다른 부분에 초점을 맞추어야 할 것 같다.

Figure 7 Volatility – callbacks

Callback Plugin을 통해 확인한 결과는 위의 그림과 같다. 여기서 module 항목에 다른 것들과는 다르게 존재하는 항목을 볼 수가 있다. 바로 00004A2A이다. 결과를 보면 CreateThread에 4A2A모듈이 동작하고 있는 것을 통해, 스레드의 생성과 관련이 있음을 알 수가 있다.

Figure 8 Volatility – SSDT

추가로 SSDT (System Service Descriptor Table)는 커널 모드 함수에 대한 포인터를 포함하고 있다. 그러므로 악성코드는 이러한 SSDT 후킹을 할 수가 있으므로 확인해주어야 한다. 확인 결과는 위의 그림과 같으며 모듈 00004A2A가 많은 부분에서 SSDT에 적용되어 있는 것을 확인할 수가 있다.

Figure 9 Rekall – modscan

4A2A 모듈을 추출하기 위하여 해당하는 주소를 찾아보자. Modscan 플러그인을 통하여 4A2A의 베이스 주소를 확인할 수가 있다. 확인 결과 베이스 주소는 0xff0d1000이다. 이 주소를 가지고 모듈을 추출해보자.

Figure 10 Volatility – moddump

Moddump 플러그인을 통하여 위에서 확인했던 베이스 주소를 기반으로 모듈을 추출할 수가 있다. 위의 결과와 같이 성공했다는 문구를 확인할 수가 있지만, 어떠한 이유에서인지는 모르겠지만 추출된 해당파일이 나타나지 않았다. 따라서 추가적인 확인을 할 수가 없었다.

위에서 확인했던 바와 같이 4A2A 모듈은 스레드가 시작되거나 종료될 때 트리거 되는 것을 확인할 수가 있었다. 또한 SSDT가 후킹되었다는 것을 확인할 수 있으므로 threads에서 확인해보자. 결과는 아래의 그림과 같다.

Figure 11 Volatility – threads – HookedSSDT

그림에서와 같이 생성된 스레드들이 4A2A와 관련이 있음을 알 수가 있으며 각 스레드의 서비스 테이블이 4A2A모듈을 가리키고 있다. 그림 8에서 보았던 API 함수들과 같은 함수임을 알 수가 있다.

Figure 12 Rekall – Malfind

Malfind 플러그인을 통해 코드 인젝션이 되었는지를 확인할 수가 있다. 여기서는 독특하게 svchost.exe에 실행파일의 MZ헤더가 존재하는 것을 확인할 수가 있다. 따라서 이를 추출하여 확인하도록 해보자.

Figure 13 Volatility – dlldump

Dlldump를 통해 pid와 base address를 입력해주고 dump-dir을 통해 저장할 경로를 지정해주면 된다. 결과는 성공적으로 추출이 완료되었으며 이에 대해 분석해보자.

Figure 14 module.c30000.dll – string

문자열 추출 결과는 다음과 같다. 여기서 몇 가지 살펴보아야 할 것에 표시를 하였는데 우선 cmd.exe를 이용한다는 것과 그림 3(MFT parser)에서와 같이 str.sys가 존재하는 것을 확인할 수가 있다. 아래 바이러스 토탈의 결과를 보자.

Figure 15 Virustotal – module.c30000.dll

추출한 모듈을 바이러스 토탈에 확인해 본 결과 악성코드임에 많은 의심을 받는다. 존재하는 함수 중 DownloadFile부터 시작해 많은 부분 악의적인 기능을 하기에 충분한 요소가 있다.

Figure 16 svchost.exe(856) – handles

어떠한 핸들을 가지고 있는지 확인하기 위하여 handles 플러그인을 통해 File과 Mutant를 출력하였다. 우선 File에서 str.sys과 각 index.dat에 대한 핸들을 가지는 것을 확인할 수가 있다. 또한 Mutant를 통해 Encrypt 등을 확인할 수가 있다. 개인정보를 원격으로 추출할 수 있으므로 추가로 확인해보자.

Figure 17 Rekall – threads

Svchost.exe(856)의 Threads를 확인해보자. Rpcrt4와 관련하여 스레드가 존재하는 것을 확인할 수가 있다. RPC(Remote Procedure Call)는 별도의 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게 하는 프로세스 간 통신 기술이다. 다시 말해, 원격 프로시저 호출을 이용하면 프로그래머는 함수가 실행 프로그램에 로컬 위치에 있든 원격 위치에 있든 동일한 코드를 이용할 수 있다.

Index.dat는 IE 등을 통해 핸들에 들어가는 것이 정상이며 해당 프로세스가 이를 핸들로 가지고 있다는 점과, RPC가 있다는 점에서 충분히 악의적인 행위를 할 수가 있음을 의심할 수가 있다.

+ 수정 : index.dat과 rpc 관련 스레드를 가지는 svchost.exe가 악의적이다고만은 할 수가 없다. 정상적인 svchost.exe가 가질 수도 있음

Figure 18 Volatility – driverirp

Driverirp 플러그인은 IRP Table을 보기 위해 사용하는 명령어이며, 모듈을 이용한 Hooking된 IRP 함수 탐지하지만 항상 옳은 방법은 아니기에 –verbose 를 통해 구체적으로 확인을 해보자. 결과는 아래의 그림과 같다.

Figure 19 Volatility – driverirp –v

PUSH 명령어를 통해 인자를 주고 CALL 명령어를 통해 어떠한 기능의 주소를 호출하는 것을 확인할 수가 있다. 해당 인자 값은 0xffffffff이며 호출하는 함수의 명령어는 아래와 같다.

Figure 20 Volatility – Volshell

Volshell을 통해 디스어셈블 한 결과이다. 함수의 호출과 함께 어떠한 값을 스택에 Push하는 것을 확인할 수가 있고, 그 값은 0x46C825FF(우측)이다.

구체적으로 어떠한 기능을 하는지는 확인하지 못하였지만 icqogwp드라이버와 관련하여 해당 악성코드가 어떠한 기능을 하고 있다는 것을 알 수가 있다.

  3. 요약

지금까지 BlackEnergy2를 메모리 분석을 통해 분석해보았다. 전체적으로 확실한 기능에 대해서는 발견하지 못했지만 해당 메모리 덤프를 통해 알게 된 정보에 대하여 요약하고자 한다.

• 2010-08-15 19:21:25에 1e0fb1--.exe를 실행
• CallBack(스레드 관련)과 SSDT(그림8참고)에 대하여 4A2A 모듈이 후킹
• 악의적인 dll의 컨테이너 역할로 svchost.exe(856)이 동작
• 해당 DLL은 DownloadFile이나 cmd와 관련된 문자열이 존재
• Svchost.exe(856)이index.dat이나 RPC에 대하여 핸들과 스레드를 가짐
• 4A2A모듈이 icqogwp드라이버와 관련하여 어떠한 동작을 함

비록 실행했던 프로그램 1e0--.exe는 메모리에서 내려갔지만, 메모리에 남아 있는 다른 흔적들을 통하여 해당 악성코드의 기능에 대하여 유추할 수 있었다. 그림14와 같이 어떠한 API가 사용되었는지, 핸들이나 뮤턴트, 스레드, 드라이버 등을 살펴보므로 이에 대하여 확인할 수가 있었다.만약 본래의 프로세스가 메모리에 남아있었다면 추출하여 더욱 상세히 분석을 할 수 있었을 것이다.

참고

https://ko.wikipedia.org/wiki/원격_프로시저_호출

http://blog.naver.com/chogar/220226730293

from datetime import datetime,timedelta
dt = '01cb17701e9c885a'
us = int(dt,16) / 10.
print datetime(1601,1,1) + timedelta(microseconds=us)

Output

2010-06-29 09:47:42.754212

1. 개요

 Coreflood는 미국에서 발생한 해킹사건에 쓰인 악성코드로 키보드의 동작을 기록하여 PC 사용자의 웹사이트 로그인이나 ID, 암호, 개인의 금융정보까지 빼낼 수 있는 프로그램이다.

 러시아 해커 그룹에 의해 만들어졌으며 2010년에 출시된 트로이 목마 및 Botnet으로 많은 금융기관과 대학, 그리고 병원과 정부 등도 감염되는 등의 막대한 피해를 입힌 악성코드이다.

 해당 문서에서는 Rekall과 Volatility를 통하여 Coreflood에 감염된 PC의 메모리를 통해 분석을 진행할 것이며 분석 대상 환경은 Windows XP SP2 x86이다.

2.분석

 해당 메모리를 Rekall을 통해 이미지를 열고 어떤 프로세스가 동작 중인지를 확인하며 이를 통해 이름이나 생성 및 종료 시간이 수상한 프로세스가 있는지를 확인해볼 것이다. 여기에는 은닉된 프로세스가 있을 수 있으므로 pslist가 아닌 psscan을 사용하였다.

그림 1. Rekall – psscan

 그림 1과 같이 몇 개의 의심되는 프로세스를 표시해보았다. 우선 실행된 시간이 2010-08-15인 프로세스에 초점을 맞추어 위 2개의 프로세스가 해당이 되며 cmd.exe의 경우 Vmware에 의한 것으로 해당 분석과는 상관이 없는 내용이므로 포함하지 않았다.

 현재 어떤 프로세스가 동작 중이었는지에 대해 확인을 했으므로 이제 사용자가 어떠한 프로그램을 실행시킨 것인지 확인을 해야 한다. 이에 대해서는 사용자가 응용프로그램을 실행시켰을 경우 레지스트리에 기록되는 UserAssist에 대하여 아래의 그림을 통해 확인을 해보자.

그림 2. Rekall – userassist

 Userassist엔 2010-08-15 18:10:58에 flashload.exe를 실행했다는 것을 확인할 수가 있으며, 그 다음엔 iexplore.exe가 실행되었다는 것을 확인할 수가 있다. 그림 1과 같이 실행 중인 프로세스에선 해당 이름을 확인할 수가 없으므로 해당 프로그램에 대하여 찾아보자.

그림 3. Volatility – MFTparser – logon.scr.pf

 이전에 의심스러웠던 logon.scr이 flashload.exe가 실행된 후 10분 가량 후에 실행되었다는 것을 확인할 수가 있다. 따라서 해당 프로세스가 아직 악의적인 프로세스인지 아닌지에 대하여 단정 짓기는 힘들다. 그렇다면 다른 방법으로 접근해보자..

그림 4. Rekall – messagehooks

 Messagehooks Plugin은 모든 데스크탑을 검색하여 글로벌 후킹을 열거한다. 결과를 보면 IEXPLORE.EXE가 4개의 전역 후킹 결과를 나타내는 것을 보이며 키보드와 마우스 모두 후킹되고 있는 것을 확인할 수가 있다.

그림 5 Volatility - ssdt

 SSDT는 System Service Descriptor Table로 커널 모드 함수에 대한 포인터를 포함한다. 그러므로 악성코드는 이러한 SSDT 후킹이 의심되므로 확인을 해주어야 하며 위 결과와 같이 0x805aa8b4는 사실 ntoskrnl.exe에 소유되지만 주소의 명령은 0x806d56c0(hal.dll)으로 나타내는 것을 확인할 수 있다.

그림 6. Volatility - callbacks

 SSDT에 이어 Callback을 확인해보면 이전에 보았던 hal.dll이 존재하는 것을 확인할 수가 있다. 해당 dll은 버그 체크를 할 때 Callback되는 것을 확인할 수가 있다.

그림 7.Rekall - modscan

 해당 모듈을 찾기 위하여 modscan을 사용하였다. 결과는 위의 그림과 같으며 해당 주소에 MZ시그니처를 확인 후 덤프로 추출해낼 것이다.

그림 8. Volatility – volshell    

 Volshell의 db를 통해 해당 주소의 MZ 시그니처가 있는지 확인을 해본 결과 위의 그림과 같이 올바른 위치에 MZ 가 위치해 있는 것을 확인할 수가 있다. 따라서 아래와 같이 해당 모듈을 추출해 보자.

그림 9. Volatility – moddump

 추출한 hal.dll의 악성코드 여부를 판단하기 위하여 Virustotal을 이용하였다. 결과는 아래와 같으며 55개의 엔진에서 악성코드라 판단되는 것이 0이라는 것을 알 수가 있다. 따라서 추출한 hal.dll을 악성코드라 보기가 힘들다.

그림 10. VirusTotal – Extracted hal.dll

 이에 추가로 확인하기 위하여 같은 운영체제(Windows XP x86)에서의 정상적인 hal.dll과 문자열을 통해 비교해보았다. BinText를 통해 각 문자열을 추출하였으며 추출한 문자열들을 WinMerge를 통하여 비교하였다. 결과는 아래의 그림과 같다.

그림 11. WinMerge – Compare String

 위에 나타난 부분만이 메모리에서 추출한 hal.dll에 추가로 있는 부분이다. 그 외에 원본에는 있지만 추출한 dll에는 존재하지 않는 부분은 메모리에서 추출했다는 점을 감안하여 나타내지 않았다. 추출한 파일에 추가로 붙는 정보가 적으므로 악성코드라 판단하기 힘들다는 것을 알 수 있었다.

그림 12. Volatility – malfind

 해당 플러그인은 Code Injection을 검출해주는 기능을 한다. 위의 그림과 같이 의심되는 IEXPLORE.EXE에서도 해당 되는 지점이 나타났지만 값이 0으로 채워져 있는 것을 확인할 수가 있다. 이는 해당 지점을 읽을 수 없으므로 읽을 수 있는 지점이 나올 때까지 이동하며 보아야 한다.

그림 13. Volatility – volshell

 해당 주소 0x7ff80000에서부터 100씩 읽으며 읽혀지는 곳이 나올 때까지 확인해보았다. 그 결과 0x7ff81000에서 데이터를 읽을 수 있다는 것을 확인하였다. 이제 이 지점을 디스어셈블하여 출력해보자.

그림 14. Volatility – volshell

 해당 지점을 확인해보니 쉘코드가 존재하는 것을 확인할 수가 있다. 페이지의 권한이 실행, 읽기, 쓰기라는 점과 함께 malfind플러그인을 통해 확인할 수가 있다. 이번엔 api후킹의 여부를 확인해보자.

그림 15. Volatility – apihooks

 Apihooks 플러그인을 통해 확인을 해본 결과 IEXPLORE.EXE에 여러 개가 검출 되었다. 후킹된 대부분의 함수들 모두 0x7ff81960을 호출하는 부분으로 이어지는 것을 확인할 수가 있었다. 그림 4에서의 주소(0x7ff81b40)와 유사함을 알 수가 있고, 이에 대하여 volshell을 통해 확인해보자.

그림 16. Volatility – volshell

 디스어셈블을 통해 확인한 결과는 위의 그림과 같다. 이러한 dll을 덤프로 추출하고자 할 때 dlldump는 메모리에서의 변화를 포함하고 있으며 dumpfiles는 디스크 상에서의 코드와 일치한다. 그러므로 두 방법을 통해 추출하고 바이너리를 비교해보자.

그림 17. Volatility – dlldump

 Dlldump를 통해 추출하는 방법은 위의 그림과 같다. 추출에 성공하였고 해당 이름이 module.2044.485d1a8.771b0000인 것을 확인할 수가 있다.

그림 18. Volatility – dumpfiles

 Dumpfiles를 통해 추출한 결과는 위의 그림과 같다. 추출한 파일 이름은 file.2044.0x80f04f30으로 나타난다. 이제 이 두 개의 파일을 비교하여보자.

그림 19. Compare Bytes

 위의 두 그림에서와 같이 좌측은 Dlldump, 우측은 Dumpfiles를 통해 추출한 파일이다. 즉 좌측은 메모리에서의 코드 변경이 반영되었고, 우측은 반영되지 않았다는 것이며 그림에서와 같이 디스크 상에서의 파일에는 존재하지 않는 코드가 존재한다. 이외에도 몇 가지 더 있지만 생략하겠다.

그림 20. Volatility – envars

 환경변수를 확인해보면 부모 프로세스가 자식 프로세스에게 해당 환경 변수를 상속하는 것이 일반적이다. 붉게 표시한 부분을 보면 부모에게는 없지만 자식(iexplore.exe)에는 존재하는 것을 확인할 수가 있다. 정상적인 프로세스에는 없다는 것을 생각했을 때 해당 환경변수 또한 악성코드에 의해 남은 흔적임을 의심해볼 수 있다.

  3.정리

 2장의 분석 과정을 통하여 CoreFlood가 실행된 메모리를 분석해보았다. 대체로 더 상세한 분석을 하기에는 필자의 실력이 아직 미흡하기에 버겁다. 지금까지 분석한 내용을 정리하면 아래와 같다.

• Flashload.exe가 2010-08-15 18:11:13를 실행
• IEXPLORE.EXE가 키보드와 마우스의 전역 후킹을 함
• API후킹과 Code Injection으로 보이는 흔적 발견
• 전체적으로 악의적인 코드는 0x7FF81000 이후에 분포
• 환경변수에 흔적이 남는 것으로 예상

참고자료

The Art of Memory Forensics (Detecting Malware and Threats in Windows, Linux, and MAC Memory)

Ligh, Michael Hale, Case, Andrew, Levy, Jamie 외 1명 저  JohnWiley&SonsInc  2014.07.14.

https://en.wikipedia.org/wiki/Coreflood

https://code.google.com/p/volatility/

http://www.rekall-forensic.com/

1. 개요

 악성코드에 대해 공부를 할 때는 몰랐지만, 직접 여러 악성코드를 분석해보니 네트워크와 연결을 진행하는 악성코드가 정말 많다는 것을 알게 되었습니다. 그렇기에 네트워크와 관련해서 정말 지식이 부족하다고 느껴지기에 계속 미루는 것보단 한번 직접 네트워크에 대해 간간히 공부해보자는 생각에서부터 이렇게 시작하게 되었습니다.

 이번 문서에서는 네트워크에 대한 저의 첫 문서인 만큼 너무 깊이는 들어가지고 않고 향후에 악성코드를 분석하는데 있어 저번과 같은 지장이 있지 않을 정도로 학습을 하려고 합니다. 따라서 이번에는 간단하게 WireShark에 대하여 기초적인 학습을 진행하였습니다. 

1.1 WireShark란?

보안 공부를 시작한지 얼마 안된 사람들도WireShark나 Nmap에 대해서는 자주 들을 수가 있을 것입니다. WireShark는 세계에서 가장 널리 쓰이는네트워크 프로토콜 분석기로 아래와 같은 장점이 있습니다.

그림 1. WireShark

• 오픈 소스라 무료로 사용이 가능
• Packet Capture를 위한 pcap 네트워크 라이브러리 제공
• Tcpdump와 유사하나 GUI를 통해 편리한 인터페이스 제공
• 다양한 필터링 기능 제공

1.2 네트워크 개념

아래의 그림은 OSI 7 Layer에서 각 레이어별 기능과 통신 프로토콜에 대해 간단히 정리되어 있는 것이다.

그림 2. 각 레이어별 기능과 프로토콜

아래의 그림은 TCP를 이요한 3-Way Handshaking으로 이후에 나오는 내용이기에 참고할 겸 첨부하였다.

그림 3. 3-Way HandShake

2.패킷 캡처

 우선 실행 후 화면은 아래의 그림-3와 같다. Start라는 버튼 아래 현재 환경에서 갖는 네트워크 장치에 대해 목록이 있으며, 이 중에 하나를 선택 후 'Start'를 누르면 캡처가 시작된다.

그림 4. WireShark 실행 화면

  이렇게 패킷 캡처를 시작하면 네트워크 장치를 지나는 패킷들이 나열되며 본인의 PC 환경에 따라 상이하지만 대부분 정말 많은 패킷의 교환을 확인할 수가 있다.

2.1 패킷 캡쳐

이제 실제 악성코드가 행위에 사용했던 네트워크 패킷을 한번 확인해보자. 해당 악성코드는 저번 주 분석에 실패를 하였던 Nethost.exe에 초점을 맞추었다.

그림 5. Packet Capture 화면

위에서 Start를 통해 악성코드를 실행하기 전에 캡처한다. 그 후 악성코드가 실행되는 동안의 패킷들이 와이어샤크가 기록을 하며 악성코드의 종료와 함께 캡처를 중지하였고 총 2182개의 패킷이 캡처되었으며, 매우 많은 양임을 알 수가 있다. 따라서 아래와 같은 필터링 기능을 통해 범위를 줄여보자.

2.2 실습 – GET /chrome_extension.exe

아래와 같은 필터 옵션을 적용하므로 이전보다 가독성이 좋아지는 것을 확인할 수가 있다. 해당 패킷을 보면 그림-3에서와 같이 3 way handshake를 통해 연결이 진행되는 것을 확인할 수가 있다.

그림 6. TCP 연결

위의 연결이 해제된 후 재연결이 되면 HTTP로 해당 아이피에 /chrome_extension.exe를 요청하는 것을 확인할 수가 있다.

그림 7. TCP 연결 & extension.exe요청

 이렇게 요청을 한 후 아래의 그림과 같이 1514의 길이만큼 지속적으로 패킷을 받는 것을 확인할 수가 있다. 여기서의 패킷은 디버거를 통해 확인해본 결과 extension.exe에 기록될 명령어들의 내용이다. 아래의 그림과 같이 확인할 수가 있다.

그림 8. GET - Extension.exe

2.3 실습 – GET /chrome_start_page.exe

 Nethost.exe는 이러한 동작을 한번 더 반복하는데 이번에는 extension.exe가 아니라 start_page.exe로 데이터를 요청하는 것을 확인할 수가 있다. 아래의 그림과 같다.

그림 9. GET – Start_Page.exe

 이와 같이 IP주소 193.238.153.91과의 통신은 각 파일에 기록될 데이터들을 주고 받고 종료가 된다. 따라서 다른 IP와 연결되는 패킷도 확인을 해보자.

2.4 실습 – 이 외 패킷

 위의 작업이 끝난 후 다른 패킷들을 살펴 본 결과 아래의 패킷을 확인할 수 있다. HTTP로 185.20.186.44에 패킷을 보내는 것으로 마지막에 Fail이라는 단어를 같이 보내는 것으로 보아 악성코드의 어떠한 기능이 실패했다는 것을 추측해볼 수가 있다.

그림 10. Fail을 보내는 패킷

 하지만 이것만 가지고는 불분명했지만 뒤에 캡처된 패킷의 경우 종료를 알리는 것을 확인할 수가 있었고, 이외의 기능이 없이 이와 관련된 연결이 모두 종료되는 것을 확인할 수가 있었다.

그림 11. Fail이후의 패킷

  3. 결론

 지난 주에 nethost.exe를 분석하며 해당 악성코드가 웹 브라우저의 정보를 가지고 오는 것임을 추후에 확인할 수가 있었는데, 이러한 기능을 하지 않고 종료되는 것을 확인할 수가 있었다.

 이에 대해 몇 가지 결론을 생각해본다면 해당 서버에 연결을 시도하고 RST와 ACK 패킷이 돌아오는 것으로 보아, 해당 서버가 현재는 막혔을 것이라 예상을 해볼 수가 있다.

 이러한 네트워크 분석을 병행하므로 확실히 해당 악성코드에 대한 이해도가 높아지는 것을 체감할 수가 있었고, 이론만 공부하다가 악성코드를 직접 분석해보며 항상 느끼는 것이지만 무엇이 부족한지 매번 알게 된다는 점이다. 따라서 이후에 네트워크에 대하여 한계를 느끼면 다시 해당 문서를 작성하고자 합니다.

참고

필터링 옵션과 관련하여 참고

https://wiki.wireshark.org/CaptureFilters

https://wiki.wireshark.org/DisplayFilters

전체적인 내용

    http://asec.ahnlab.com/156

    http://openness.tistory.com/entry/Wireshark-%EC%82%AC%EC%9A%A9%EB%B2%95

  개요

해당 악성코드 파일(nethost.exe)에 대한 기본적인 파일 정보는 아래의 표-1과 같다. 

이를 통해 해당 악성코드는 러시아어로 작성된 것과 버전에 따라 유포자 및 제작자에 의해 업데이트가 될 수 있다는 것을 확인할 수가 있다.

  정적 분석

정적 분석에서는 PE구조를 확인하고, 이를 통해 패킹의 여부를 확인하며 그 외에 PE구조의 특이사항을 확인할 것이다. 이러한 PE 구조의 특이사항이란 IAT나 문자열 등을 포함하며 이를 통해 프로세스의 대략적인 기능에 대하여 추측해볼 것입니다.

PE구조 분석

PE구조를 확인해본 결과 별도의 패킹이 되지 않은 것을 확인할 수가 있었으며, TLS 영역도 존재하지 않음을 확인할 수가 있다. 아래의 그림은 DIE를 통해 해당 프로그램을 분석한 결과이다..

그림 1. PE구조 분석

그림에서와 같이 해당 악성코드는 C/C++로 작성된 것을 확인할 수가 있다.

문자열 분석

해당 악성코드에는 다양한 문자열들이 존재하는데 네트워킹과 관련된 문자열이 많음을 확인할 수가 있습니다. 몇 가지 선별한 문자열은 아래와 같다. 

이러한 문자열들을 통하여 인터넷 브라우저를 통하여 네트워킹을 진행하며 이외에도 ping 명령어, 그리고 레지스트리 키, FTP 등을 확인할 수가 있다. 따라서 웹브라우저의 연결을 통하여 특정한 사이트와 연결을 하거나, 다른 어떠한 작업을 진행하기 위하여 ping 명령어를 사용하는 것이라 예상해 볼 수가 있다.

Import Address Table 분석

어떤 함수들이 사용되고 있는지 IAT에 나타나있는 항목을 Dependency Walker를 통해 확인해 보았으며, 이 중에서 악성코드의 기능으로 의심되는 몇 가지 항목은 아래의 표와 같습니다. 

이를 통해 보았을 때 WS2_32.dll에서 네트워킹과 관련된 API들이 많이 사용되는 것을 알 수가 있다. 또한 CRYPT32.dll과 ADVAPI32.dll을 통해 암호화와 레지스트리 값 설정을 하는 함수가 존재하며 KERNEL32.dll을 특정한 파일과 기능하는 함수들이 있고 SHELL32.dll을 통해 특정한 명령어를 실행할 것이라 예상할 수가 있다.

동적 분석

동적 분석에서는 정적 분석을 토대로 예상되는 기능들을 직접 안전한 환경에서 실행하므로 일어나는 변화들을 관찰하여 이에 대하여 알아볼 것입니다. 여기선 Process Explorer를 통하여 프로세스의 변화를 관찰하고 TCP Viewer를 통하여 네트워크를 관찰하고 마지막으로 MFT를 분석할 것입니다.

          프로세스 분석

해당 프로세스를 실행시키고 ProcessExplorer을 통하여 아래와 같이 extension.exe가 실행이 추가적으로 실행이 되며, 이후 startpm.exe도 실행이 되는 것을 알 수가 있다.

그림 2. 프로세스 진행과정(1)

이렇게 3개의 프로세스가 실행되고 startpm.exe가 종료되기 전에 하위 프로세스로 CMD를 통하여 Ping 명령어를 사용하는 것을 확인할 수가 있었다.

그림 3. 프로세스 진행과정(2)

이러한 결과를 토대로 이후4장 상세 분석을 함에 참고를 하면 도움이 될 것이다.

네트워크 분석

해당 악성코드가 네트워킹을 하는 과정에 대하여 어느 곳과 연결이 네트워킹을 하는지 알아보기 위하여 TCP Viewer를 통하여 확인해보았다.

그림 4. TCP/UDP 연결 확인

위의 그림에서와 같이 악성코드가 실행된 후 이전에는 없던 System Process(PID:0)이 생기는 확인할 수가 있다. 이렇게 사용되는 프로세스와 원격주소에 대하여 정리한 것은 아래의 표와 같다.

이와 같이 총 9개의 주소 혹은 IP와 네트워킹을 하는 것을 확인할 수가 있으며, 프로세스가 종료된 후에는 이러한 네트워킹도 모두 종료가 되는 것을 확인할 수가 있었다.

MFT 분석

악성코드가 동작한 시간 이후로 MFT에 나타난 변화를 통하여 어떠한 파일이나 디렉터리가 생성되었는지를 확인해 보았으며 아래의 표와 같이 정리할 수가 있습니다. 

위의 표와 같이 SystemDir이라는 디렉터리를 생성 후 Temp나 그 곳에 부차적인 파일들을 생성하여 실행을 진행하고 실행이 완료된 후에는 삭제하는 것을 확인할 수가 있었다.

그 후 IE와 관련된 흔적들을 지우는 것을 확인할 수 있었으며 이를 통해 웹을 통한 행위에 대해 유심히 살펴보아야 함을 알 수가 있다.

상세 분석

상세 분석에서는 해당 악성코드에 대하여 상세한 분석이 진행되며, 필요하다면 부차적인 파일들도 상세 분석을 진행할 것이다.

Nethost.exe분석

우선 MFT에서 분석한 바와 같이 Nethost는 %AppData%\Local\SystemDir을 생성하는 것을 확인할 수가 있었다. 이후에 extension.exe와 startpm.exe는 동시에 생성되는 것이 아니라 같은 방식으로 extension.exe이 먼저 생성되기에 이에 맞추어 startpm.exe의 생성과정은 생략하였다.

그림 5. SystemDir 생성

이렇게 생성된 디렉터리와 %AppData\Local\%Temp 디렉터리를 통하여 악성코드가 어떠한 행위를 하는 것을 알 수가 있었다. 이렇게 기능을 한 후 프로세스가 종료된 후 디렉터리 내에 해당하는 내용들을 삭제하는 것 또한 확인할 수가 있었다.

그림 6. 네트워크 연결

네트워킹을 진행하는 것을 확인할 수가 있으며 send와 recv명령어를 사용하는 것을 확인할 수가 있었으며 동적 분석에서 확인한 바와 같이 여러 IP와 연결하는 것을 확인할 수가 있었다.

그림 7. CreateFile함수 통한 파일 생성

위의 그림과 같이 SystemDir 디렉터리에 extension.exe라는 파일을 생성을 하며, 이후엔 이와 같은 방식으로 startpm.exe를 생성한다. 이렇게 생성된 파일은 아래의 그림과 같이 WriteFile API를 통하여 버퍼가 기록된다.

그림 8. WriteFile 통한 기록

이렇게 recv를 통해 데이터를 받은 후 WriteFile을 통하여 4096Byte 만큼씩 데이터를 기록하는 것을 확인할 수가 있다. 이때의 IP는 193.238.153.90이다.

그림 9. MoveFile을 통한 파일 이동

872KB까지 기록이 된 후 MoveFile 함수를 통하여 기록되던 파일(SystemDir\)이 Temp디렉터리에 exe.tmp로 이동 되는 것을 확인할 수가 있다. 이후 아래의 그림과 같이 CopyFile 함수를 통하여 최초에 실행됐던 nethost.exe가 Temp\extension.exe와 Temp\startpm.exe로 복사가 되는 것을 확인할 수가 있다.

그림 10. CopyFile을 통한 파일 복사

이렇게 된 후 .tmp로 옮겨진 파일을 읽어서, CopyFile을 통한 원본과 같은 파일에 쓰는 것을 아래의 그림과 같이 확인할 수가 있다.

그림 11. 복사된 파일에 기록

위의 루프가 끝난 후 아래 그림 같이 CreateProcess를 통하여 각 파일(extension.exe, startpm.exe)를 실행하는데 여기서 이를 실행할 때 아래의 그림과 같이 인자를 주는 것을 확인할 수가 있었다.

그림 12. CreateProcess API 함수

CreateProcess의 CommandLine에 사용되는 각 프로세스의 인자는 아래의 표-6에 정리한 것을 볼 수가 있다. 여기서 이는 모두 한 줄에 해당하는 항목임을 유의하자. 

이렇게 각 프로세스는 생성된 후 아래의 그림과 같이 DeleteFile API를 사용하여 exe.tmp파일을 제거한다.

그림 13. DeleteFile API 함수

이렇게 작업을 수행한 후 해당 nethost.exe는 종료가 되는 것을 알 수가 있다. 이러한 분석을 통해 보았듯이, nethost.exe는 Dropper인 것을 알 수가 있다.

1. 분석 결과 요약

1.1 의뢰 내용 요약

의뢰 내용은 의뢰자(피해자)가 사건 현장에서 잠시 자리를 비우고, 복귀 후 해당 PC에 이상 프로세스(Economices)가 동작 중임을 의뢰자가 인지하였으며 이에 따라 해당 프로세스가 어디서 유입이 되었는지, 어떠한 기능을 하며, 추가적인 2차 피해가 발생할 수 있을 경우 대응 방안에 대하여 조사를 의뢰하였습니다. 자세한 내용은 아래와 같이 2개로 나뉩니다.

- 실행된 프로세스(Economices.exe)의 악성코드 여부

- 2차 피해 발생 가능성 여부와 대응 방안

1.2 해당 PC 악성코드 감염 사항

의뢰자의 PC에 대하여 해당 악성코드와 관련하여 분석 결과를 시간 순으로 나타내면 아래와 같습니다.

그림 1. 악성코드 행위 타임라인

• 피의자는 피해자가 자리를 비운 사이 2015-11-12 19:39:30에 피해자의 PC에 자신의 USB로 연결을 하였습니다.

• 연결 후 'eco'라는 폴더를 생성하였으며, 해당 디렉터리에 Economices.exe를 저장하고 실행하였으며, 이는 피해자의 키 이벤트 내용을 피의자의 PC로 전송하는 개인정보 침해를 유발하는 프로그램입니다..

• 실행 후 피의자는 피해자의 PC 레지스트리에 등록을 하여 지속적으로 피해자의 정보를 얻으려 하였다는 것을 알 수 있습니다.

• 이후 피의자는 2015-11-12 19:41:57에 USB 연결을 해제하였습니다.

  2.증거 수집 및 분석 도구

증거 수집과 분석에 사용된 도구들의 이름과 버전, 그리고 각각 사용된 용도에 따라 정리를 한 페이지입니다.

2.1증거 수집 도구

증거 수집에 사용된 도구들에 대하여 정리하였으며 이러한 도구에 대한 내용은 아래의 [표–1]와 같습니다.

표 1. 증거 수집 도구

2.2 분석 도구

분석 단계에서 사용한 도구는 아래 [표-2]와 같습니다. 

표 2. 증거 분석 도구

 분석 단계에 있어서 Volatility와 Rekall을 통하여 수집한 메모리를 분석하려 했으나, 수집 단계나 이송에 문제가 있었는지 해당 YURI-PC-20151112-110112.raw 정상적으로 인식되지 않아 수집한 메모리를 통한 분석은 하지 못하였습니다.

  3. 증거 수집

본 증거물은 의뢰자 PC로부터 2015-11-12 19:44:12부터 조사자의 USB를 연결하여 수집을 시작하였으며, 해당 의뢰자의 동참 하에 진행되었습니다. 그리고 각 분석의 진행을 시간 순으로 정렬한 내용은 아래와 같습니다.

그림 2. 증거 수집과 이송 절차 

 증거물 수집 과정에 있어 고려해야 할 사항은 다음과 같습니다.

• 의뢰자의 인터뷰
  • 전체적인 이미징은 거부함에 따라 선별적인 증거 수집
  • 압수 수색이 아니기에 의뢰자가 동의한 사항에서만 증거 수집
• 증거 수집에 있어 의뢰자가 동참하였으며 해당 의뢰자의 요청으로 인하여 지정된 수준까지만 수집이 가능

• 의뢰자는 증거 수집이 끝난 후 본인의 작업(LoL)을 해야 함에 따른 시간 상의 제약이 존재

* 증거 수집에 있어 해당 PC의 메모리 수집이 올바르게 되지 않았기에 해당 프로그램에 대하여 추가적인 분석을 위하여 의뢰자에게 해당 PC의 Economices.exe를 전송해줄 것을 요청하였고 15-11-13 03:41:50 해당 파일을 수신하였습니다.

3.1 증거물 대상과 수집 PC 환경

 수집 대상에 대하여 충분한 설명을 의뢰자에게 하였으며 이에 따른 동의가 있고 증거 수집을 하였기에 선별적인 증거 수집이 이루어졌으며, 의뢰자가 수집에 동의한 사항은 아래의 표와 같습니다.

표 3. 증거 수집 대상

 분석 대상 컴퓨터 환경에 대한 기본 정보는 아래의 표와 같습니다. 

표 4. 증거 수집 대상 PC 환경

3.2 증거 메모리 수집 : 2015-11-12 19:45:27

메모리 수집에 있어 DumpIt을 통하여 디스크의 변질을 최소화 하기 위하여 조사자의 외부 USB로 메모리 수집을 진행하였으며 YURI-PC-20151112-110112.raw로 저장이 되었습니다. 

3.3 증거 레지스트리 수집 : 2015-11-12 20:12:03

 REGA를 통한 레지스트리 수집을 하였으며 수집된 레지스트리 파일은 아래의 [표-5]와 같으며, 이렇게 수집된 레지스트리에 대한 해시와 시간은 [별첨-1]을 통하여 확인할 수 있습니다. 

표 5. 수집된 레지스트리 관련 자료

3.4 증거 PC의 $MFT 수집 : 2015-11-12 20:18:34

 FTK Imager와 WinHex를 통하여 $MFT와 $LogFile, $J 파일을 수집하였으며, 이 파일에 대한 해시 값은 아래와 같습니다. 

표 6. MFT파일 크기와 해시 값

3.5 의뢰자에게 별도로 받은 의심 파일 : 2015-11-13 03:41:50

 해당 의심 파일이 의뢰자에 PC에 남아있음을 인지하였으며 이에 대해 의뢰자에게 송신해줄 것을 요청하였으며, 이러한 요청에 의해 2015-11-13 03:41:50에 해당 파일을 송신하였습니다. 파일에 대한 내용은 아래의 표와 같습니다.

표 7. Economices.exe의 크기와 해시 값

 해시 값을 통하여 전송한 파일과 수신한 파일 간에 무결성이 유지되었음을 확인할 수가 있었습니다.

4. 상세 분석 내용

 상세 분석 내용을 제공하는 페이지 입니다. 의뢰자의 PC에서 수집한 증거를 분석실로 이송 후 조사자의 분석 환경에 해당 증거들을 옮긴 후 분석을 진행하였습니다.

4.1MFT 분석을 통한 시간대 확인

 의심되는 프로세스(Economices.exe)에 대한 타임스탬프를 확인할 것이며. 사건 현장은 상대적으로 의뢰자의 지인이 많이 찾아오는 장소로 동 시간대에 의뢰자가 잠시 자리를 부재한 사이(19:35:00-19:43:00)에 발생한 것임을 고려하여야 합니다.

 이를 토대로 근처 시간대를 확인할 것이며 해당 시간대에 의심되는 파일이 생성되거나 실행되었는지를 확인하기 위하여 MFT를 분석해 보았습니다.

그림 3. MFT 분석

 위의 그림과 같이 해당 프로그램은 "\Documents\카카오톡 받은 파일"에' eco폴더를 생성 후(19:40:12) 해당 경로에 저장(19:40:14)이 되었다는 것을 확인할 수가 있습니다. 이에 대한 csv파일은 [별첨-3]과 [별첨-4]에서 확인할 수 있습니다.

 이를 통해 의뢰자가 자리를 비우고 약 5분이 지난 후 제 3자에 의해 해당 파일이 생성되었음을 알 수가 있습니다.

4.2 해당 프로그램 침입 경로 확인

 위의 MFT 분석을 통해 시간대를 축소할 수가 있었으며, 이러한 시간에 이루어진 레지스트리 변경사항에 대하여 분석해보았습니다.

그림 4. USB 연결 흔적 확인

 그림-4과 같이 해당 시간(19:39:30)에 USB와 연결한 흔적들을 확인할 수가 있었으며 이를 통해 해당 프로그램이 USB를 통하여 복사되었음을 예상할 수가 있습니다. 하지만 여기서 최초 장비 연결 시 더 많은 레지스트리의 값이 변화하는데 몇 개의 값만이 변화되었기에 해당 USB는 이번이 최초 연결이 아님을 알 수가 있습니다.

 이는 그림-5를 보면 알 수 있듯이 해당 필드의 한 칸 상위인 VID_058F&PID_6366의 값은 마지막으로 쓰여진 값이 2015-10-04 03:11:47인 것을 통해 해당 일자에 최초로 PC에 연결이 되었으며 이번이 최초연결이 아님을 알 수가 있습니다.

그림 5. VID_058F&PID_6366 LastWriteTime

 이를 통해 해당 프로그램 Economices.exe를 설치한 피의자는 의뢰자의 지인임을 예상할 수가 있었으며, 여기에 사용된 USB의 정보는 아래의 표와 같습니다. 

표 8. 악성코드 유입에 사용된 USB의 정보

 해당 USB에 대한 사용 흔적은 수집한 대상 PC의 DriverFrameworks-UserMode 이벤트 로그에도 기록되었는데, 이에 대해 표-8을 보면 19:39:32에 연결하였다는 항목을 보아 위 그림-4과 그림-5에서의 내용에 신빙성을 더해주며, 해당 USB의 연결 해제가 19:41:57에 이루어졌다는 것 또한 확인을 할 수가 있습니다. 자세한 사항은 [별첨-5]를 통해 확인할 수 있습니다.

표 9. 증거 대상

4.3 기타 침해 입증 자료

 아래의 그림과 같이 해당 파일의 경로와 해당 Economices.exe가 레지스트리에 추가된 것(19:41:33)을 확인할 수가 있으며 이는 USB를 연결 해제(19:41:57)하기 전에 등록된 것임을 알 수가 있으며, 값이 추가되었다는 것은 컴퓨터를 종료 후 다시 실행할 때마다 해당 프로그램이 자동 실행되는 것을 의미하며 이는 악성코드가 지속성을 유지하고자 할 때 주로 쓰는 방법입니다.

그림 6. 지속성 유지를 위한 레지스트리 추가

 그림-7과 같이 해당 프로그램은 19:40:47에 실행이 된 것임을 확인할 수가 있습니다.

그림 7. Economices.exe 실행 시간

 대상 PC의 증거를 수집하며 네트워크 연결 상태도 확인을 해보았으며 이에 대한 사진은 [별첨-6]을 통해 볼 수 있고, 이를 토대로 중요한 사항인 3226(Economices.exe)은 현재 같은 IP 영역대인 192.168.0.5와 네트워킹을 하고 있었음을 알 수가 있습니다. 

표 10. Netstat을 통해 본 연결 상태

 이를 통하여 해당 프로그램은 같은 IP에 있는 의뢰자의 친구 김00씨의 PC가 연결된 주소로, 2대의 PC가 네트워킹을 하고 있음을 알 수가 있으며 이러한 악성코드의 기능은 아래에서 설명하겠습니다.

4.4 해당 프로세스의 악성코드 여부 확인

 Economices.exe에 대한 상세한 분석을 진행하는 페이지입니다. 해당 파일에 대한 PE구조를 분석하고 그에 맞게 분석을 진행하였습니다.

그림 8. PEiD의 출력 결과

 위의 그림과 같이 PEiD를 통하여 보았을 때는 별로 알 수 있는 유용한 내용이 없었으며 추가적으로 PE 구조를 더 살펴본 결과 .rsrc 섹션에 아래의 그림과 같이 PYTHON27.DLL이라는 문자열과 exe의 MZ 헤더와 PE 시그니처 등이 존재하는 것을 확인할 수가 있으며, 이러한 구조는 주로 Python으로 된 코드를 py2exe를 통하여 컴파일 했을 경우 주로 나타나는 구조임을 알 수가 있습니다.

그림 9. 해당 파일의 리소스 섹션

 이를 통하여 Py2exe된 파일을 다시 코드로 볼 수 있도록 제작하는 작업이 필요하며 사용된 도구는 [표-2]에 기재된 바와 같이 2개의 Python Code를 통하여 진행하였습니다. 해당 과정은 아래와 같습니다.

그림 10. Python Code 복구 과정

 이러한 과정을 통하여 복구된 파이썬 코드는 [별첨-7]와 같으며 이를 통해 파이썬의 기능에 대하여 알아보았습니다. 주요 기능은 아래와 같습니다.

• Pyhook을 통해 키로깅의 기능을 구현하였습니다.

• 의뢰인의 지인이였던 김00군 PC의 IP 주소인 192.168.0.5가 나타나있습니다.

 위 두가지 사실을 종합해보았을 때 해당 프로그램은 키로깅의 기능이 있으며 하나의 클라이언트로 동작하는 것을 확인할 수가 있었습니다. 이를 통해 의뢰인(192.168.0.3)은 김00군(192.168.0.5)에 키 이벤트를 전송하므로 개인 정보 유출의 위험이 많다는 것을 알 수가 있습니다.

그림 11. 메모리 분석을 통한 키로깅 확인

  5. 대응 방안

 위의 분석을 토대로 2차 피해 발생에 대응하기 위한 방안은 다음과 같습니다.

• 실행 중인 악성코드의 경우 해당 프로세스를 종료하여 추가적인 피해를 방지해야 합니다.

• 현재 피해자의 PC에 악성코드가 지속성을 유지하고 있기 때문에 해당 레지스트리의 값을 제거하여 2차적인 피해를 방지합니다.

• 피의자가 피해자의 관계 상 해당 프로세스를 다시 설치할 수가 있기에 피해자의 PC에 접근을 하지 못하게 하는 등 제약이 필요합니다.