Stuxnet malware analysis report - volatility 중심으로 메모리 분석

악성 문자열 확인

 

메모리에 ‘.stub’이 있는지 알아보기 위해 strings 명령어를 사용하여 결과를 텍스트 파일로 저장해 봤습니다.

[그림 1] 명령어: strings /Users/lucykorea/Desktop/DF/assignment/stuxnet.vmem | grep -E "\.stub" > /Users/lucykorea/Desktop/DF/assignment/task1a.txt

이 명령어를 실행한 결과, 생성된 텍스트파일의 캡쳐화면은 다음과 같습니다.

[그림 2] task1a.txt 의 텍스트파일

 

메모리에 ‘mrxnet.sys’이 있는지 알아보기 위해 strings 명령어를 사용하여 결과를 텍스트 파일로 저장해봤습니다.

[그림 3] 명렁어: strings /Users/lucykorea/Desktop/DF/assignment/stuxnet.vmem | grep "mrxnet\.sys" > /Users/lucykorea/Desktop/DF/assignment/task1b.txt

이 명령어를 실행한 결과, 생성된 텍스트파일의 캡쳐화면은 다음과 같습니다.

[그림 4] task1b.txt의 텍스트파일

 

메모리에 ‘verisign’이 있는지 알아보기 위해 strings 명령어를 사용하여 결과를 텍스트 파일로 저 장해봤습니다.

[그림 5] 명령어: strings /Users/lucykorea/Desktop/DF/assignment/stuxnet.vmem | grep "verisign" > /Users/lucykorea/Desktop/DF/assignment/task1c.txt

이 명령어를 실행한 결과, 생성된 텍스트파일의 캡쳐화면은 다음과 같습니다.

[그림 6] task1c.txt의 텍스트파일

 

 

 

메모리 덤프 뜬 시간 확인

stuxnet.vmem을 자세히 분석하기 전, 기본 정보를 보기 위해 windows.info를 실행했습니다.

[그림 7] windows.info 명령 실행 결과

 

이때, 중간에 SystemTime을 보면 다음과 같이 2011-06-03 04:31:36으로 설정되어있는 것을 확인 할 수 있습니다.

[그림 8] Windows.info 중 SystemTime

이 시간은 메모리 덤프가 생성된 시점의 시간을 의미하므로, 이 메모리 덤프는 2011년 6월 3일 4 시 31분 36초에 생성되었음을 알 수 있습니다.

 

 

악성 프로세스 분석

현재 실행중인 프로세스 목록을 보기 위해 windows.pslist 명령어를 실행했습니다.

[그림 9] windows.pslist 명령 실행 결과

위 그림에 하이라이트 쳐 있는 lsass.exe는 Local Security Authority Subsystem Service으로 윈 도우가 부팅될때 실행되는 프로세스 중 하나입니다. Pid가 680인 lsass.exe는 처음 부팅될 시간인 2010년 10월 29일 실행되었지만 pid가 868, 1928인 하단에 있는 두 lsass.exe는 부팅되고 한참 이후인 2011년 6월 3일에 실행된 것을 볼 수 있습니다. 이는 비정상적인 행동이므로 악성 프로세스로 판단하였습니다.

 

 

더 자세하게 종료되었거나 숨겨진 프로세스까지 보기 위해 windows.psscan 명령어를 실행했습니다.

 

[그림 10] windows.psscan 명령 실행 결과

여기에서도 똑같이 2011년에 비정상적으로 실행된 lsass.exe 프로세스가 두개로, pid 1928와 869을 가지고 있습니다. 따라서 이 프로세스가 제일 의심스럽기 때문에 이 프로 세스 위주로 분석을 진행하겠습니다.

 

windows.pstree 명령어를 사용하여 전체 프로세스 트리를 출력했습니다.

[그림 11] windows.pstree 명령 실행 결과

이때, 세개의 lsass.exe에 대한 부모 프로세스로는 winlogon.exe와 services.exe가 있다. 이 를 좀 더 가독성 있게 보기 위해 다음과 같이 출력해줬습니다.

[그림 12] 명령어: python vol.py -f /Users/lucykorea/Desktop/DF/assignment/stuxnet.vmem windows.pstree | grep

-E 'lsass.exe|winlogon.exe|services.exe'

pid가 868과 1928을 가진 lsass.exe는 parent process로 services.exe를 가진다. 원래 lsass.exe는 winlogon.exe를 parent process로 가지므로 lsass.exe 868과 1928은 비정상적 인 프로세스임을 알 수 있습니다

 

 

lsass.exe에 대한 모든 dll list를 windows.dlllist 을 이용해 출력해주었습니다.

[그림 13] pid 680 lsass.exe(정상)에 대한 dll list (이하 약 20줄 생략)
정상인 lsass.exe(680)의 dll list를 보면 엄청 많이 있는것을 알 수 있습니다.

 

[그림 14] pid 868 lsass.exe에 대한 dll list

