Red_Message :: 실전 악성코드와 멀웨어 분석 실습 1-3 분석

2014. 1. 10. 18:14 :: 문제풀이/Pracical Malware

안녕하세요~ 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장에서 다루게 됩니다.

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

 

':: 문제풀이 > Pracical Malware' 카테고리의 다른 글

Red_Message :: 실전 악성코드와 멀웨어 분석 실습 3-2 분석  (0) 2014.02.05
Red_Message :: 실전 악성코드와 멀웨어 분석 실습 3-1 분석  (0) 2014.02.02
Red_Message :: 실전 악성코드와 멀웨어 분석 실습 1-4 분석  (0) 2014.01.14
Red_Message :: 실전 악성코드와 멀웨어 분석 실습 1-2 분석  (0) 2014.01.08
Red_Message :: 실전 악성코드와 멀웨어 분석 실습 1-1 분석  (0) 2014.01.07
posted by Red_Message

[Red_Seek] 엔디언 표기법

2014. 1. 9. 17:12 :: 리버싱

안녕하세요.

오늘은 컴퓨터에서 메모리에 데이터를 저장하는 방식을 의미하는

바이트 오더링(Byte-Ordering)의 엔디언 표기법에 대해서 공부하겠습니다.

 

크게 두가지 리틀 엔디언(Little Endian)과 빅 엔디언(Big Endian)이 있습니다.

 

 

1. 바이트 오더링

 

  바이트 오더링이란 데이터를 저장하는 방식입니다. 애플리케이션의 디버깅을 할 때 알아두어야 하는 기본 개념중 하나입니다. 이 안에 리틀 엔디언, 빅 엔디언 두가지 방식이 있습니다.

 

예제 코드입니다.

 

총 4개의 서로 크기가 다른 자료형이 있습니다.

아래의 표는 위에서 말한 두가지 엔디언 방식에 따라서 같은 데이터를 각각 어떻게 저장했는지 나타내는 표입니다.

TYPE

Name 

SIZE 

빅 엔디언 스타일 

리틀 엔디언 스타일 

BYTE 

b 

1 

[12] 

[12] 

WORD 

w 

2 

[12][34] 

[34][12] 

DWORD 

dw 

4 

[12][34][56][78] 

[78][56][34][12] 

char [] 

str 

6 

[61][62][63][64][65][00] 

 [61][62][63][64][65][00] 

(참고 : ASCII 문자 'a'는 0x61, 'e'는 0x65와 같습니다. 그리고 문자열 마지막은 NULL로 끝납니다. 0x는 16진수의 표시입니다.)

 

위에 예제 코드와 표에 WORD, DWORD 타입으로 보시면 빅 엔디언 스타일은 앞에서부터 순차적으로 저장을 합니다.

하지만 리틀 엔디언 스타일은 역순으로 저장을 합니다.

 

그리고 역순으로 저장하는 리틀 엔디언도 바이트 자체는 정상적인 순서로 저장이 됩니다. 2byte, 4byte의 자료형과 같이 멀티바이트인 경우 각 바이트가 역순으로 저장되는 것입니다.

(멀티바이트 : a,b,c(1byte)와 같이 아스키코드로만 문자를 다 표현할 수 없어 아스키코드에 다른 문자(2byte)를 포함한 문자 집합)

 

또한 str 문자열은 엔디언 형식에 상관없이 동일하게 저장됩니다.

그 이유는 문자열은 결국 캐릭터(char)배열이기 때문에 각 바이트를 하나씩 연속해서 저장한다고 생각해보면 리틀 엔디언에서도 순차적으로 저장이 되기 때문에 동일합니다.

 

 

2. 빅 엔디언

 

  데이터를 순차적으로 저장하는 방식입니다. 빅 엔디언의 장점은 사람이 보기에 직관적이다. 그리고 빅 엔디언은 대형 UNIX 서버에 사용되는 RISC 계열의 CPU에서 많이 사용됩니다. 또한 네트워크 프로토콜에 빅 엔디언이 사용됩니다. 이는 x86 계열의 응용 프로그램 개발자와 리버서에게 중요한 의미를 가지고 있습니다.이유는 애플리케이션 개발에 사용된 데이터를 네트워크로 송수신할 때 엔디언 타입을 변경해야 하기 때문입니다.

 

 

