RedScreen

안녕하세요~ Message 입니다. 오늘은~

<실전 악성코드와 멀웨어 분석> 책의 실습 문제 1-4 을 분석해보고자 합니다.

드디어 1번 문제를 벗어날 수 있는 마지막 문제입니다 ㅎㅎ 하지만 약간 난이도 있어보입니다.(ㅜㅜ)

분석환경은 동일하게  Windows XP / Vmware 9.0.3 build 입니다.

1. 바이러스 토탈에서 악성코드 여부 확인하기

분석하고자 하는 파일은 책에서 제공하는 실습용 악성코드 Lab01-04.exe 입니다.

37군데에서 악성코드라고 진단하였습니다.

\

2. 패킹되거나 난독화된 징후 찾기, 패킹이 되어있다면 언패킹하기

PEView로 보았을 때는 각 섹션의 영역이 정상적으로 있고,

Virtual Size와 Size of Raw Data(실제크기)가 약간의 차이가 있지만 정상으로 보입니다.

PEID로도 확인해본 결과 아무런 패킹이 되어 있지 않네요.

3. 이 프로그램이 컴파일 된 시각

컴파일 된 시각을 PEVIEW로 확인해본 결과

2019년 8월 30일로 나오는군요...임의로 변경된 시간이므로 신뢰할 수 없을 것 같습니다.

4. 임포트를 보고 악성코드의 기능 알아내기

DWalker를 통하여 임포트된 DLL을 살펴보겠습니다.

KERNEL32.DLL, MSVCRT.DLL, ADVAPI32.DLL 총 3개의 DLL이 임포트 되었네요.

그중 ADVAPI32.DLL 이 가장 의심스럽습니다. (실습 1-2에서는 해당 DLL이 CreateServiceA 를 호출하고

부팅 시 자동으로 실행되는 윈도우 서비스를 등록하는 악성코드였죠.)

ADVAPI32.DLL이 호출하는 API 함수들을 살펴볼까요? (자세한 내용은 MSDN에서 확인하세요)

AdjustTokenPrivileges

액세스 토큰에 할당되어 있는 권한을 활성/비활성화 시키는데 사용하는 API입니다.

새로운 권한을 추가하는 것은 불가능하며 해당 토큰이 가지고 있는 권한 내에서만 

활성/비활성 여부만 조정할 수 있습니다. 

5. 감염된 시스템에서 악성코드를 인식하는데 어떤 호스트 기반이나 네트워크 기반을 사용했는지(스압)

Strings 툴을 이용하여 해당 파일의 모든 문자열을 뽑아보았습니다.

위에서 발견한 임포트 함수들 외 악성행위를 할 것으로 의심되는 부분을 뽑아볼까요?

- URLDownloadToFileA

- http://www.practical...(생략)...anlysis.com/updater.exe

- system￦wupdmgrd.exe

이건뭐...뽑다보니 전부다 의심되는것들 투성이네요 ㅎㅎ(아래 스샷참고)

위와 같은 API들이 사용되는것을 대략적으로 파악했습니다.

[권한획득]

이제 임포트 함수애서 파악했던 권한에 관련된 API들부터 시작하여 차근차근 분석해볼까요, 

API들의 기능으로 보아, OpenProcessToken > LookupPrivilegeValueA > AdjustTokenPrivileges

순으로 진행이 될듯 한데요, 실제로 확인해본 결과 예측한 그대로 흘러가더군요.

올리디버그의 [우클릭 - Search for - found intermodular calls] 기능을 이용하여 해당 API들을 추적합니다.

먼저 OpenProcessToken 함수를 살펴볼까요? (아래 스샷 참조)

hProcess

프로세스의 핸들값, GetCurrentProcess를 이용하여 현재 프로세스의 핸들을 구하고 리턴값(EAX)을 넣어주네요.

DesiredAccess

원하는 접근 유형입니다. TOKEN_QUERY와 TOKEN_ADJUST_PRIVILEGES을 인자값으로 넣었네요.

잠시후 보게될 AdjustTokenPrivileges 함수에서는 토큰 권한을 수정할때 TOKEN_ADJUST_PRIVILEGES가 필요하며,

해당함수의 다섯번째 인수인 PreviousState 매개변수가 NULL일 경우 TOKEN_QUERY까지 필요합니다.

TokenHandle

반환되는 토큰의 핸들값을 받을 인자입니다.

다음은  LookupPrivilegeValue 함수를 살펴보겠습니다.

lpSystemName

시스템의 이름입니다.

lpName

