Stuxnet 분석

Stuxnet

• 2008년 발견
• 이란 등 국가의 가스 파이프라인이나 발전소 같은 특정 산업 제어 시스템 위협
• 그들이 원하는 의도를 수행하게끔 PLC(Prgramming Logic Contoller)를 재구성함으로써 기능을 방해

 

Stuxnet 특징

• 네트워크 쉐어를 통하여 원격 컴퓨터로 복사 및 실행
• LAN 구간을 통하여 업데이트
• MS 취약점을 통한 권한 상승
• 윈도우 루트킷 포함
• 보안 제품 우회 시도
• PLC 조작

그림 1-1 Stuxnet 감염구조

① configuration data의 유효성을 검사한다.
② 다음 레지스트리 키의 NTVDM TRACE 값을 검사한다.
    HKLM \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ MS-DOS Emulation. 이 값은 감염 여부를 기록하는 값으로 값이
    19790509이면 감염된 시스템을 의미한다. 1979년 5월 9일을 의미하며, 관련 내용은 다음 주소를 참고하기 바란다.
    http://en.wikipedia.org/wiki/Habib_Elghanian
③ configuration data의 날짜를 검사한다.
④ global mutex를 생성한다.
⑤ stuxnet의 .stub 섹션으로부터 아래와 같이 암호화된 파일을 생성한다.
    1) main stuxnet payload .dll 파일을 Oem7a.PNF로 저장
    2) %SystemDrive%\inf\mdmeric3.PNF
    3) %SystemDrive%\inf\mdmcpq3.PNF(configuration data)
    4) %SystemDrive%\inf\oem6C.PNF(log file)
⑥ 현재 날짜가 2012년 6월 24일 이전인지 검사. 또한 최신 버전 여부 검사
⑦ 201, 241 resource를 디스크에 Mrxnet.sys, Mrxcls.sys로 저장하며, 각각 Load Point와 Rootkit으로 동작한다.
⑧ .dll 파일을 services.exe에 injection 후 export 32를 호출하여 연결되는 이동식 디스크 감염과 RPC Server를 시작한다.
⑨ Step 7 project 감염을 위해 .dll 파일을 Step 7 프로세스(S7tgtopx.exe)에 injection 후 2번 export 함수를 호출

 

 

imageinfo를 통해 WinXPSP2x86 서비스 팩 하고 2011-06-03 04:31:36 날짜 생성된 것을 알 수 있다.

그림 1-2 imageinfo

pstree를 통해 프로세스를 확인했다.

그림 1-3 pstree

lsass.exe 인증에 관련된 프로세스라 의심스럽다. Winlogo.exe 밑에 service.exe와 lsass.exe 동등하게 실행되는 게 정상적인 프로세스지만 하위에서 실행되는 것을 알 수 있다. 

그림 1-4 lsass.exe

psxview 다른 프로세스 플러그인을 확인했다.

그림 1-5 psxview

수상한 프로세스는 없지만 Procmon.exe는 악성코드 분석가가 사용하는 도구를 확인할 수 있다.

그림 1-6 Procmon.exe

외부 네트워크와 연결되었는지 확인을 위해 connections, connscan을 사용했지만 연결된 네트워크는 없는 것을 알 수 있다.

그림 1-7 외부 네트워크

PID 1928,868,680의 메모리 덤프를 만들었다.

그림 1-8 procdump

dlllist를 정상적인 프로세스를 확인했다.

그림 1-9 dlllist

PID 1928 비정상적인 프로세스는 KERNER32.DLL를 확인할 수 있다.

그림 1-10 비정상적인 프로세스

malfind를 통해 데이터를 찾았다.

그림 1-11 malfind

PAGE에 대한 EXECUTE권한과 READWRITE 권한을 가지고 있다.

그림 1-12 권한

문자열 ZwMapViewOfSection 네이티브 함수의 미러링 함수를 확인할 수 있다. 윈도우 제공하지 않는 함수는 위치를 복제한 것처럼 보면 된다.