3. 리틀 엔디언

 

  데이터를 역순으로 저장하는 방식입니다. Intel x86 CPU에서 리틀 엔디언 방식을 사용합니다. 따라서 저희 같은 windows 계열 리버서들은 리틀 엔디언에 대해서 잘 알아야 합니다. 장점으로는 산술 연산과 데이터의 타입이 확장/축소될 때 더 효율적입니다.

 

 

4. 디버거 프로그램(OllyDbg)에서 리틀 엔디언 확인

 

예제 코드

 

위에 예제 코드를 Visual C++에서 빌드하여 LittleEndian.exe 실행 파일을 만들어 OllyDbg로 디버깅 후 변수들이 저장된 모습의 사진입니다. 

 

바로 위 사진에서 보시면 더 위쪽에 빅 엔디언과 리틀 엔디언 방식을 비교해둔 표 처럼 리틀 엔디언 방식처럼 역순으로 저장된 것을 확인할 수 있습니다.

 

 

 

위에서 말씀 드렸듯이 windows 계열에서 리버싱을 하는 저희 같은 리버서들은 리틀 엔디언을 잘 알아야 합니다. windows 기반이 모두 리틀 엔디언 방식으로 저장 되어 있으니까요.

 

 

참고서적 : 리버싱 핵심 원리 / 저자 : 이승원

 

':: 리버싱' 카테고리의 다른 글

Red_Seek :: 스택 프레임  (0) 2014.01.29
[Red_Seek] abex' crackme #1 (크랙미 #1)  (0) 2014.01.23
[Red_Seek] 스택  (0) 2014.01.22
[Red_Seek] IA-32 Register  (0) 2014.01.14
[Red_Seek] 리버싱(Reversing) 이란?  (0) 2014.01.08
posted by Red_Seek

[Red_Seek] 리버싱(Reversing) 이란?

2014. 1. 8. 17:57 :: 리버싱

보안과 프로그램을 공부하면서

처음으로 공부하기 시작한 리버싱.

기초 및 이론은 "이승원님 / 리버싱 핵심 원리" 책을 참고하여 작성 하겠습니다.

저 역시 "리버싱 핵심 원리" 책으로 공부중입니다.

 

그럼 리버싱이란 무엇일까요?

 

 

1. 리버스 엔지니어링(Reverse Engineering)

 

  일반적인 의미에서는 '역공학'이라고 하며 어느 특정 물건, 장치 등이 있으면 그것에 대한 구조, 기능, 동작 등을 역으로 따라가며 분석하고 그 원리를 이해하며 부족한 부분을 보완하며 새로운 기능 등을 추가하는 작업입니다.

 

 

2. 리버스 코드 엔지니어링(Reverse Code Engineering)

 

  RCE(Reverse Code Engineering)는 소프트웨어 분야의 리버스 엔지니어링 이라고 생각하시면 될것같습니다. 제가 공부하는 것 역시 소프트웨어 분야의 작업이기 때문에 위에서 말한 리버싱(Reversing)이 여기에 해당하겠습니다.

 

 

#리버싱# : 소프트웨어 분야에서 해당 프로그램의 구조, 기능, 동작 등의 원리를 역으로 따라가며 이해하고 분석하여 부족한 부분이 있거나 추가 되었으면 하는 새로운 기능 등을 추가하는 전체적 행위가 되겠습니다.

 

 

3. 리버싱 방법

 

  - 정적분석 : 파일의 겉모습을 관찰하여 분석하는 방법입니다. 파일을 실행하지 않고 파일의 종류(exe,dll, doc, zip 등), 크기, 헤더정보, 실행 압축 여부, 등록 정보, 디지털 인증서 등의 내용을 확인하는 것입니다. 또한 디스어셈블러를 이용해서 내부코드와 그 구조를 확인하는 방법입니다.

 

  - 동적방법 : 파일을 직접 실행시켜서 그 행위를 분석하고, 디버깅을 통하여 코드의 흐름과 메모리의 상태 등을 자세히 살펴보는 방법입니다. 레지스트리, 네트워크 등을 관찰하면서 프로그램의 행위를 분석하고 디버거를 이용하여 프로그램 내부 구조와 동작 원리를 분석하기도 합니다.(디버깅은 리버싱에서 비중이 큰 작업이지만 리버싱의 하위 개념입니다.)

 

 