하지만, 비정상적인 lsass.exe(868)은 lsass.exe(680)과 비교했을때 현저히 dll의 수가 적은 것을 알 수 있습니다.

 

[그림 15] pid 1928 lsass.exe에 대한 dll list

lsass.exe(1928)도 마찬가지로 lsass.exe(680)에 비해 훨씬 적은 dll을 확인할 수 있다. 이때, 하이라 이트 친 부분을 보면 이상한 경로를 통해 kernel32 dll을 불러오고 있는것을 볼 수 있습니다.

이때, windows.ldrmodules도 분석해봤습니다.

[그림 16] pid 680 lsass.exe(정상)에 대한 ldrmodules
정상인 lsass.exe(680) 프로세스는 하나의 mapped path를 가지는 것을 확인할 수 있습니다.

 

[그림 17] pid 868 lsass.exe에 대한 ldrmodules

lsass.exe(868)에 대한 ldrmodules의 결과를 보면, 위와 같이 하이라이트 되어있는 부분에 mapped path가 N/A로 나와있는 것을 확인할 수 있습니다. 이를 더 자세하게 보기 위해 windows.malfind 명령어를 실행해보았습니다.

[그림 18] pid 868 lsass.exe에 대한 malfind 결과

결과를 보면, ldrmodules를 통해 확인했던 mapped path가 없는 주소인 0x80000와 0x100000에 대해 MZ가 file signature인 exe 파일이 있는것을 확인할 수 있고, 이 실행파일이 악성파일이라고 추측할 수 있습니다.

 

위와 같이 pid 1928에 대한 ldrmodules와 malfind 결과를 비교해보겠습니다.

[그림 19] pid 1928 lsass.exe에 대한 ldrmodules

[그림 20] pid 1928 lsass.exe에 대한 malfind

이 결과를 보면 lsass.exe(1928)에 대해 주소값 0x80000, 0x100000, 0x870000에 대해 모두 악성 실행파일이 있는것을 확인할 수 있으며, 추가적으로 주소값 0x6f0000와 0x680000에 대해서도 의 심스러운 코드가 있는 것을 확인할 수 있습니다.

 

 

악성 드라이버 확인

메모리 덤프 안에 있는 드라이버들을 출력할 수 있는 windows.modules 명령어를 실행해줬습니다.

(중략)

[그림 21] windows.modules 명령 실행 결과

윗부분에 있는 모듈들의 path를 보면 대부분 \SystemRoot\나 \windows\등 정상적인 path를 사용하고 있는것을 볼 수 있지만 하단에 하이라이트 되어있는 세 모듈을 보면 \??\로 시작하는 특이한 path를 사용하는 것을 볼 수 있습니다. 이때 여기서 사용되는 드라이브를 보면 vmmemctl.sys, PROCMON20.sys, mrxcls.sys, mrxnet.sys이 실행됨을 확인할 수 있습니다.

 

systemlookup.com에서 찾은 결과, 이때 vmmemctl.sys는 VMWare의 관련 프로그램이고 PROCMON20.sys는 sysinternals와 관련된 프로그램입니다. 하지만 mrxcls.sys와 mrxnet.sys 모두 악 성으로 결과가 나온 걸 확인할 수 있습니다.

 

[그림 22] vmmemctl.sys 분석 결과

[그림 23] PROCMON20.sys 분석 결과

[그림 24] mrxcls.sys 분석 결과

[그림 25] mrxnet.sys 분석 결과

따라서, mrxcls.sys와 mrxnet.sys 드라이버가 Stuxnet에 사용된 악성 드라이버인것을 확인할 수 있 다.

 

 

악성 프로세스, 드라이브 덤프 및 해시값 생성

lsass.exe pid 868과 1928 프로세스를 덤프하기 위해 우선 windows.pslist –dump 명령어를 사용하 여 다음과 같이 덤프했습니다.

[그림 26] lsass.exe 868과 1928의 덤프 결과
또한, 악성 드라이버인 mrxcls.sys와 mrxnet.sys를 다음과 같이 덤프했습니다.

[그림 27] mrxcls.sys와 mrxnet.sys의 덤프 결과

 

이 네 덤프 파일에 대한 sha256 해시값을 다음 그림과 같이 맥북의 openssl sha256 명령어를 사 용하여 계산하였으며, 계산 결과는 다음 표와 같습니다.

[그림 28] sha256 해시값 계산

 

대상 파일	해시값
lsass.exe(868)	e4377f2c8ddb2bbf38f4dd47c721e62c4c0346618f6290d6b629bc7e1108f90f
lsass.exe(1928)	0e03d3398eb2cc3d96c39a551d67945a427e39890aa94f2c57396fd8e4805d9b
mrxcls.sys	431daa815763688e94be46066c0cca657f4b229d2f6ba61080cf0a6d210b8e8b
mrxnet.sys	2c0958672a76cc94b1f223dc34a933eb70598a33e200aeeb3ae72dc5f8fa4d70

[표 1] 각 파일에 대한 sha256 해시값