어떤 권한이 있는지 확인하는 인자입니다. 이 인자값에서 악성코드 제작자의 의도를 알 수 있겠죠.

여기서는 "SeDebugPrivilege" 가 들어갔음을 볼 수 있는데요, 디버그 권한을 가진 프로그램은

프로세스 핸들을 이용하여 OpenProcess 나 OpenThread API를 사용할때 보안검사를 통과할 수 있게됩니다.

이 악성코드의 흐름상 권한을 획득한 뒤 바로 파일 생성 및 수정을 위해 OpenProcess가 사용됩니다.

아마 이를 위한 사전절차가 되겠네요.

lpLuid

반환되는 LUID(Locally Unique Identifier) 식별자를 받을 인자입니다. 시스템에서는 특권을 LUID로 구분합니다.

프로세스 핸들의 개념과 동일하게 보시면 되겠네요.

다음은  AdjustTokenPrivileges 함수를 살펴보겠습니다.

TokenHandle

권한을 변경하고자 하는 토큰의 핸들입니다.

DisableAllPrivileges

TRUE일경우 모든 권한을 disable로 설정합니다. TRUE일경우 아래의 Newstate값의 영향을 받습니다.

NewState

권한에 대한 정보를 담고 있는 TOKEN_PRIVILEGES 구조체 포인터가 들어가는 자리입니다.(아래 스샷 참조)

여기서 또한번의 구조체 포인터가 들어가게 되는데요, LUID_AND_ATTRIBUTES 구조체 입니다.

해당 구조체가 특권에 대한 Enable/Disable을 결정하는 플래그인 Attributes 플래그를 가지고 있습니다.(아래 스샷 참조)

언급은 안했지만 위에서 보았던 LookupPrivilegeValue 에서 알아낸 LUID를 이 구조체 안에 이미 담아두었답니다.

정리하면, LookupPribilegeVlaue API를 이용하여 알아낸 "SeDebugPriviliges" 의 LUID를 이용하여

해당 Attributes의 플래그가 Enable로 셋팅 되었다면 정상적으로 권한을 얻을 수 있다는것이죠!

(함수 실행전 구조체안의 변수들은(Attributes 플래그 포함) 이미 제작자가 세팅해 놓은 상태입니다.)

[윈도우 보안(WFP) 해제]

악성코드는 SeDebugPriviliges 특권을 얻은후 WFP를 무력화 시킵니다.

sfc_os.dll 안의 Ordinal #2 익스포트 함수를 LoadLibraryA + GetProcAddress를 이용하여 호출하는데요,

sfc_os.dll의 ordinal #2 익스포트 함수는 windows에서 시스템을 보호하기 위해 사용하는 WFP를

무력화시키기 위해 사용하는 함수입니다.

반대로 ordinal #1 함수는 WFP를 활성화 시키는 함수입니다.

(WFP는 우리가 Ctrl+Alt+Del 키를 눌렀을때 흔히 볼 수 있었던 winlogon.exe를 통해 활성화 됩니다.)

sfc_os.dll의 #1 익스포트 함수인 SfcInitProt가 호출되면 SFC Watcher Thread가 생성됩니다.

이 쓰레드가 실제 보호하고자 하는 프로세스의 이벤트를 감시합니다.

하지만 sfc_os.dll #2 익스포트함수는 SFC Watcher Thread를 제거하는 SfcTerminateWatcherThread 입니다.

(SFC Watcher Thread가 종료되면 재부팅 되기 전에는 다시 생성되지 않는다고 하네요.)

이러한 SfcTerminateWatcher를 호출하기 위해서는 "SeDebugPrivilege" 권한이 필요하며, SFC Watcher Thread를 생성한

winlogon.exe에서 직접 실행되어야 합니다.

따라서 악성코드 제작자는 SeDebugPrivilege를 얻어야만 했을것이고, 실제로 위에서 해당 작업을 수행했습니다.

정리하면, 악성코드는 

- CreateRemoteThread 함수를 이용하여 winlogon.exe를 실행시키고

- SfcTerminateWatcherThread를 호출하여 WFP를 무력화 시킵니다.

그 과정을 진행하기 위해서는 CreateRemoteThread 함수를 호출해야 하며,

안에 들어가는 주요 매개변수 값 2가지를 알아내야합니다.

첫번째로 GetProcAddress 함수를 사용하여 sfc_os.dll의 SfcTerminateWatcherThread의 주소값을 알아내야 하는것과

winlogon.exe의 프로세스 핸들값을 알아내야 합니다.

아래는 CreateRemoteTHread 함수입니다.