그림 1-13 함수

악성으로 추측되는 파일인 것 같다.

그림 1-14 KERNEL32

0x80000, 0x1000000, 0x870000 주소의 vadinfo를 보면 파일 핸들이 조회되지 않아 보통 파일에서 핸들을 가져온다. 없는 것으로 보아 정상적으로 호출이 된 DLL 파일이 아닌 것 같다. 

그림 1-15 vadinfo

ldrmodules를 보면 VirtualAlloc과 WriteProcessMemory로 주입된 듯 보이는 메모리를 확인할 수 있다.

그림 1-16 lsass.exe

원본 lsass.exe 파일이 올라오는 메모리  경로를 확인할 수 없어 수상한 것 같다.

그림 1-17 경로

v옵션을 통해 경로를 확인했다.

그림 1-18 v옵션

정상적인 프로세스 같지 않는 것을 알 수 있다.

그림 1-19 비 정상적인 프로세스

유령 프로세스

• 정상적인 프로세스를 시스템에 로드하는 몇 멀웨어가 사용하는 기술
• 적대감 있는 코드를 포함시켜 동작
• 정상적인 코드는 악의적인 코드에 의해서 교체되어 실행되지 않음
• 정상적인 프로세스들처럼 이 프로세스가 숨도록 도움
• 정상적인 프로세스처럼 정상적인 API 등을 임포트
• PEB는 훼손시키지 않지만 프로세스 내의 실제 코드와 데이터는 바뀌어 실행

두 개 주소에 대해 메모리 덤프를 만들었다.

그림 1-20 dlldump

apihooks를 해보면 NT Syscall Hooktype이고 네이티브 후킹을 하고 있고 Vicitim과 Hooking ntdll.dll, ntdll.dll인 것으로 보아 자기 자신을 후킹 하는 것을 보아 변조된 것을 알 수 있다.

그림 1-21 DLL

Function 함수만 보면 네이티브 함수에 관련된 미러링 함수를 확인할 수 있다.

그림 1-22 네이티브

volshell를 통해 후킹 된 코드를 보면 0x7c90050은 변조된 코드이고 0x7ffe0300은 코드 섹션을 호출하는 것으로 보아 정상적인 코드인 것을 알 수 있다.

그림 1-23 volshell

해당 파일의 메모리 덤프를 만들었다.

그림 1-24 dlldump

HookedSSDT를 통해 커널 다이브를 보면 PROCMON인 것을 알 수 있다. 프로세스 모니터링하기 때문에 조회되는 것 같다.

그림 1-25 HookedSSDT

callbacks를 보면 너무 많은 정보를 확인할 수 있다. 의심스러운 것은 구글 통해 어떤 모듈인지 알 수 있다.

그림 1-26 callbacks

mrxnet.sys 모듈을 검색하면 stuxnet 관련된 모듈인 것을 알 수 있다.

그림 1-27 mrxnet.sys

modules 플러그인을 통해 mrx base address 알 수 있다.

그림 1-28 modules

Base Address의 메모리 덤프를 만들었다.

그림 1-29 moddump

devicetree를 통해 드라이브와 객체의 관계 및 연결된 장치를 확인했다.

그림 1-30 devicetree

FILE_DEVICE에 MRxNet에 많은 관여된 것을 볼 수 있다.

그림 1-31 FILE_DEVICE

Ntfs FILE_DEVICE에 많은 관여된 것을 볼 수 있다.

그림 1-32 NTFS

print key를 통해 레지스트리 정보를 보면 mrxney.sys 위치를 알 수 있다.

그림 1-33 기타정보

mftparser를 통해 프로세스 위치와 시간을 알 수 있고 filescan을 통해 mrx 종류에 대해 알 수 있다.

그림 1-34 기타정보

userassist를 통해  프로그램 목록을 확인할 수 있다.

그림 1-35 userassist