#1 : http://redscreen.tistory.com/66

#2 : http://redscreen.tistory.com/67

#3 : http://redscreen.tistory.com/68

#4 : http://redscreen.tistory.com/71

 

------------------------------------------------------------------------------------------------------------------------------------------

7. Strings 윈도우를 이용해 디스어셈블리 내의 문자열 \cmd.exe /c를찾아보자. 어디에 있는가?

------------------------------------------------------------------------------------------------------------------------------------------

View > Open Subviews > Strings 를 선택하여 해당 문자열을 찾습니다. (Shitft + F12)

맨 아래부분에서 발견 가능하고, 더블클릭하면 섹션과 주소값을 알아낼 수 있습니다.

답 : xddors_d 섹션 / 0x10095B34

 

 

------------------------------------------------------------------------------------------------------------------------------------------

8. \cmd.exe /c를 참조하는 코드 영역에서 무슨 일이 발생하는가?

------------------------------------------------------------------------------------------------------------------------------------------

해당 메소드가 어떤 기능을 하는지 알아내기 위해 해당 문자열을 더블클릭합니다.

이후에 문자열의 주소를 클릭하고 상호참조 리스트를 호출합니다. (Ctrl+X)

결과는 아래와 같이 단 한곳에서 호출함을 알 수 있습니다.

gethostbyname처럼 여러군데에서 호출되지 않으니

한군데만 확인하면 어떤 기능을 하는지 확인할 수 있다는 단서를 제공합니다.

 

또한 해당 코드영역을 더 살펴보면

"Hi, Master..."

"Welcome Back...."

"Encrypt Magic Number For This Remote Shell Session..."

등등의 백도어에서 원격 접속 시 사용될 것 같은 문자열이 있습니다. 

 

CMD창을 이용하여 명령어를 입력할 가능성이 있음을 기억해둡니다.

그리고 아까 상호참조를 타고 그래프 뷰로 넘어가서 화살표를 따라 쭉쭉 내려가면

"quit", "exit", "cd" 와 같은 문자열과 함께 memcmp 함수를 발견할 수 있습니다. 

 

책에서 memcmp를 볼 수 있을거라고 매우 쉽게 설명되 있지만, 

저는 아직 숙련되지 않기도 했고, 그래프가 크게 느껴져서  삽질을 좀 많이

빨간색(FALSE), 초록색(TRUE), 파란색(무조건) 화살표의 의미를 생각하며 그래프를 타고 내려가면

그래프 오버뷰의 중간 부분에서 memcmp가 반복 됩니다.

CMD에서 명령어를 입력할때마다 memcmp함수로 어떤 명령인지 비교하는 코드겠구나..라는 생각이 들었습니다.

답 : 원격 세션 생성

 

 

------------------------------------------------------------------------------------------------------------------------------------------

9. 같은영역 0x100101C8에서 dword_1008E5C4는 경로를 지정하는 전역 변수로 보인다.

    악성코드는 어떻게 dword_1008E5C4를 설정하는가? (힌트 : 상호참조 이용)

------------------------------------------------------------------------------------------------------------------------------------------

주어진 x100101C8 주소로 넘어가면 dword_1008E5C4값이 나옵니다.

 

해당 전역변수를 더블클릭하면 .data 섹션으로 넘어가게 되는데,

그곳에서 상호참조 리스트를 확인하면 아래와 같이 3가지가 나옵니다.

 

전 포스팅에서 살펴보았듯이 R Type은 읽기만 할뿐이고,

수정하는 부분은 맨위의 W Type 하나뿐이므로, 해당 부분을 살펴보면 어떻게 무슨값을 설정하는지 알 수 있겠군요.

OK를 누르고 해당 주소지로 이동하면, 아래와 같이 sub_10003695의 리턴값인 EAX를 이용하여

전역변수에 값을 할당하는 것을 볼 수 있습니다.

 

그렇다면 sub_10003695는 무엇을 하는 서브루틴일까요?

더블클릭하여 이동하면 아래와 같이 GetVersionExA 함수를 사용하는 소스임을 알 수있습니다.

아래 소스코드가 한눈에 파악이 안되어, Syntax부터 살펴보기로 했습니다.

 

GetVersionExA API의 SynTax는 아래와 같고, lpVersionInfo 파라미터를 넣어줘야 합니다.

push eax 를 이용하여 파라미터를 넣어주었고, GetVersionExA API로 버전값을 알아낸 것으로 보입니다.

 