따라서 GetProcAddress 함수를 호출하여 SfcTerminateWatcherThread의 주소값을 얻은 후

OpenProcess 함수를 호출하여 winlogon.exe의 프로세스 핸들값을 얻어냅니다.

(OpenProcess를 하기위해 winlogon의 PID값을 알아내기위한 별도의 과정이 있으나 내용이 너무 길어져 생략합니다.)

(아래 스샷 참조)

두가지의 매개변수를 알아낸 후 바로 CreateRemoteThread 함수를 호출하여 WFP를 무력화시킵니다.

[시스템 파일 이동(백업)]

악성코드는 윈도우 WFP를 해제시킨 이후 system32 폴더 안에 있는 주요 파일을 임시폴더로 옮깁니다.

일단, GetWindowsDirectory 함수는 운영체제에 설치되어 있는 경로를 구하는 함수입니다.

lpBuffer에 uSize만큼의 경로를 담아오게 됩니다. (아래스샷참조)

Snprintf 함수는 원하는 포멧으로 버퍼에 문자열을 입력할 수 있는 함수입니다.

GetWindowsDIrectory 함수를 호출하여 받아온 경로 C:\Windows 값에 \system32\vupdmgr.exe 문자열을

합치는 역할입니다. 따라서 포맷은 %s%s(C:\Windows + \system32\vupdmgr.exe )입니다.

이후 GetTempPathA 함수를 호출하여 임시파일 디렉토리를 얻은 후

아까와 같은 방식인 %s%s 포맷으로 임시폴더 디렉토리와 파일명(\winup.exe) 문자열을 합칩니다.

이후 moveFIleA 함수를 호출하여 시스템 파일을 원하는 이름으로 변경한 뒤 임시폴더로 이동시킵니다.

[파일생성 및 실행]

시스템 파일을 이동시킨 후 악성코드는 새로운 파일을 생성 및 실행합니다.

먼저 시스템 파일을 백업할때처럼 wupdmgr.exe의 디렉토리 주소를 알아낸후 GetMoudleHandle 함수를 호출하여

실행중인 모듈의 핸들을 얻습니다. (아래스샷 참조)

이후 FindResourceA 라는 함수를 호출하는데요, 이 함수는 실행모듈이 가진 리소스를 검색하는데 사용됩니다.

아마 악성코드 안에 추가적인 악성코드 파일이 있는것 같습니다. 흔히 이런 악성코드를 드로퍼(Dropper)라고 지칭합니다.

FindResourceA 함수를 호출하여 얻어낸 리소스의 핸들을 이용하여

LoadResource 함수를 호출하는데요, 이 함수는 해당 리소스를 메모리 적재를 수행합니다.

SizeofResource를 이용하여 적재된 리소스의 사이즈를 알아낸 후 다음 작업을 진행합니다.

그 이후 바로 CreateFIleA 함수를 호출하는데요, 이 함수는 파일을 오브젝트를 생성 또는 오픈할 수 있는 함수입니다.

lpFileName : 파일을 생성하거나 열 경로입니다.

dwDesiredAccess : 파일에 대한 액세스 권한을 지정합니다.

dwShareMode : 파일 공유모드를 지정합니다.

lpSecurityAttributes : SECURITY_ATTRIBUTES 구조체의 포인터입니다. 사용하지 않을 경우 NULL

dwCreationDisposition : 파일의 존재 유무에 따른 행동입니다. 플래그에 따라 결정됩니다.(ex 파일 없을 경우 생성, 항상 생성, 파일 열기 등)

dwFlagsAndAttributes :  파일의 속성을 지정합니다(ex 읽기전용, 숨김, 보관 기능 등)

hTmplateFile : GENERIC_READ 액세스 권한을 가진 템플릿 파일의 유효한 핸들입니다. 사용하지 않을 경우 NULL

system32 폴더에 wupdmgr.exe 파일 생성을 성공한 후 WriteFile 함수를 호출하여 파일 안의 내용을 채웁니다. (아직은 빈파일이니까요)

파일 내용은 FindResource + LoadResource로 적재해준것으로 채워지겠죠!

이후 CloseHandle로 핸들을 닫고 WInExec으로 생성한 파일을 실행합니다. 이것으로 악성코드의 주요 행동이 분석되었습니다.

6. Resource Hacker를 이용하여 리소스를 점검하고 추출하기

정적분석에서 이미 파악한 내용이지만, Resorce Hacker를 이용하여 리소스를 점검하고 추출해보겠습니다.

리소스가 발견되었습니다. 정적분석시 발견되었던 BIN 타입의 101 이름을 가진 리소스군요.