4. Source Code, Hex Code, Assembly Code

  리버싱에서는 보통 실행파일을 취급합니다.

 

  - Source Code

    Visual C++에서 소스코드(HelloWorld.cpp)를 실행 시킨 사진입니다.

 

 

  - Hex Code

    위에 소스코드에서 Visual C++에서 빌드하여 생성된 실행 파일은 컴퓨터가 이해할 수 있는 2진수 형식으로 되어 있는데 그것을 16진수인 Hex Code로 변환된 사진입니다.

 

 

  - Assembly Code

    솔직하게 Hex Code역시 보기 쉬운 형태는 아닙니다. 따라서 사람이 이해하기 쉬운 어셈블리코드 형태로 보기 위해 디버거 프로그램(OllyDbg)으로 위 소스코드를 빌드해서 생성한 실행파일 HelloWorld.exe를 디버거한 사진입니다.

 

이렇게 어셈블리 코드를 가지고 해당 실행파일을 분석하게 됩니다.

 

 

 

 

 

저도 보안공부와 프로그램공부를 하면서 역공학, 리버싱이란 단어만 들었지 그것이 무엇을 하는지 정확히 모르고 있었습니다.

이제부터 자세히 공부해보록 하겠습니다.^^

 

 

 

 

참고서적 : 리버싱 핵심 원리 / 저자 : 이승원

':: 리버싱' 카테고리의 다른 글

Red_Seek :: 스택 프레임  (0) 2014.01.29
[Red_Seek] abex' crackme #1 (크랙미 #1)  (0) 2014.01.23
[Red_Seek] 스택  (0) 2014.01.22
[Red_Seek] IA-32 Register  (0) 2014.01.14
[Red_Seek] 엔디언 표기법  (0) 2014.01.09
posted by Red_Seek

Red_Message :: 실전 악성코드와 멀웨어 분석 실습 1-2 분석

2014. 1. 8. 17:41 :: 문제풀이/Pracical Malware

안녕하세요~ 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....) 접속을 하는군요.

 

 

':: 문제풀이 > Pracical Malware' 카테고리의 다른 글

Red_Message :: 실전 악성코드와 멀웨어 분석 실습 3-2 분석  (0) 2014.02.05
Red_Message :: 실전 악성코드와 멀웨어 분석 실습 3-1 분석  (0) 2014.02.02
Red_Message :: 실전 악성코드와 멀웨어 분석 실습 1-4 분석  (0) 2014.01.14
Red_Message :: 실전 악성코드와 멀웨어 분석 실습 1-3 분석  (0) 2014.01.10
Red_Message :: 실전 악성코드와 멀웨어 분석 실습 1-1 분석  (0) 2014.01.07
posted by Red_Message

Red_Message :: 실전 악성코드와 멀웨어 분석 실습 1-1 분석

2014. 1. 7. 14:35 :: 문제풀이/Pracical Malware

<실전 악성코드와 멀웨어 분석> 책의 실습 문제 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)와 통신하는 백도어로 추정됩니다.

 

 

':: 문제풀이 > Pracical Malware' 카테고리의 다른 글

Red_Message :: 실전 악성코드와 멀웨어 분석 실습 3-2 분석  (0) 2014.02.05
Red_Message :: 실전 악성코드와 멀웨어 분석 실습 3-1 분석  (0) 2014.02.02
Red_Message :: 실전 악성코드와 멀웨어 분석 실습 1-4 분석  (0) 2014.01.14
Red_Message :: 실전 악성코드와 멀웨어 분석 실습 1-3 분석  (0) 2014.01.10
Red_Message :: 실전 악성코드와 멀웨어 분석 실습 1-2 분석  (0) 2014.01.08
posted by Red_Message

티스토리툴바