이후에 VersionInformation 내부의 dwPlatformId 값이 2인지 CMP 명령어를 이용하여 비교를 하게 되는데,

참고로 dwPlatformId는 아래와 같이 윈도우 버전에 관련된 변수입니다.

 

두값이 같을 경우, CMP명령어의 결과는 0이되고 제로플래그(ZF)가 1로 세팅됩니다.

ZF가 1이라면 SETZ 명령어에 의해 AL(EAX의 하위 8비트)가 1로 세팅됩니다.

 

정리하면, Windows 계열인 경우 서브루틴 sub_10003695가 1을 리턴할 것이고,

리턴되는 값이 dword_1008E5C4 값에 저장될 것입니다.

답 : 운영체제 버전 저장

 

--------------------------------------------------------------------------------------------------------------------------------------------------

Tip. CMP 그리고 JUMP (JA vs JB vs JE vs JZ)

1) CMP

CMP는 묵시적으로 Op1(Destincationm, 피연산자)에서 Op2(Source, 소스피연산자)와의 뺄셈을 수행 ex) CMP Op1, Op2

그리고 어떤 피연산자도 수정되지 않지만, 뺄셈을 수행하다보니 플래그를 수정합니다.

- Op1 - Op2 < 0, ZF=0 CF=1

- Op1 - Op2 > 0, ZF=0 CF=0

- Op1 - Op2 = 0, ZF=1 CF=0

2) JUMP

JMP와 관련된 명령어는 매우 많지만 이번 문제에서 자주 쓰이는 Jump 명령어를 정리합니다.

- JA : Jump if Above / CMP로 두 값을 비교하여 Op1(왼쪽) 크면 Jump  /  ZF = 0  and  CF = 0

- JB : Jump if Below / CMP로 두 값을 비교하여 Op2(오른쪽) 크면 Jump  /  CF = 1

- JE : Jump if Equal / CMP로 두 값을 비교하여 Op1, Op2 값이 같으면 Jump  /  ZF = 1

- JZ : Jump if Zero / 결과값이 0이면 Jump / ZF = 1

- JNZ : Jump if not Zero / 결과값이 0이 아니면 Jump / ZF = 0

 

Tip. CMP 이전에 수행하는 XOR EAX, EAX 명령어

XOR 명령어는 Overflow와 Carry 플래그를 항상 0으로 해제합니다.

또한 EAX는 서로다른 값일때만 1로 세팅되므로,

XOR EAX, EAX를 수행할 경우, 서로가 같은 값을 가지므로 0으로 초기화됩니다.

한마디로 CMP이전에 수행되는 해당 명령어는 청소도구라고 생각하면 되겠네요!

 

Tip. 함수에서 돌아온 이후 수행하는 TEST EAX, EAX 명령어

예를들어, memcmp 함수가 수행된 이후에 TEST EAX, EAX를 수행한다면 어떤 의미일까요?

TEST 명령어는 묵시적으로 두 피연산자의 대응되는 각 비트 쌍에 대해 AND 연산자를 수행하고,

결과에 따라서 플래그를 설정합니다. 또한 TEST 명령어는 연산자에 어떤 영향을 주지 않습니다.

하지만 이러한 글을 다 기억하는 것보다는, 자주 쓰이는 사례의 의미를 기억하는게 더 효율적이겠지요.

- CMP명령어는 두 OP가 동일한지를 판단하며

- TEST명령어는 두 OP가 모두 0인지 판단합니다.

즉 위에서 예로든 memcmp 함수가 시행된 이후에 EAX값에 리턴값이 설정되어 있을것이고

TEST명령으로 해당 값이 0인지 확인하는데 사용됩니다.

즉, memcmp로 비교한 문자열이 동일한가? 라는것을 TEST 명령어로 체크하는겁니다.

--------------------------------------------------------------------------------------------------------------------------------------------------

posted by Red_Message

안녕하세요. Message입니다.

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

분석환경은 Windows 7 Ultimate 64x / Vmwre 12.1.0 build 입니다.

 

#1 : http://redscreen.tistory.com/66

#2 : http://redscreen.tistory.com/67

#3 : http://redscreen.tistory.com/68

#4 : http://redscreen.tistory.com/71

 

 

------------------------------------------------------------------------------------------------------------------------------------------

0. 준비

------------------------------------------------------------------------------------------------------------------------------------------

OllyDbg쓰다가 IDA쓰다가 이클립스로 개발하다가...보면 가장 혼동되는게 단축키입니다.

원래는 그때마다 검색해서 다시 감잡은 다음에 작업에 들어갔는데,