이것으로 분석 1-4를 마치겠습니다. 책만 봤을 때는 그냥 간단하겠구나 싶었는데

막상 정적분석을 하니 내용이 많이 길어졌네요.

읽어주셔서 감사합니다. 혹시 틀린점이 있다면 댓글 남겨주세요.

지금까지 Message 였습니다. 모두 즐거운 하루 되세요!

안녕하세요~ Message 입니다. 오늘은~

<실전 악성코드와 멀웨어 분석> 책의 실습 문제 1-3 을 분석해보고자 합니다.

문항수는 줄어들고 있지만 내용은 점점 많아지는 느낌입니다 ㅋㅋ

분석환경은 동일하게  Windows XP / Vmware 9.0.3 build 입니다.

안녕하세요~ Messager 입니다. 오늘은~

<실전 악성코드와 멀웨어 분석> 책의 실습 문제 1-2 을 분석해보고자 합니다.

분석환경은 Windows XP / Vmware 9.0.3 build 입니다.

1. 바이러스 토탈에서 악성코드 여부 확인하기

분석하고자 하는 파일은 책에서 제공하는 실습용 악성코드 Lab01-02.exe 입니다.

19군데에서 악성코드라고 진단하였습니다.

2. 패킹되거나 난독화된 징후 찾기

먼저 PEView로 확인해보겠습니다... 패킹이 되어 있지 않다고 뜨네요.

근데.. EP Section에 UPX1은 뭘까요? PEVIEW로 구조를 살펴봐야겠습니다.

PEVIEW로 살펴보니 의심스러운게 한두군데가 아닙니다.

PE구조 끝마다 붙은 UPX0,1,2 등등이 더 의심스럽게 만듭니다. 파일의 가상크기와 실제크기를 확인해 보겠습니다.

Virtual Size는 4000인 반면에, 실제크기인 Size of Raw Data는 0 군요.. 패킹이 되어있는것 같습니다.

아무래도 PEID가 만능은 아닌 모양입니다.

UPX 툴을 이용하여 언패킹하였습니다.

3. 임포트를 보고 악성코드의 기능 알아내기

Dependency Walker으로 파일을 분석한 결과 총 4개의 DLL을 임포트 하고 있습니다.

KERNEL32.DLL, MSVCRT는 프로그램들이 흔하게 사용하는 DLL이지만

ADVAPI32.DLL, WINNET.DLL은 살펴볼 필요가 있겠습니다.

의심스러운 API들은 아래와 같습니다.

KERNEL32.DLL : GetMoudleFileNameA, CreateThread (다른 API들과 사용될 경우 후킹, 인젝션등에 사용될 가능성)

ADVAPI32.DLL : CreateServiceA (윈도우 서비스 생성 - 보이지 않지만, 윈도우 부팅시 항상 실행되는 프로그램)

WINNET.DLL : InternetOpenA, InternetOpenUrlA(Open함수로 세션 생성, Url함수로 특정 URL로 접속할 가능성)

4. 감염된 시스템에서 악성코드를 인식하는데 어떤 호스트 기반이나 네트워크 기반의 증거를 사용했는지

임포트 함수 분석 시 가장 의심스러웠던 CreateService, InternetOpenA, InternetOpenUrlA 위주로

올리디버그를 이용한 분석에 들어갑니다.

올리디버그의 [우클릭 - Search for - All(Found)l intermodular calls] 기능을 이용하여 해당 API들을 추적합니다. 

7번째쯤 CreateServiceA API가 보이고, 13번째쯤 InternetOpenA API가 보입니다. 

CreateServiceA 부터 더블클릭하여 살펴봅니다.

Malservice란 서비스 이름과 SERVICE_AUTO_START 인자가 눈길을 끕니다.

SERVICE_AUTO_START의 경우 시스템이 시작될 때 자동으로 실행되는 옵션입니다.

그 다음으로 InternetOpenA API를 추적합니다.

InternetOpen API를 통하여 Internet Explorer 8.0 으로 세션을 연결한뒤

바로 뒷부분에서 InternetOpenUrlA API를 통해 ASCII코드로 저장해 두었던

특정 URL로(http://www.malwareanalysis....) 접속을 하는군요.

<실전 악성코드와 멀웨어 분석> 책의 실습 문제 1-1 을 분석해보고자 합니다.

분석환경은 Windows XP / Vmware 9.0.3 build 입니다.

1. 바이러스 토탈에서 악성코드 여부 확인하기

    분석하고자 하는 파일은 책에서 제공하는 실습용 악성코드 Lab01-01.exe와 Lab01-01.dll 2개의 파일입니다.

    exe파일을 바이러스 토탈에 검색해보겠습니다.

   

  

  
  

   Avast와 Ikarus에서 악성코드라고 판별하는군요.

2. 악성코드의 컴파일 정보 확인하기

    Stud_PE로 확인해본 결과 Visual C++ 6.0에서 컴파일 되었네요. 컴파일된 시간을 알아내기 위해

    PEView로 살펴보겠습니다.

   Lab01-01.exe의 경우 IMAGE_NT_HEADER -> IMAGE_FILE_HEADER -> Time date Stamp 에서

   2010/12/19 16:16:19 UTC에 컴파일 된 사실을 알 수 있었습니다.

   Lab01-01.dll 역시 exe파일과 약 20초 차이로 컴파일 되었습니다.

   책에서는 동일한 제작자에 의해 동일한 시간에 생성됐다는 암시로 보고 있습니다.

     PEView를 통하여 IMAGE_SECTION_HEADER를 살펴보면 패킹이 되었는지 확인해볼 수 있습니다.

     Virtual Size(가상크기)와 Size of Raw Data(원래 데이터 크기)를 비교하였을 때 Virtual Size가 Size of Raw Data

     보다 월등히 크다면 패킹을 의심해보아야 합니다.

     하드디스크의 offset 구조에서 메모리 영역으로 로딩되면서 NULL Padding의 크기 차이가 발생하기 때문에

     약간의 차이는 발생하지만, 비교해본 결과 별 차이가 없네요.

     PEid를 이용하여 패킹의 여부를 추가적으로 확인해보았으나, 패킹되지 않았네요.

     패킹의 흔적이 없으니 기타 동적/정적 분석시 문제가 없을것같습니다.

     [ exe파일 ]

     

     [ dll파일 ] 

    

4. DLL 임포트 리스트 확인하기

    Dependency Walker를 이용하여 Lab01-01.exe 파일의 Import된 DLL 목록을 살펴보면

    KERNEL32.DLL과 MSVCRT.DLL 두개의 DLL을 임포트하고 있는것을 볼 수 있습니다.

    MSVCRT.DLL의 모든 임포트 함수의 경우 컴파일러가 추가한 래퍼 코드의 일부분으로 거의 모든 실행파일에

    포함되어 있는 함수라고 합니다. 무난하게 Pass~!

    문제는 KERNEL32.DLL의 CreateFileA, FindFirstFIleA, FindNextFileA과 같은 함수들입니다.

    이 함수들을 이용하여 악성코드가 시스템의 파일을 탐색하거나 새로운 파일을 만드는데 쓰일 수 있습니다. 

   다음으로 Lab01-01.DLL을 살펴보겠습니다.

   KERNEL32.DLL, WS2_32.DLL, MSVCRT.DLL 총 3개의 DLL을 임포트하는군요.

   KERNEL32.DLL의 경우 악성코드가 프로세스를 생성할 수 있는 CreateProcessA 함수를 포함하고 있습니다.

5. 감염된 시스템에서 검색할 수 있는 다른 파일이나 호스트 기반의 증거 확인

    올리디버그의 Serch 기능으로 텍스트를 검색해 보았습니다.(마우스 우클릭 -> Serch for -> All referenced text strings)

    결과값으로 Kernel32.dll 과 이름이 유사한 Kernel132.dll 의 경로값이 나왔습니다.(영어 L을 숫자 1로 표현)

   해당 스트링을 어떤 용도로 사용하는지 알아내기 위해 더블클릭하여 따라가 보았습니다.

   처음 DWalker로 파악한 CreateFileA API가 이곳에 쓰였습니다.

   아마 Kernel132.dll을 일반 시스템 Dll로 위장시켜 악성행위를 하는 악성코드로 추정됩니다.

6. 감염된 시스템에서 이 악성코드를 발견하기 위해 사용한 네트워크 기반의 증거 확인

    같은 방법으로 dll 역시 올리디버거로 살펴보겠습니다.

    수상한 IP 주소가 보이네요.(127.26.152.13)

    아래쪽에는 백도어에서 사용할 가능성이 높은 sleep과 exec이 보입니다.

   주소를 더블클릭하여 추적한 결과

   inet_addr() 함수를 통해 외부로 통신함을 알 수 있었습니다.

7. 악성코드의 목적 확인

    Kerne132.dll을 만들어 사용하고(혹은 위장) sleep과 exec을 이용하여

    외부 C&C서버(127.26.152.13)와 통신하는 백도어로 추정됩니다.