이참에 IDA에서 자주 쓰는 단축키만 정리하겠습니다.

 

일반

---------------------------------------------------------

- TextView와 Graph 화면전환 : SPACE 

- Strings Window : Shitft+F12

- 함수이동 : Ctrl+p 

- 이름검색 : Ctrl+L

- XREF 검색 : Ctrl+X 

- 주소이동 : g 

- 전단계 이동 : ESC

- 코드수정 : Alt+F2

- Text 검색 : Alt+t

- Quick View : Ctrl+1 

---------------------------------------------------------

 

디버그

--------------------------------

- BreakPoint : F2

Debugging Start : F9

- Debugging Exit : Ctrl+F2

- Step Into : F7

- Step Over : F8

--------------------------------

 

그래프모드 화살표 색상

---------------------------

------▶  False

------  True

------  무조건 Jump

---------------------------

 

------------------------------------------------------------------------------------------------------------------------------------------

1. DllMain의 주소는 무엇인가?

------------------------------------------------------------------------------------------------------------------------------------------

Function Name Window에서 DllMain을 찾습니다.

처음에는 DllEntryPoint로 착각했지만, DllMain이 따로 있었습니다.

둘의 차이점을 검색해보았으나, 명확하게 딱 이거다 라고 되어 있는걸 못찾았습니다.

스페이스키를 누르고 그래프를 살펴보았더니 DllEntryPoint가 먼저 호출되고 난 이후에

자신이 받은 인자값을 그대로 넣어주면서 DllMain을 호출하더군요.

답 : text 섹션 / 0x1000D02E

 

Tip. main에 관하여

RedAlert 에서 배포된 PE구조 문서를 보니

일반적으로 EntryPoint는 main, wmain, WinMain, wWinMain 으로 착각하기 쉽지만 (처음보는 함수도 많네요)

진정한 main은 CRT main이라고 합니다. CRT main은 C/C++ run-time startup 코드라고 불리는 함수가 따로 존재하는데,

이는 Linker에 의해 실행파일이 생성될 때 합쳐치며, main 함수도 CRT main에 의해서 호출되는 함수입니다.

CTR main은 Command-Line argument와 환경변수를 채우고,

heap 초기화, 전역변수 객체 생성자 호출, 전역변수 초기화 등을 수행합니다.

종류는 mainCRTStartup, wmainCRTStartup, WinMainCRTStartup wWinMainCRTStartup 등등..

이부분은 따로 숙지할 필요가 있겠네요.

 

 

------------------------------------------------------------------------------------------------------------------------------------------

2. Imports 윈도우를 이용해 gethostbyname을 탐색해보자. 임포트 위치는 어디인가?

------------------------------------------------------------------------------------------------------------------------------------------

Import Window에서 getbyhostname을 찾습니다.

윈도우에 포커스를 두고, gethostbyname을 타자치면 검색 기능이 활성화되어 쉽게 찾을 수 있습니다.

gethostbyname을 더블클릭하면 디스어셈블리창으로 이동되며, 주소값을 알아낼 수 있습니다.

답 : idata 섹션 / 0x100163CC

 

------------------------------------------------------------------------------------------------------------------------------------------

3. gethostbyname 함수는 몇번 호출되는기?

------------------------------------------------------------------------------------------------------------------------------------------

디스어셈블리창에서 Ctrl+X 를 입력하면 xref로 표기되는 상호참조 리스트 윈도우가 호출됩니다.

type은 호출(p)읽기(r)로 표시됩니다.

sub_10001074, sub_10001365, sub_10001656, sub_1000208F, sub_10002CCE 등 5개의

서로다른 함수에서 9번 호출됨을 알 수 있습니다.

답 : 5개의 함수에서 9번 호출

 

 

------------------------------------------------------------------------------------------------------------------------------------------

4. 0x10001757에 위치한 gethostbyname 호출을 보면 어떤 DNS 요청이 이뤄지는지 알 수 있는가?

------------------------------------------------------------------------------------------------------------------------------------------

.gethostbyname 함수는 도메인이름ex) www.daum.net 하나를 파라미터로 받는 함수입니다

상호참조 리스트에서 P type의 메소드를 클릭하여 확인하면

EAX 레지스터를 이용하여 도메인 네임 인자를 받는 어셈블리코드를 볼 수 있습니다.

 

off_10019040 주소를 더블클릭하거나 G 기능을 이용하여 주소로 점프하면

아래와 같이 "[This is RDO]pics.practicalmalware...(생략)" 소스를 발견할 수 있습니다.

 

EAX 레지스터에 0Dh 주소값을 더하는 이유는

문자열의 [This is RDO] 값을 제외하고 "pics..." 부분을 포인터로 얻기 위함입니다. 

답 : pics.practicalmalwareanalysis.com

 

 

------------------------------------------------------------------------------------------------------------------------------------------

5. 0x10001656 서브루틴에서 IDA Pro는 지역변수 몇개를 인지하고 있는가?

6. 0x10001656 서브루틴에서 IDA Pro는 파라미터 몇개를 인지하고 있는가?

------------------------------------------------------------------------------------------------------------------------------------------

스페이스바를 이용하여 그래프모드로 전환후 0x10001656으로 가거나

G단축키를 이용하여 0x10001656으로 이동하면

아래와 같은 그림에서 지역변수와 파라미터의 개수를 확인할 수 있습니다.

답 : 지역변수 23개, 파라미터 1개 (arg_0= dword ptr 4)

 

 

 

posted by Red_Message

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

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

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

 

1. 파일을 실행하였을 때 어떤 일이 발생했는가?

 

1) 기본 분석

파일을 실행하기 앞서, 기본적인 분석을 수행합니다.

패킹여부, 문자열 추출, DLL 리스트 등을 확인하며 특이사항을 체크합니다.

- 문자열추출

Strings 툴을 이용하여 문자열을 추출합니다.

 

이중에 유심히 봐야할 문자열은 아래와 같습니

- 도메인명 : http://www.practical...(중략)..analysis.com

- 레지스트리 위치 : SOFTWARE\Microsoft\XPS

- 문자열 : DOWNLOAD, UPLOAD

- 커맨드라인 파라미터 의심 문자열 : -cc, -re, -in

 

- DLL 확인

DWalker로 어떤 함수를 사용하는지 확인합니다.

KERNEL32.DLL의 경우, 너무 많은 함수를 참조하기 때문에 한눈에 들어오지 않지만

ADVAPI32.DLL은 서비스 관련 함수와 레지스트리 관련 함수들이 눈에 띄고,

SHELL32.DLL에서 ShellExecuteA 함수가 확 들어옵니다.

나중에 상세 분석을 하기 위해, 해당 내용들은 기억해둡니다.

 

 

 

2) 파일실행

파일을 실행하면 특정 프로세스(conime.exe)를 실행 시킨 후, 스스로 삭제됩니다.

(보통 conime.exe만 나타났지만..여러번의 시도 끝에 Lab03-04.exe와 동시에 나타난 순간을 캡쳐했습니다)

 

어떤 원리로 삭제되는지 알아보기 위해 ProcMon을 실행시킨 뒤, 프로세스 이름으로 필터를 설정합니다.

하지만 필터를 설정했음에도 불구하고, 너무나 많은 이벤트가 발생하는 것을 볼 수 있습니다.

따라서 추가적인 필터가 필요합니다. (이때 .exe를 빠뜨리면 안됩니다)

 

아래와 같이 Operation에 Process Create 를 필터로 추가 설정하였습니다.

그럼 아래와 같이 이벤트가 1개로 줄어든 것을 볼 수 있습니다.

 

탐지된 이벤트를 더블클릭하여 확인해 보면

아래와 같이 cmd를 이용한 del 명령으로 스스로를 삭제하는 커맨트를 발견할 수 있습니다.

 

2. 동적 분석 시 장애물이 무엇인가?, 이 파일을 실행시키는 다른 방법이 있는가?

해당 악성코드가 스스로 삭제되는점을 미루어 보아,

분석을 위한 도구 또는 컴포넌트가 필요한 것 같습니다.

해당 내용은 9장에서 다룬다고 하니, 해당 내용을 공부하고 돌아와야 겠군요!

posted by Red_Message

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

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

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

 

1. Process Explorer로 이 악성코드를 모니터링했을 때 무엇을 알아냈는가?

분석할 파일은 Lab03-03.exe 입니다.

Process Explorer를 실행하고, 해당 실습파일을 실행시키면

아래와 같이 Lab03-03.exe이 실행되고, 서브프로세스인 svchost.exe가 같이 실행되는것을 볼 수 있습니다. (초록색) 

하지만 1~2초 정도 시간이 지나면, 아래와 같이 서브프로세스인 svchost.exe만 고아 프로세스로 동작하는 것을 볼 수 있습니다.

에서는 svchost.exe가 고아 프로세스라는 사실이 매우 일반적이지 않으며, 아주 의심스럽다고 표현합니다.

(아마 이런 부분은 많은 경험을 쌓아야 알 수 있겠죠...ㅜㅜ...)

svchost.exe의 경우, 바로 전 문제인 3-2 문제에서 특정 DLL 파일을 실행시키기 위한 수단으로 사용되었습니다.

 

2. 실시간 메모리 변조를 확인할 수 있는가?

Process Explorer에서 svchost.exe의 속성 -> Strings 탭으로 이동하면

디스크와(Image) 메모리(Memory)에 있는 실행이미지를 볼 수 있습니다.

Image와 Memory를 반복하여 누르면, 이미지가 상당 부분 일치하지 않음을 알 수 있습니다.

 

 

3. 악성코드임을 의미하는 호스트 기반 표시자는 무엇인가?

위 스크린샷에서 몇가지 특이한 문자열을 발견할 수 있는데,

practicalmalwareanalysis.log나 [ENTER]와 같은 문자열은 svchost에서 일반적으로 발견되지 않습니다.

아래에서 나오겠지만, 사용자가 입력한 엔터값이나 쉬프트값 등을

악성코드 제작자가 쉽게 알아보기 위해 '[ENTER]'와 같은 문자열로 대체하여 기록하기 위해 사용합니다.

(이번 경험을 통해서, 나중에 저런 문자열을 보면 키로깅 행위를 먼저 의심해 볼 수 있겠습니다.)

실제 키로깅 행위를 하는지 Process Monitor 툴을 이용하여 확인해보겠습니다.

 

1) ProcMon 필터설정

Process Explorer에서 생성되는 PID를 확인한 후, 아래와 같이 필터를 설정합니다.

 

2) ProcMon 이벤트값 확인

이후 메모장을 열어 아무 글자나 타이핑 한 뒤, 결과를 살펴보면

practicalmalwareanalysis.log 파일에서 CreateFile, WriteFile 등의 이벤트가 발생하는것을 볼 수 있다.

 

3) DWalker DLL 확인

DWalker를 이용하여 어떤 함수를 사용하는지 확인해보았습니다.

KERNEL32 DLL의 많은 함수를 사용하는것을 확인할 수 있었고,

CreateFile(파일생성), WriteProcessMemory(원격프로세스 데이터 작성, DLL인젝션에 사용 가능) 등이 보입니다.

 

4. 이 프로그램의 목적은 무엇인가?

ProcMon에서 발견한 practicalmalwareanalysis.log 파일을 편집기로 열어보면,

사용자 입력값이 프로그램 이름과 함께 기록되어 있음을 확인할 수 있습니다.

따라서, svchost.exe로 가장한 키로거로 판단할 수 있습니다.

 

posted by Red_Message

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

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

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

 

1. 악성코드가 설치된 방법

분석할 파일은 Lab03-02.dll 입니다. 실행파일이 아닌 DLL이 어떻게 설치되었을까요?

일단 주어진 유일한 파일이 DLL파일이니, 분석해보면 답이 나올 것 같습니다.

DWalker로 어떤 Export 함수가 있는지 확인해볼까요.

우리가 알아내야 하는 [어떻게 설치가 되었는가]에 대한 실마리가 보입니다.

바로 Install과 installA 두개의 함수인데요(대소문자주의),

installA 함수를 살펴보니 별다른 기능은 없이 Install 함수를 호출하는군요.(아래 스샷 참고)

따라서 CMD창에서 아래와같이 입력해주면 설치가 되는데요(Rundll32.exe를 이용하여 설치하는 방법은 교재에 나와있습니다.)

대소문자 주의해주세요.(installA 맨앞에 i가 소문자임)

아, 그리고 실행하기 전에 RegShot, ProcMon, SystemExplorer, WinAlysis와 같은 스냅샷 기능의 툴을 실행시켜줍니다.

이렇게해서 악성코드가 설치가 되었습니다. 다음으로 슝슝~

 

2 . 설치후 실행방법과 동작 프로세스

어떻게 실행이 되는지 알아봅시다. 설치전에 시켜놓은 스냅샷을 비교해볼까요?

아래 스샷은 SystemExplorer를 이용하여 스냅샷을 비교한 내용인데요,

스냅샷을 비교해보니 HKLM 하이브(루트키) 내부의 Service 레지스트리 키값 아래로 

폴더모양의 IPRIP 레지스트리 키(Key)가 새로 생성되었고

IPRIP 키 안에 10개의 값들이 추가된것을 확인할 수 있었습니다.

아마도 실행시키면 레지스트리 서비스(IPRIP) 내부에 본인을 설치하는 악성코드인 모양입니다.

그런데 왜 악성코드는 레지스트리 서비스에 본인을 설치했을까요?

그것에 대한 힌트는 ImagePath 값에 있는 "svchost.exe -k netsvcs" 부분입니다.(아래 svchost.exe 세부내용 참조)

 

[svchost.exe에 대하여...]

우리가 흔히 보았던 svchost.exe 프로그램은 윈도우즈 서비스를 백그라운드로 구동하는 프로세스입니다.

원래 윈도우즈 서비스는  WinLogon.exe가 호출하는 Services.exe(SCM:서비스제어관리자)에 의해 관리되지만

예외적으로 DLL 기반의 서비스는 svchost.exe에 의해 관리됩니다.

(우리가 실습중인 악성코드는 DLL 기반이기 때문에 svchost에 의해 실행되겠네요 ^^) 

svchost.exe는 윈도우 부팅시 윈도우 레지스트리의 Service항목을 검색하여 목록을 만듭니다.

HKLM\System\CurrentControlSet\Services 내부에 등록된 서비스에서 Parameters 키 내부에 ServiceDLL값이

들어 있는 서비스들을 묶어 실행시킬 목록을 형성합니다. 이해가 안간다면 우리가 분석중인 악성코드를 통해 이해해봅시다.

아니나 다를까, IPRIP 서비스이름 아래 Parameters 키가 뙇!! 그 안에 ServiceDll이 뙇!!

따라서 이 악성코드는 이제 svchost.exe가 자동으로 실행시켜주는 서비스 기반의 악성코드로 판별이 되었습니다.

재부팅후 ProcessExplorer 메뉴탭에서 [Find] - [Find Handle or DLL] 기능을 이용하여 Lab03-02.dll을 검색하면

svchost.exe가 로드하여 사용하고 있음을 볼 수 있습니다.

(교재에서는 재부팅을 하지 않기 위해 CMD 에서 서비스를 구동할 수 있는 net 명령어로 실행시킵니다 : net start IPRIP)

 

[조금더..분석 - 정적분석]

우리가 분석중인 악성코드의 경우 서비스에 등록이 되어 시스템으로부터 호출이 되는 형식으로 분석이 되었는데요,

그렇다면 우리가 설치하기 위해 사용했던 InstallA 함수 이외에, 운영체제가 접근하는 콜백함수가 있어야합니다.

( *콜백함수 : 호출되는 함수를 알려주어 특정 이벤트 발생시 모듈이나 OS 등에서 함수를 호출할 수 있도록 하는 방법)

DLL을 이용하여 서비스에 등록을 하기 위해서는 main()에서 서비스 관리를 위한 ServiceMain()을 콜백으로 등록해야합니다.

우리 악성코드는 어떻게 등록되어 있을까요? 아래 스샷을 참조해봅시다.

 

 

 

3. 호스트기반 표시자 및 정보를 수집하는 ProcMon을 사용하기 위해 사용한 필터

악성코드를 실행하기 전 ProcMon을 실행시켜 놓았다면 ProcessExplorer에서 수집한 PID를 이용하여

필터를 적용할 수 있습니다.  위에서는 재부팅을 통하여 svchost가 악성코드를 실행시키는것을 관찰했지만

ProcMon을 통한 관찰을 위해 교재에서 사용한 CMD - net 명령어를 이용하겠습니다.

실행이 되면 아래와 같이 우리가 레지스트리 편집기에서 발견하였던 익숙한 텍스트가 우리를 반겨줍니다 (ㅋㅋ)

이후에 ProcessExplorer를 이용하여 알아낸 PID를 ProcMon 필터에 적용해줍니다.(PID는 시스템 or 재부팅시 다를 수 있음.)

 

5. 악성코드에서 유용한 네트워크 기반 시그니처

ApateDNS를 이용하면 아래와 같이 악성코드의 DNS 요청을 확인할 수 있습니다.

또한 NetCat을 이용하여 아래와 같은 네트워크 시그니처를 관찰할 수 있습니다.

 

posted by Red_Message

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

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

(책에서도 1-4 다음에 바로 3-1로 넘어갑니다)

분석환경은 동일하게  Windows XP / Vmware 9.0.3 build 이며,

사용되는 툴은 Dependency Walker, Strings, ProcMon, Process Explore, ApateDNS, NetCat 입니다.

 

1. 악성코드의 임포트 함수와 문자열 확인하기

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

근데..임포트 함수라고는 딸랑 ExitProcess 하나뿐이군요. 정상적인 기능을 수행하는 프로그램이라면 이런 경우는 거의 없지요.

아마 패킹이 되어 있는것 같습니다.

PEID로 확인해본 결과 PEncrypt 3.1 Final -> junkcode 로 패킹이 되어있네요.

패킹을 해제하기 전까지는 정적분석이 안될것 같습니다.

마지막으로 Strings를 이용하여 문자열을 확인해봅시다.

......(중략).....

패킹이 되어있기 때문에 문자열에서 많은 기대를 할 순 없지만, 마지막 부분에서

WinVMX32, VideoDriver, vmx32to64.exe, 레지스트리 위치, 도메인명 등의 주요 단서들이 발견되었습니다.

동적분석 & 정적분석을 통해 이 단서들이 어떻게 사용되는지 알아봅시다.

 

2. 악성코드임을 의미하는 호스트 기반 표시자 확인하기

악성코드 실행전 동적 분석을 위한 툴을 실행시킵니다. : ProcMon, Process Explore

 

[Process Explorer]

악성코드를 실행시키고 Process Explorer로 체크합니다.

Lab03-01를 클릭하고 메뉴탭에서 [View] - [Lower Pane View] - [Handles]를 선택합니다.

이 뷰를 통하여 해당 악성코드가 뮤텍스(Mutant)를 생성하는 것을 알 수 있습니다.

숙련된 리버서 혹은 악성코드 분석가라면 뮤텍스를 생성을 바로 알아차리겠지만 공부하는 입장에서는

별다른게 없네~ 하고 그냥 넘어갈 확률이 높겠네요 ^^; (ㅜㅜ)

다음으로  [View] - [Lower Pane View] - [DLLs]를 선택합니다.

지난 실습에서 보았던 ws2_32.dll과 같은 네트워크에 관련된 DLL이 보입니다만...

DLL이 한두개도 아니고...매의 눈으로 관찰해야 보이겠녜요.

아마 경험이 쌓이면 익숙해지겠죠?

 

[ProcMon]

ProcMon을 실행시킨 후 악성코드를 실행시키면 Lab03-01.exe의 행동이 기록됩니다.

하지만 다른 프로세스들의 결과와 함께 나올 뿐만 아니라 Lab03-01.exe의 데이터만 해도 너무 많은 리스트가 나와

눈을 어지럽힙니다. 따라서 우리가 원하는 부분만을 보려면 FIlter 기능을 이용해야합니다.

메뉴탭에서 [Filter] - [Filter]에 들어가서 아래와 같이 설정합니다.

(다른 필터들을 전부 [Remove] 시켰더니 아예 결과값이 안나오더군요, 기존 필터는 그대로 유지하고, 추가 필터 3개만 [Add] 합니다.)

- Process Name : Lab03-01.exe

- Operation : WriteFIle

- Operation : RegSetValue

이렇게 필터를 만든 후 [Apply]를 누르면 총 10개의 결과값을 볼 수 있습니다.

 그중 주요 항목은 아래와 같습니다.

- WriteFile : C:\WINDOWS\system32\vmx32to64.exe (악성코드의 복사)

- RegSetValue : HKLM\SOFT\Microsoft\Windows\CurrentVersion\Run\VideoDriver (윈도우 부팅시 자동실행)

 

3. 악성코드를 인식할 수 있는 네트워크 기반의 시그니처 확인하기

 악성코드 실행전 동적 분석을 위한 툴을 실행시킵니다. : ApateDNS, NetCat

 

[ApateDNS]

ApateDNS를 실행시킨 후 [Start Server]를 클릭하면 악성코드가 주기적으로

www.prac..(중략)..anlysis.com 으로 DNS 요청을 하는것을 볼 수 있습니다.

(혹시 Vmware XP에서 초기화 오류가 발생하는경우 MicroSoft Frame Work가 설치 안됐을 가능성이 높습니다.)

 

[NetCat]

ApteDNS에서 DNS Reply IP를 이용하면 NetCat을 이용하여 리다이렉션된 내용을 볼 수 있습니다.

(요거 설정 안된줄도 모르고 한참을...ㅠ)

리스닝모드로(-l) 포트443번(-p)을 모니터링하게되면 전송되는 256바이트의 무작위 데이터를 볼 수 있습니다.

 

 

 

posted by Red_Message

안녕하세요~ 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에서 확인하세요)

OpenProcessToken

특정 프로세스의 액세스 토큰을 가져오는 API입니다. 성공하게 되면 넣어준 인자값안에 해당 프로세스의

액세스 토큰 핸들값을 넣어줍니다. 이 토큰을 활용하여 특정행위에 대한 권한 획득이 가능합니다.

(여기서 access token은 로그인 계정에 따라 달라지겠죠? Admin, Guest 등..)

LookupPrivilegeValueA

액세스 토큰의 권한 리스트에 특정 권한이 있는지 검색해주는 API입니다.

예를들어 시스템을 무한 재부팅 시키는 악성코드라면 시스템종료를 시킬 수 있는 권한을 가져야겠죠.

아마 악성코드가 필요한 권한이 있는데, 그 권한이 해당 액세스 토큰에 있는지

알아보는데 사용될거라 예상됩니다.

AdjustTokenPrivileges

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

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

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

 

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

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

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

- GetWindowsDirectoryA

- WinExec

- GeTempPathA

- URLDownloadToFileA

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

- systemwupdmgrd.exe

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

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

 

[권한획득]

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

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

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

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

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

hProcess

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

DesiredAccess

원하는 접근 유형입니다. TOKEN_QUERYTOKEN_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)라고 지칭합니다.

hModule : 리소스를 얻고자하는 모듈의 핸들입니다. 위에서 GetModuleHandle 함수를 호출한 이유가 되겠지요

lpName : 리소스의 이름을 포함하는 NULL로 끝나는 문자열 포인터입니다.

lpType : 리소스의 타입을 의미하는 문자열 포인터입니다.

 

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 였습니다. 모두 즐거운 하루 되세요!

 

posted by Red_Message

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

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

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

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

 

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

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

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

   

   

 

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

    늘 그래왔듯, PEVIEW로 한번 구조를 살펴보겠습니다.

    역시 패킹이 되어 있군요! (사실 안되있으면 문제의 의미가 없겠습니다만...)

    Virtual Size가 3000인데 반해, Size of Raw Data(실제크기)는 0입니다. 패킹의 전형적인 흔적입니다.

    또한 섹션의 명칭 또한 생략되어 있습니다.(text, data, rdata 등..)

   

    DWalker로 임포트 테이블을 살펴보겠습니다.

    LoadLibaryA, GetProcAddress 총 2개의 API가 보입니다.

   역시 패킹의 전형적인 흔적으로서, 악성코드가 임포트하는 DLL을 로드하기 위해 LoadLibrary를 사용하고

    DLL 내부의 함수를 얻기 위해 GetProcAddress를 사용할것으로 예상됩니다.

   

 

    이제 어떤 패킹이 되어있는지 알기위해 PEID를 통해 알아보겠습니다.

    지금까지 보아왔던 UPX가 아니라 FSG1.0이라는 생소한 패킹이네요.

   

    패킹후에 더 자세한 분석이 가능할 것 같습니다. 이 실습파일에 대한 패킹은 18장에서 다루게 됩니다.

    그때 까지 잠시 미뤄두겠습니다.

 

posted by Red_Message

안녕하세요~ 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은 살펴볼 필요가 있겠습니다.

(물론 실습 1-1에서 KERNERL32.DLL의 CreateFileA, FindFirstFIleA, FindNextFileA 함수들이 악성행위를 하는데

사용됐으니 모든 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....) 접속을 하는군요.

 

 

posted by Red_Message

<실전 악성코드와 멀웨어 분석> 책의 실습 문제 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초 차이로 컴파일 되었습니다.

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

   DLL파일은 스스로 실행될 수 없기 때문에 이를 뒷받침 해주는 근거가 되겠습니다. 

    


  

  

3.  악성코드의 패킹 및 난독화 여부 확인

     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 함수를 포함하고 있습니다.

    WS2_32.DLL의 기능은 윈도우 소켓을 구동하는데 필요한 DLL 파일입니다. 윈도우에 익스플로러가 내장되면서

   만들어졌다고 합니다. 네트워크 컴퓨팅을 하기 위한 DLL 이므로 이 DLL을 사용하여 네트워크에 연결하거나

   정보를 외부로 유출할 가능성이 있습니다.

   DWalker의 우측 상단은 임포트 함수를 우리에게 보여줍니다. 하지만 어떤 함수를 임포트

   하는지 나타나지 않네요. (아래 스샷 참고) 일단 패스해야겠습니다.

 

 

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)와 통신하는 백도어로 추정됩니다.

 

 

posted by Red_Message