개요

DB 생성

DB를 생성하기 위하여 두 가지 준비가 필요하다. 우선 Python을 통해 DB를 생성할 것이므로 Python을 설치해야 하며, 다른 준비물로는 Sysinternals의 Strgins가 필요하다. 아래의 링크를 통해 각 도구를 다운로드 하자.

[+] Python : https://www.python.org/downloads/

[+] Strigns : https://technet.microsoft.com/en-us/sysinternals/strings.aspx

프로그래밍을 해야 하지만, strings를 통해 어렵지 않을 것이다. 우선 여러 파일의 문자열을 넣어야 하므로 파일의 목록을 가지고 올 수 있는 부분을 먼저 제작해보자. 특정 폴더만을 지정할 경우 크게 두 가지 방법이 있는데, 하나는 os.listdir()을 통해 얻을 수가 있으며 다른 하나는 아래의 코드와 같이 지정된 디렉터리에 존재하는 하위 디렉터리까지 파일의 목록을 얻을 수가 있다.

위와 같이 파일의 목록을 얻은 다음 이를 아래의 Filelist 변수에 넣어주었다. 그리고 os.system 명령어를 통해 strings를 사용하여 하나의 파일씩 DB에 추가한다. 이렇게 지정된 모든 파일의 문자열이 DB에 존재하게 된다. 하지만 여기서 문제가 생긴다. 수많은 PE 파일들이 존재하기 때문에 공통적으로 포함되어 있는 문자열인 'MZ', 'PE', '. code', '. data' 등은 수 없이 중복되어 용량이 너무 커지게 된다. 따라서 모든 파일의 문자열을 추가한 다음, 이러한 중복 문자열을 제거하기 위한 코드를 제작하여야 한다. self.DB_Update()가 바로 그 내용으로 다음 그림에서 확인하자.

아래의 그림과 같이 'GenDB.tmp'라는 새로운 임시파일을 생성하여 기존의 'GenDB.db'의 내용을 0x2000000 씩 읽는다. 이렇게 읽은 문자열들을 배열로 놓기 위하여 split()를 사용하였으며, 이를 통해 arr이라는 배열(리스트)에 존재하게 된다. 파이썬에서 배열의 경우 자체적으로 아이템의 중복을 제거하기 위한 함수가 존재하는데 바로 set(arr)이다. 따라서 아래와 같이 arr=list(set(arr))을 통해 아이템의 중복을 제거한다. 중복이 제거된 문자열은 GenDB.tmp에 기록되고, 모든 바이트를 읽은 다음 GenDB.tmp를 GenDB.db로 이름을 변경한다.

위에서 0x2000000씩 읽는 이유는, buf = f.read()와 같이 DB의 내용을 한 번에 변수에 담으면 좋겠지만, DB는 말 그대로 데이터 베이스이기 때문에 수많은 파일의 문자열이 들어가게 될 경우 용량이 거대해진다. 따라서 이렇게 거대한 용량을 한 번에 읽으려 하면 파이썬은 "MemoryError"를 반환하게 되어 프로그램이 해당 데이터를 제대로 읽을 수 없게 된다. 그렇기에 이를 방지하기 위하여 지정된 바이트씩 읽는다. 

하지만 이 방법 또한 단점은 존재한다. 0x2000000씩 읽기 때문에, 0x2000000 만큼의 문자열에서만 중복되는 문자열이 제거된다. 즉, 0x000000에 'AAA"라는 문자열이 있고 0x2000010에도 'AAA'라는 문자열이 있을 경우 제거되지 않는다. 이러한 단점이 존재하지만 DB의 크기를 줄이는 것이 목적이기 때문에 몇 개는 남더라도 지우는 것이 훨씬 효과적이라 생각한다.

실습을 위하여 %SystemRoot%\System32\에 존재하는 3903개의 파일을 복사하였다. 이를 통해 DB를 생성하였으며, 최초 중복을 제거하기 전 파일의 크기는 약 400MB지만 중복을 제거한 뒤 DB의 크기는 약 135MB로 감소하였다. 이를 통해 중복제거가 완벽하지는 않지만 충분히 효과가 있다는 점을 알 수 있다.

DB 비교 & 패턴 생성

이제 약 3903개의 파일에 대하여 DB가 생성되었으니 한 번 성능을 테스트해보자. 대상으로 사용할 파일은 "Abex's Crackme01"을 UPX로 실행 압축한 파일이다. 따라서 DB에 존재하지 않다면 "UPX0", "UPX1"과 같은 내용들이 결과로 출력될 것이며 만약 DB에 UPX 관련 파일이 있을 경우 출력되지 않을 것이다. 우선 비교를 위한 코드는 다음과 같다.

이번에도 Strings.exe를 통해 문자열을 추출한 다음, 중복 문자열을 제거한다. 중복이 제거된 문자열을 배열의 형태를 통해 DB의 문자열 하나씩 비교한다. 이를 통해 DB에 일치하는 내용이 없는 문자열만 결과로 출력한다. 이제 이렇게 완성된 코드를 통해 파일을 비교해보자. 해당 결과는 다음과 같다.

abex's crackme01에서 볼 수 있는 몇 가지 문자열들이 결과로 출력되는 것을 확인할 수 있다. 대신 위에서 예상하였던 "UPX'와 관련된 문자열은 이미 DB에 존재하고 있기에 나타나지 않았다. 출력된 결과 중 몇 가지 문자열을 통해 Yara 규칙을 작성해보자.

아주 기초적으로 문자열 기반 규칙을 작성하였다. 그리고 해당 규칙을 적용하였을 때, 제대로 파일을 인식하는 것을 확인할 수 있었으며, 다른 3903개의 정상 파일에는 해당 시그니처가 부합되지 않다는 것 또한 확인할 수 있다.

직접 만들면서 부족한 프로그래밍임을 알 수 있었지만, 그래도 만들어보고 싶은 걸 초보적이 게나마 만들 수 있기에 공부하면서 재미있었다. 구글에 다른 훨씬 좋은 제너레이터가 존재하고 있으니, 그 코드들을 보며 다른 사람들은 어떻게 생각하면서 제작했는지 보는 것 또한 나쁘지 않을 것 같다. 아래는 부족하지만 내가 만든 위 프로그램의 코드이다.

1. Yara란

Yara는 문자열이나 바이너리 패턴을 기반으로 악성코드를 검색하며 이러한 악성코드를 분류할 수 있게 하는 도구이다. C와 Python과 같은 문법으로 Yara Rule을 작성하는 것으로 악성코드가 어떤 기능을 하는지, 어떠한 조건에 포함되는지를 쉽게 확인할 수 있으므로 많이 사용되고 있다. Yara는 설명, 이름 규칙, 문자열의 집합 그리고 Bool 식으로 규칙 로직을 결정한다. 또한, 단순히 문자열과 바이너리 패턴만을 이용해서 파일의 시그니처를 찾는 것뿐만 아니라, 특정 Entry Point 값을 지정하거나, File Offset, Virtual Memory Address를 제시하고 정규 표현식을 이용하여 효율적인 패턴 매칭이 가능하다.

1.1 Yara 설치

Yara는 리눅스, 맥, 윈도우 시스템 모두에서 사용할 수 있으며, 소스코드를 직접 컴파일하거나 Yara 실행파일을 직접 실행할 수 있고, Yara-Python 확장을 통해 Python을 통해서도 Yara를 사용할 수가 있다. 이러한 방법 중 Yara를 가장 많이 사용하는 리눅스와 윈도우에서 설치하는 방법에 대해 알아보자.

    Linux

Yara 사이트(https://plusvic.github.io/yara/)에서 Download Latest release를 통해 이동해 Source Code - tar.gz를 다운로드한다. 그 후 다음과 같은 과정을 통해 설치를 해주면 되는 것으로 첫 번째 라인에서 많은 항목을 설치하는 것 같지만, 해당 항목이 존재하지 않으면 설치 과정에 오류가 생길 수 있다.

리눅스에서 파이썬으로 사용하고자 할 경우 위에서 압축을 해제한 yara의 폴더에 존재하고 있는 yara-python 폴더에서 다음과 같은 명령어를 입력해주면 된다.

    Windows

윈도우의 경우도 마찬가지로 사이트에 접속한 뒤 "Windows binaries can be found 'here'"에서 바로 실행시킬 수 있는 yara나 Python을 이용하는 yara-python을 버전에 맞게 다운로드한다. yara.exe의 경우 바로 실행하여 사용할 수 있으며 yara-python의 경우 다운로드된 yara-pythonx.x.x.win32-pyx.x.exe를 실행시키면 자동으로 yara-python 설치 작업이 완료된다. yara-python이 설치되면 다음과 같은 방법을 통해 사용할 수 있다.

1.2 Usage

Yara는 사용자가 정의한 규칙에 따라 동작하며 이러한 규칙을 어떻게 만드느냐에 따라 Yara는 사용가치가 더욱 올라간다. 우선 규칙에 대한 기초적인 부분을 알아보자. 규칙이 최소한으로 갖추어야 할 형태는 아래의 그림과 같으며, 여기서 검사하고자 하는 파일이 rule의 condition 조건에 TRUE가 될 경우, Yara 명령을 실행했을 때 규칙에 맞음을 출력하고 condition 조건에 False가 되면 기본적으로는 출력되지 않는다.

여기서 규칙의 이름은 영숫자와 밑줄 문자를 포함할 수 있지만, 첫 번째 문자는 숫자를 사용하면 안 된다. 또한 다른 C와 같이 기본적으로 예약되어 있는 키워드는 사용할 수 없다. 

이를 통해 하나의 간단한 실습을 하나 해보자. 규칙을 적용하려는 대상은 바로 UPX로 패킹되어 있는 파일로, UPX의 경우 .code 섹션과 .data 섹션 등 섹션의 내용을 UPX 1 섹션에 압축한다. 이렇게 압축된 내용은 실행되면서 메모리에서 할당된 UPX 0 섹션의 주소에 압축을 풀어 본래의 내용을 실행한다. 따라서 "UPX0"라는 문자열과 "UPX1"이라는 문자열이 포함되어 있는지 확인해보자. 문자열의 여부를 확인하기 위해서는 "strings"를 사용하여야 하며 이는 아래의 그림을 보자.

규칙 "UPX_rule"을 선언하고 strings를 통해 $upx0와 $upx1을 선언해 각 UPX N 섹션의 여부 확인을 위한 문자열을 지정한다. 그 후 condition을 통해 $upx0을 만족하는 동시에 $upx1을 만족하는지 확인하며 만약 둘 중 하나라도 존재하지 않을 경우 False가 된다.

위 규칙을 사용하여 두 개의 파일에 관하여 확인해보았다. Yara-python으로 사용했기에 Python을 실행 후 Yara 모듈을 Import 해준다. 그 후 rules라는 변수에 규칙을 컴파일해주었고, 각 파일이 매칭 되는지 확인하기 위해 match()를 사용하였다. 결과를 확인해보면 UPX 패킹이 되어 있는 파일의 경우 규칙의 이름이 반환되었으며, UPX 패킹이 되어 있지 않은 파일의 경우 아무것도 반환되지 않았다.

이러한 과정을 통해 Yara의 기본적인 사용방법에 대하여 알아보았다. 지금의 예제는 빙산의 일각에 불과하며 Yara를 통해 더 많은 조건을 확인할 수가 있다. 많은 조건이 있지만 본 문서에서는 Strings에 해당하는 문자열과 바이너리를 통한 탐지에 정규표현식의 활용까지에 대하여 알아볼 것이다.

2. String 탐지

텍스트 문자열은 ASCII 인코딩, 대소문자를 구분하는 문자열을 표현하는 가장 간단한 방법으로 " " 사이에 텍스트를 넣어주면 된다. 여기서 만약 대소문자를 구분하지 않으려면 해당 " "뒤에 nocase 설정을 추가해주면 된다. 예를 들어 위에서 $upx0 = "UPX0"라 되어 있는 것을 $upx0 = "UPX0" nocase로 nocase를 추가하면 $upx0은 "UPX0"뿐만 아니라 "upx0", "Upx0", "uPx0" 등도 일치하게 된다.

다음으로 wide 설정은 2 바이트를 한 글자로 읽는 인코딩에 대하여 문자열을 검색할 때 사용할 수 있다. 대표적으로 Unicode가 있으며 $MFT 파일의 내용을 보면 $FILE_NAME에 존재하고 있는 파일의 이름이 2 바이트씩 읽어야 함을 알 수가 있다. 만약 "UPX0"라는 문자열이 아래와 같이 2 바이트씩으로 읽어야 할 때, wide 설정을 추가해주면 된다. 단, Wide와 ASCII 형태 모두 검색하고자 할 경우 wide ascii 설정을 해주면 된다.

마지막으로 fullword 설정에 대하여 알아보자. fullword 설정을 할 경우 숫자나 문자가 올 경우 이를 구분하게 된다. 예를 들어 "UPX0"라는 단어가 "123UPX0123"이나 "aUPX0", "UPX01" 등이 나올 경우 이는 거짓이 된다. 이에 반해 "...UPX0..."이나 "_UPX0_", "  UPX0  " 등은 참이 된다.

이렇게 문자열에서 줄 수 있는 설정들에 대하여 알아보았다. 이를 위 그림처럼 규칙을 생성했을 경우 Unicode형태로 되어 있는 "UPX0", "UPX1"를 모두 읽는 것을 확인할 수가 있다. 이러한 설정은 같이 사용될 때 더욱 유연하게 사용될 수 있다.

3. Binary 탐지

16진수 문자열은 { } 사이에 Hex 값을 입력하는 형태로 입력해야 하며, Wild-cards, Jumps 그리고 Alternatives라는 세 가지 구조를 허용한다. 입력하고자 하는 16진수 값 중 모르거나 어떠한 바이트가 있더라도 상관이 없을 경우 Wild-Cards를 사용할 수가 있는데, wild-cards는 물음표(?)를 통해 바이트를 대체하여 나타낼 수가 있다. 아래의 그림을 보자.

Hex 값을 나타내는 규칙을 생성하며 "??"를 통해 Wild Cards를 사용하는 것을 확인할 수가 있다. 이러한 규칙을 위 Text에서 사용한 UPX0, UPX1가 존재하고 있는 파일에 적용하면 규칙에 부합한다는 결과를 얻을 수 있다. 여기서 한 바이트 "??" 뿐만 아니라 "?8"과 같이 한 바이트의 두 자릿수 중 한 자리에만 적용할 수도 있다.

하지만 만약 악성코드가 특정 시그니처 사이에 사용자의 계정이 존재할 경우, 사용자 계정의 길이는 개인마다 다르다. 이러한 경우 규칙을 제작하는 사람의 입장에서는 번거롭지만, Hex의 Jumps 기능을 통해 간편하게 규칙을 생성할 수 있다. 

위 규칙과 같이 "name:....UPX"에서 "...."에 사용자의 계정이 존재할 경우 이에 관해선 확인할 수 없으므로 [n-m]의 형태를 통해 Jumps를 사용할 수 있다. n글자에서 m글자까지 무작위 하게 16진수가 올 수 있는데, 이는 "name:Kali-KMUPX", "name:SecurityUPX" 등 4글자에서 10글자 사이의 무작위 바이트를 허용한다. Jumps는 최대 [0-255]까지 허용하며 너무 범위가 크게 설정되어 있는 경우 성능의 저하를 초래할 수 있으므로 적절한 범위를 설정해야 한다.

이제 16진수를 나타낼 때 사용할 수 있는 Alternatives에 대하여 알아보자. Alternatives는 "A | B"로 나타내며, 이는 일반적인 프로그래밍 언어에서 사용하는 바와 같이 '또는'을 의미한다. 예를 들어 { AA BB (11|22) CC DD }로 설정할 경우, { AA BB 11 CC DD }와 { AA BB 22 CC DD } 둘 다 규칙에 부합된다. 하나의 글자가 아니라 여러 글자를 같이 적용할 수 있는데, { (AA BB CC | DD) FF }라 되어 있을 경우 {AA BB CC FF}와 {DD FF}가 조건에 부합된다. UPX를 예로 들어보자.

UPX 패킹의 경우 UPX0와 UPX1이라는 문자열을 발견할 수 있지만, UPX2는 존재하지 않는다. 따라서 위와 같이 "UPX(1|2)"로 규칙을 설정할 때, "UPX1" 또는 "UPX2" 둘 중 하나인 "UPX1"에 부합되므로 참이 된다. 만약 더 긴 문자열이나 불규칙적일 경우 두 바이트나 그 이상으로 (11 22 33 | AA)와 같이 Alternatives를 활용할 수도 있다. 마지막으로 이러한 기능들을 복합적으로 사용한 아래의 규칙을 보자.

위 그림과 같이 이러한 세 가지 기능은 같이 사용될 수가 있다. $a에는 "U"로 시작하며 그 사이에 1~6글자의 바이트가 무작위 하게 올 수 있으며 마지막에 "0"이 있는지 확인하는 것이다. $b의 경우 WildCards로 시작하여 마지막에 "0x3?"를 나타내므로 ASCII 글자인 0x30(0)와 0x31(1) 둘 다 올 수가 있다. 이렇게 기능들을 같이 사용하므로 훨씬 유연한 규칙을 생성할 수가 있다.

4. Regex 활용

정규표현식이란 특정한 규칙을 가진 문자열의 집합을 표현할 때 사용하는 '형식 언어'이다. Yara에서는 특정 문자열이나 바이너리뿐만 아니라 정규표현식 또한 사용할 수 있기에 이를 이해하고 있는 것은 Yara를 더 효율적으로 활용할 수 있게 한다. 우선 정규표현식에 대해 기초적인 개념을 설명한 뒤, Yara에서의 활용을 보자.

위 표는 정규표현식에서 사용할 수 있는 문법들에 대해 정리한 것이다. 이를 참고하여 몇 가지 문법을 직접 사용해보자. 악성코드와 관련해서 가끔 하드 코딩되어 있는 경우가 있다. 이러한 하드 코딩되어있는 문자열의 경우 주로 특정 사이트와의 연결을 위한 도메인 주소나 IP주소를 가지고 있는 경우가 있는데, 정규 표현식의 이해를 돕고자 이를 예제로 간단하게 구현해보자.

    IP Address

IP의 경우 x.x.x.x와 같이 세 개의 '.'과 네 개의 숫자들로 구성되어 있다. 이를 정규표현식으로 구현하기 위해서는 숫자들의 집합과 '.'을 표현할 수 있어야 한다. 정규표현식에서 문자들의 집합은 '[ ]'으로 표현할 수가 있으며, 이를 통해 숫자를 나타내면 0부터 9까지 매칭 되어야 하므로 '[0-9]'가 된다. 하지만 간단하게 '\d'를 통해서도 숫자를 나타낼 수가 있다. 따라서 이를 통해 나타내면 "\d\.\d\.\d.\d"로 "숫자.숫자.숫자.숫자"의 형태가 된다.

하지만 IP 주소의 경우 한 자리마다 1 Byte로 최대 255까지 표현할 수 있지만 위의 표현은 한 글자씩만 해당한다. 따라서 이는 IP 주소로 나오는 숫자가 한 글자에서 세 글자까지 읽을 수 있도록 수정해야 하며, 이를 정규표현식으로 나타내기 위해서는 최소 n 개에서 최대 m 개 까지 반복됨을 나타내는 {n, m}을 사용하면 된다.

따라서 "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}"과 같이 나타낼 수가 있다. 이를 그룹 '( )'으로 묶어 더 간략히 표현할 수 있으며, 이를 표현하면 "(\d{1,3}\.){3}\d{1,3}"이다.

    Domain Name

특정 사이트에서 파일을 다운로드하거나 연결을 할 때 보통 도메인 주소가 포함되는 경우가 많다. 간단하게 구현해보며 이해하는 것이 목적이므로 "http://xxxx.xxxx.xxx"를 기준으로 해보자. 우선 http나 https라는 단어가 있을 경우 이를 통해 도메인 주소를 얻을 수가 있다.

우선 http와 https에서 공통적으로 'http'는 포함되므로 "http"를 입력한 뒤 '?'를 통해 's'를 's'가 없거나 하나 있을 경우에만 매칭 하는 결과를 얻을 수가 있다. 이를 통해 나타내면 "https?:"가 된다. 여기서 뒤의 도메인 주소는 공백이 아닌 문자가 오기 때문에 "\S"를 입력해주고 반복된 것 또한 포함하는 "+"를 입력해준다. 최종적으로 나타내면 "https:?\S+"가 된다.

이렇게 정규표현식에 대하여 간략히 알아보았다. 정규표현식에 대한 꾸준한 연습을 통해 이후 좀 더 정확한 표현식을 만드는 것은 중요하다. 실제 안티바이러스 제품의 경우 특정한 패턴을 통해 엔진에 등록되었을 때, 해당 패턴이 오류를 범하고 있어 정상 파일을 감염 파일로 간주하게 될 경우 큰 피해를 보게 된다.

In Yara

Yara에서 정규표현식을 표현하기 위해서는 "/Regex/"와 같이 두 개의 슬래시(/) 안에 정규 표현식을 사용하여야 한다. 정규표현식에선 String 탐지에서 사용할 수 있었던 'nocase', 'wide', 'ascii', 'fullword'의 기능을 사용할 수 있다. 아래의 그림을 보자.

문자열에 정규식을 사용하면서 'wide' 설정을 해주었다. 이 경우 A에서 Z까지의 문자가 3개 온 뒤 '0'이나 '1'이 오는 경우를 뜻하며 마지막에 wide를 설정해주므로 Unicode 문자열을 읽을 수 있게 된다. 따라서 "UPX0"나 "UPX1"은 조건에 부합되지만, 그 외에 "AAA0"이나 "FFF1" 등도 조건에 부합될 수 있어 오탐이 증가할 수 있다. 여기선 쉬운 이해를 위해 명확하지 않은 규칙과 예제를 사용하였지만, 정규표현식의 경우 특정 패턴을 매칭 시키는 데 있어 유용하다는 것은 명확한 사실이다.

5. Practice

이렇게 Yara를 통한 Strings에 대하여 살펴보았다. 마지막으로 학습한 내용을 정리해보고자 Python을 통한 실습을 해보자. 실습에 사용한 파일은 리버싱을 접해본 사람은 모두 알만한 Abex's CrackMe 01과 UPX이다. 대상 파일인 crackme01.exe가 UPX로 패킹되어 있는지 찾는 것이다. 이를 위해 2개의 코드를 작성하였는데, 우선 UPX 패킹 여부와 CrackMe01.exe인지 확인하기 위한 코드와 이러한 규칙을 적용시키기 위한 실행파일이다. 우선 제작한 규칙을 먼저 살펴보자.

위의 코드와 같이 "UPX_rule"이라는 규칙과 함께 "CrackMe01"이라는 규칙을 생성하였다. UPX_rule을 먼저 보면 UPX0 섹션과 UPX1 섹션에 지정된 문자열을 탐지하기 위한 변수 두 개와 두 변수가 모두 참이어야 규칙에 부합된다. 다음으로 CrackMe01의 경우 해당 파일에 하드 코딩되어 있는 세 가지 문자열을 각 변수로 선언하고 이 셋 중 하나라도 부합되면 참이 되도록 하였다. 이제 이러한 규칙을 실행시키기 위한 Python 코드를 작성해보자.

코드에 대한 자세한 설명은 생략하고, 몇 가지에 대해서만 설명하겠다. 규칙은 파일뿐만 아니라 프로세스에도 적용할 수 있으며 이 경우 rules.match(file)이 아닌 rules.match(pid=PID)와 같이 입력해야 한다. 따라서 -r 옵션을 통해 규칙 파일을 지정해주고, -d나 -p 옵션을 사용하여 파일이 존재하고 있는 폴더와 PID를 지정해줄 수 있다. 실습을 통해 두 경우 모두 확인해보자.

위 그림은 -d 옵션을 통해 경로를 여러 exe파일이 모여 있는 경로를 지정했다. 출력된 결과를 확인해보면 UPX 패킹으로 확인되는 것이 3개, CrackMe01으로 확인되는 것이 2개, 두 조건 모두 만족하는 것은 01.exe 하나라는 것을 확인할 수 있다. 다음으로 -p 옵션을 확인해보자.

출력 결과를 확인하면 PID 11504는 CrackMe01이며, PID 8664는 UPX패킹과 함께 CrackMe01의 조건을 만족한다. 실제로 PID 11504는 위의 Reverse_L01.exe이며, PID 8664는 01.exe로 두 조건을 모두 만족한다.

이처럼 실제 대상 파일들을 하나의 폴더에 모아놓은 뒤 yara를 적용하면 빠르게 대상 파일들을 구분할 수 있게 된다. 하지만 실제 Yara를 사용함에 있어 사용할 규칙은 엄격한 기준이 있어야 하며, 만약 빈약한 기준을 가지고 분류할 경우 오탐이나 미탐이 발생할 수 있기에 유의하여야 한다.

Reference

 [+] 사이트

    - http://hackganz.blogspot.kr/

    - http://chogar.blog.me/80182473714

    - http://www.dailysecu.co.kr/news_view.php?article_id=4776

    - http://john09.tistory.com/121

    - https://plusvic.github.io/yara/

    - http://yara.readthedocs.org/en/v3.4.0/writingrules.html

    - https://ko.wikipedia.org/wiki/정규_표현식

    - http://regexr.com/

    - http://blog.eairship.kr/205

[+] 문서

    - YARA_1.6_Korean_Users_Manual.pdf

    - #WI-13-024.pdf(YARA를 이용한 악성코드 시그니처 확인)

1. 악성코드란

악성코드란 악성 행위를 위해 개발된 컴퓨터 상에서 동작하는 모든 실행 가능한 형태이다. 이는 사용자의 의사와 이익에 반해 시스템을 파괴하거나 정보를 유출하는 등 악의적인 활동을 수행하도록 의도적으로 제작된 소프트웨어를 말한다. 보통 악성코드라 하면 EXE 파일이 떠오르지만, 이외에도 JS와 같은 스크립트나, 개발자의 실수로 만들어진 버그 또한 악성코드라 분류할 수 있다.

악의적으로 사용된다는 뜻의 악성코드는 어디에 사용될까? 이에 대한 답은 다양하다. 악성코드의 대상은 사회 기반 시설에서부터 산업 기밀을 목적으로 기업을 대상으로 할 수 있다. 이처럼 특정한 목표를 갖는 것 외에도 일방적으로 많은 이들에게 감염시키고자 하는 예도 있다. 랜섬웨어나 DDoS에 사용될 악성코드의 경우 많은 사용자들을 감염시켜야 더 많은 금액을 취하거나, 더 강력한 DDoS 공격을 수행할 수 있다. 결국, 공격자는 개인 정보 수집, DDoS 공격, 변조 및 신분 절도, 금전 요구 등 다양한 목적에 맞게 악성코드를 설계하며, 이러한 악성코드는 하나의 기능이 아닌 여러 기능을 수행하고자 복합적으로 제작되기도 한다.

이렇게 다양한 기능의 악성코드들이 존재하는 만큼 다양하게 분류될 수 있다. 악성코드는 동작 방식에 따라 크게 네 가지 항목으로 분류할 수 있고, 이는 다시 목적에 따라 여러 개의 항목으로 분류할 수가 있다. 다음 장에서부터 이러한 분류에 대하여 알아보자.

2. 동작에 의한 분류

악성코드가 어떠한 방식으로 동작하는지에 따라 분류해보자. 이 경우 크게 네 가지 항목으로 나눌 수가 있는데 바로 일반 사용자들에게도 익숙한 이름의 'Virus', 모리스에 의해 세상에 알려진 'Worm', 생소한 단어의 'PUP', 마지막으로 그리스 신화에서 들어본 'Trojan'이다. 수많은 악성코드가 존재하지만, 어떻게 동작하는지에 따라 이렇게 네 가지로 분류할 수 있다.

하지만 점차 보안이 발전하는 만큼 악성코드 또한 진화하고 있기에 더 이상 하나의 방식이 아닌, 두 가지 이상으로 복합되어 나타나기도 한다. 복합된 방식의 악성코드 또한 새로운 이름으로 분류되어 있지만 모두 이 네 가지를 토대로 나타난 것이기 때문에 이에 대해 알아야 한다. 이들에 대한 기초적인 지식 없이 새로운 악성코드를 이해하기는 어렵다. 따라서 우선 네 가지 방식에 대한 이해를 목표로 하자. 이제 각 분류된 이름들이 어떻게 동작하는지 알아보자.

2.1 Virus

사람이 어떠한 바이러스에 걸려 아프다는 것처럼 컴퓨터도 어떠한 바이러스에 걸렸다는 단어가 잘 어울린다. 이처럼 우리는 악성코드란 이름보다 바이러스라는 단어를 더 친숙하게 생각한다. 하지만 바이러스와 악성코드는 유사하면서도 다르다. 바이러스가 악성코드 중 하나의 분류로 악성코드와 동의어가 아니다. 그렇다면 보안이 생소한 일반 사용자들에게 왜 '악성코드'라는 단어보다, '바이러스'라는 단어가 더 자주 사용될까?

1986년 최초의 개인용 컴퓨터 바이러스인 브레인 바이러스가 나타났다. 이후 바이러스는 점차 진화하며 이전에는 보이지 않는 방식으로 동작하는 것을 확인할 수가 있었다. 이에 따라 유사하면서도 차이가 있는 바이러스를 구분하기 시작하였고, 이러한 모든 범주를 포괄하여 지칭하는 것이 바로 'Malicios Softwae' 혹은 'Malicios Code'가 된 것이다. 바이러스라는 이름으로 먼저 사용되었기에, 일반 사용자들의 입장에서는 굳이 구분 지을 필요가 없던 것이다. 바이러스와 악성코드가 다름을 알아보았으니 이제 바이러스가 어떠한 것인지 구체적으로 알아보자.

바이러스가 실행될 경우 바이러스는 새로운 매개체(파일)를 찾는다. 새로운 매개체를 찾은 바이러스는 대상의 PE 구조를 변경하거나, 코드를 삽입하는 등의 방식으로 자신이 가지고 있는 악의적인 행위를 다른 파일 또한 하도록 조작한다. 더 이상 감염시킬 대상이 없을 때까지 감염하며 바이러스 제작자가 의도한 기능을 지속해서 수행하게끔 한다. 바이러스의 감염성은 실제 생활에서 바이러스에 걸린 환자가 다른 지역에 갈 경우 새로운 지역 또한 바이러스에 감염될 수 있듯이, 최초 감염된 PC의 파일이 다른 PC로 옮겨져 실행될 경우 마찬가지로 새로운 매개체를 찾게 되어 다시 감염 동작을 시행한다.

문제는 감염을 시작한 바이러스가 일반적인 파일들만 감염시키는 것이 아니라 플로피 디스크와 하드 디스크 파티션의 볼륨 부트 레코드, 마스터 부트 레코드 등 감염시킬 수 있는 영역은 결코 작지 않다. MBR이 감염될 경우 사용자가 MBR을 복구하거나 운영체제를 다시 설치해야 하며, 만약 서버가 이러한 바이러스에 걸릴 경우 피해액은 더욱 커진다.

이와 같이 바이러스는 자기 자신을 복제하며 활동하는 것에 대해 알아보았다. 그렇다면 이러한 바이러스는 어떻게 없애야 할까? 여기서 '치료'라는 개념과 '제거'라는 개념의 차이에 대해 알아야 한다. 치료란 '[명사] 병이나 상처 따위를 잘 다스려 낫게 함.'과 같이 이상이 생긴 부분을 원래의 형태가 되도록 함이다. 반대로 제거란 '[명사] 없애버림.'으로 이상이 있는 부분을 삭제하는 것이다. 컴퓨터 바이러스의 경우 대상이 된 모든 파일의 구조가 바이러스가 의도한 대로 변조되었기 때문에, 이를 '치료'한다라고 표현한다. 단, 최초 감염을 실행한 숙주 파일의 경우 '제거'되는 것이 맞다. 

바이러스에 대해 정리하자면 최초 숙주 파일이 실행되며 다른 매개체로 감염이 시작된다. 그리고 이러한 매개체가 다른 사용자의 PC로 옮겨져 실행될 경우 해당 PC 또한 감염된다. 감염은 일반적인 파일뿐만 아니라 VBR이나 MBR까지 감염될 수 있으므로 유의하여야 한다. 제작자에 의해 최초 제작된 EXE 파일의 경우 제거되는 것이 맞지만, 숙주로부터 감염된 다른 파일들은 치료되어야 한다. 또한 새로운 PC로 옮겨진 파일은 최초의 숙주가 아니므로 이 역시 치료되어야 함이 맞다.

2.2 Worm

최초의 웜은 네트워크에서 활동이 적은 프로세서들을 찾아 업무를 할당하고 연산 처리를 공유하여 전체적인 네트워크의 효율을 높이도록 설계되었다. 하지만 이러한 웜이 악성코드가 된 것은 저명한 모리스에 의해 개발된 '모리스 웜' 때문이다. 모리스가 제작한 이 웜은 인터넷에 연결된 수많은 컴퓨터들을 빠른 속도로 감염시켰으며, 당시 운영체제들의 많은 버그들을 통해 확산되었다.

이렇듯 웜은 운영체제나 응용 프로그램의 취약점을 찾아 네트워크를 통해 전파되며, 바이러스가 다른 매개체들을 찾아 변조하므로 감염시키는 것에 반해 스스로 자기 자신을 복제하며 운영체제의 취약점을 통해 연결된 다른 네트워크로 전이하는 형태로 진행된다. 이는 인터넷이 발달함에 따라 웜이 한번 실행될 경우 이전보다 더욱 빠른 속도로 퍼지게 된다. 만약 웜이 실행되면 해당 PC에서 자신을 끊임없이 복제하게 되므로 메모리와 CPU에 과부하가 걸리게 되며, 연결된 네트워크로 전이하므로 해당 네트워크의 PC 또한 감염될 수 있다.

바이러스의 경우 '치료'라는 단어를 사용하였지만, 웜의 경우 다른 파일을 변조하지 않고 끊임없이 자신을 복제하기 때문에 제거해야만 한다. 또한 웜이 공격할 수 있는 보안상의 취약점을 방지하기 위해 지속적인 보안 업데이트가 필요하다.

2.3 PUP

PUP는 'Potentially Unwanted Program'의 약자로 우리말로 번역하면 '잠재적으로 원하지 않는 프로그램'이라 할 수 있다. PUP의 경우 다른 악성코드들과 가장 큰 차이점이 존재한다. 대개 악성코드는 사용자가 동의하지 않고 설치되지만, PUP의 경우 사용자의 동의가 포함되었기에 따로 분류된다. 그렇다면 사용자들은 악성코드로 분류되는 PUP에 대해 왜 동의하는 것일까? 이는 컴퓨터에 프로그램을 직접 설치해본 사람이라면 알 수 있듯이, 무료로 이용할 수 있는 많은 프로그램 중에서 설치를 진행할 때 설치하고자 하는 프로그램이 아닌 다른 제품까지 추가로 설치하겠냐고 묻는 항목에 기본적으로 체크가 되어 있다. 이러한 체크 항목이 분명히 나와 있지만, 충분히 사용자가 놓칠 수 있다. 이와 같이 PUP는 약관이 존재하며 사용자에게 동의까지 받지만, 이 동의가 결코 자의적으로 행해진 것은 아니다.

이러한 PUP는 로그인할 때마다 광고하고자 하는 웹 사이트의 바로가기를 바탕화면에 생성하거나, 웹 브라우저의 기본 페이지를 변경, 웹 페이지 접속 시 특정 광고가 지속적으로 노출되는 등으로 PC나 인터넷 접속이 느려지는 등 사용자에게 불편함을 준다. 이렇게 사용자의 자의적인 선택 아닌 동의로 설치된 PUP는 제거하는 방법 또한 까다로운 경우가 많다. 설치는 되었음에도 불구하고 제거와 관련된 기능이 없거나 이를 사용자가 찾기 어렵게 숨긴다.

어떻게 보면 사용자에게 불편함만을 주기 때문에 어찌 보면 악성코드로 부르기 모호한 점이 있다고 느낄 수 있다. 하지만 2014년 조사 결과에 따르면 전체 악성코드 감염의 24.77%가 PUP라는 점과 대부분 광고가 목적이다 보니 허술한 보안 관리로 인해 파밍이나 공인인증서 탈취를 위한 악성코드 등의 전파 경로로 악용된 사례가 존재하기 때문에 사용자의 주의가 필요하다. 

2.4 Trojan

트로이 목마(Trojan Horse)는 그리스와 트로이 사이의 전쟁에서 유래된 것이다. 당시 그리스와 트로이는 10여 년간 전쟁을 치르고 있었으나 그리스가 목마를 만들어 그 안에 병사들을 매복시킨 후 퇴각한 척한다. 이후 트로이 군은 이 목마를 승리의 상징으로 이를 가지고 갔지만, 결국 그 안에 있던 병사들이 나타나 트로이의 성문을 열어 그리스가 승리하게 된다.

위의 이야기처럼 그리스는 자신이 의도하는 바를 트로이에게 숨겨 이를 가지게끔 했으며, 트로이가 이를 가지고 간 후 그리스가 의도한 대로 되었다. 악성코드의 트로이 목마도 마찬가지로 공격자가 의도하는 바를 위하여 대상을 속인 다음 실행되었을 경우 숨겨져 있던 기능을 수행한다. 이에 대해 많은 곳에서 '정상적인 파일로 위장하여'라 정의하지만, 누가 보아도 비정상적으로 보이면서 웜, 바이러스, PUP가 아닌 경우 이러한 정의에서 벗어난다. 

따라서 이에 대해 다시 정의하자면 바이러스와 같이 다른 파일을 변조하지 않고, 웜과 같이 네트워크를 통한 전파나 자가 복제가 이루어지지 않으며, 마지막으로 PUP와 같이 사용자의 동의가 이루어지지 않았을 때 'Trojan'으로 분류해야 한다. 바이러스나 웜 또한 최초 실행되고자 할 때는 정상적인 파일처럼 보여 사용자가 실행되게끔 할 수 있다. 이러한 점을 고려했을 때, 어떠한 동작을 하는지 모르는 프로그램이 있는데 위 세 가지에 해당이 되지 않을 경우 트로이 목마라 하는 것이 더욱 정확하다고 본다. 이러한 트로이 목마는 네 가지 분류 중에서 가장 많이 사용되고 있으며, 목적에 따라 다양한 기능을 갖기도 한다. 마지막으로 트로이 목마 또한 '치료'가 아닌 '제거'의 개념이 더욱 적절한 조치이다.

3. 목적에 의한 분류

지금까지 동작 방식에 따라 크게 네 가지로 구분하였으며, 이러한 네 가지 방식은 목적에 따라 상이한 동작을 수행하게 된다. 이러한 목적에 따라 다양한 종류로 구분할 수 있으며 하나의 분류에서 또다시 기능에 따라 더 세분화될 수 있지만 그러면 너무 많은 종류로 구분될 수 있기에, 목적에 따라 크게 분류하였다. 단, 목적에 따라 분류가 되어 있다고 하여 이들을 개별적인 속성으로 간주하면 안 된다. 점차 악성코드가 진화함에 따라 하나의 악성코드가 여러 기능을 가지고 있는 경우가 많이 나타나기 때문이다. 따라서 이번 장에서는 어떠한 목적이나 기능을 수행하는 악성코드가 어떻게 명명되었는가에 대하여 정리해보자.

3.1 Downloader 

다운로더는 이름에서와 같이 파일을 내려받는다. 여기서 다운로드는 정보통신망에 접속한 사용자가 원격지 컴퓨터나 인터넷상에 있는 파일을 자신의 PC에 전송받는 것을 의미한다. 우리가 사용하는 프로그램 중에서 외부로부터 다운로드 동작을 수행하는 것이 많기 때문에, 어디서 무엇인가 다운로드하는 것 자체만으로는 악의적이라 할 수 없다. 

그렇다면 어떠한 경우에 악의적인 다운로드가 될까? 다운로드 기능이 있는 프로그램 자체가 악의적이지 않다는 것은 안티바이러스 제품을 통해서도 알 수 있다. 따라서 악성코드 제작자들은 이러한 점을 이용하는 것으로, 다운로드하는 행위 자체만으로는 초기에 차단되지 않고 실행될 수 있기에 다운로드 기능만을 포함하고 있는 프로그램을 만드는 것이다. 차단되지 않고 존재하고 있는 프로그램을 사용자가 실행하였을 경우 외부로부터 추가적인 악성코드를 다운받으므로, 이후의 동작을 위한 목적이라 볼 수 있다.

3.2 Dropper

드롭퍼의 경우 다운로더와 유사하게 새로운 파일을 생성한다. 단, 다운로더가 외부에서 파일을 다운받는 것에 반해 드롭퍼의 경우 자기 자신 안에 존재하고 있는 데이터들을 통해 새로운 파일을 생성하는 것이다. 보통 드롭되는 파일들은 원래의 파일 안에 압축되어 있으므로 실행해보지 않을 경우 이에 관하여 확인하기 어렵다. 

분석가는 다운로더와 드롭퍼가 새로운 파일을 생성한다는 점에서 이러한 추가적인 파일 또한 분석을 진행하여야 한다. 드롭퍼와 다운로더 모두 다음 단계를 위한 준비 동작으로 볼 수 있기 때문이다. 여기서 인젝터(Injector)라 불리는 악성코드 또한 드롭퍼의 특수한 형태로, 파일을 생성하지 않고 해당 데이터를 바로 새로운 프로세스로 생성하여 메모리에 놓기도 한다.

인젝터의 경우를 제외하고 다운로더와 드롭퍼 모두 아래의 런처(Launcher)를 통해 실행될 때가 많으며, 대부분 이 두 가지의 기능을 가지고 있을 경우 런처의 기능 또한 가지고 있는 경우가 많다.

3.3 Launcher

다운로더와 드롭퍼가 새로운 파일을 생성하였다 하더라도, 추가적인 악성 행위를 하기 위해선 새로운 파일 또한 실행되어야 한다. 하지만 어떤 사용자가 이유도 알 수 없이 생성되어 있는 파일을 실행할까. 그렇기에 이들을 실행하기 위한 기능이 필요하게 되었고, 바로 이를 기능과 같이 런처(Launcher)라 하게 되었다.

이미 추가로 실행하고자 하는 파일이 대상 PC에 존재할 경우 런처는 혼자서 사용될 수 있다. 하지만 대부분의 경우 그러한 파일이 대상 PC에 존재하고 있지 않기 때문에, 혼자 사용되는 것보단 다운로더나 드롭퍼의 기능과 함께 사용되는 경우가 일반적이다. 그러므로 분석을 하는 데 있어 어떠한 대상을 실행하고자 하는지 파악하는 것이 먼저이며, 만약 그 실행 대상을 찾았을 경우 그 대상 또한 추가적으로 분석해야만 한다.

3.4 Adware

인터넷이 발달하며 이에 따라 인터넷을 통해 광고하는 것에도 비용이 많이 소모된다. 애드웨어(Adware)는 소프트웨어 자체에 광고를 포함하거나, 같이 묶어서 배포한다. 이는 프로그래머가 개발하면서 개발 비용을 충당할 수 있게 해주며, 광고주의 입장에서는 포털 사이트에 배너를 놓는 것보다 비용이 저렴하기 때문이다. 

개발자와 광고주 둘 모두에게 이윤이 되기에 애드웨어가 많이 배포되고 있으며 주로 다른 프로그램을 설치할 때 동의 항목에 체크가 되어 있듯이, PUP 방식을 통해 설치되는 경우가 많다. 이렇게 사용자의 인식 없이 설치된 애드웨어는 인터넷 시작 페이지를 바꾸거나 광고와 관련된 알림 창을 띄우며 바탕화면에 광고하고자 하는 페이지의 바로가기를 지속해서 생성하기도 한다.

개발자와 광고주에게는 Win-WIn이지만 정작 그들에게서 상쇄된 손해는 일반 사용자들의 몫이 되었다. 과도한 애드웨어로 인해 PC에 불필요한 프로그램이 많아지며, 인터넷의 속도를 저하하기도 한다. 또한 무차별적인 광고로 인해 사용자가 미성년자임에 불구하고 성인물 사이트와 관련된 광고를 보이기도 한다. 마지막으로 애드웨어의 경우 광고만이 목적이다 보니 제작되는 과정에서 많은 부분이 고려되지 않을 수가 있으며, 이것이 응용 프로그램 상의 취약점을 갖게 될 경우 다른 악성 프로그램들에 의하여 악용될 소지가 있다.

3.5 Spyware

스파이라는 단어는 어떠한 곳에 침투하여 정보를 빼내어 가는 사람을 말할 때 주로 사용한다. 스파이웨어의 경우도 마찬가지로 개인이나 기업의 정보를 그들이 알지 못하게 수집하며, 이러한 정보를 동의 없이 다른 곳으로 보내기도 한다. 일반적으로 자신의 존재를 사용자로부터 숨겨 탐지가 어렵게 사용자의 컴퓨터 조작을 방해하며, 또한 사용자의 컴퓨터를 지켜보는 것에 그치지 않고 인터넷 검색 흔적이나, 사용자 로그인, 은행이나 신용 계좌 정보 등 거의 모든 유형의 정보를 수집하기도 한다.

스파이웨어는 거의 컴퓨터에서 혼자 존재하지 않고 한 번 감염된 컴퓨터에서 안티바이러스나 방화벽을 비활성화하고 브라우저의 보안 설정을 낮추므로 시스템이 추가적으로 감염 기회에 노출되도록 한다. 이렇듯 스파이웨어에 감염되면 원하지 않은 막대한 양의 CPU 활동, 디스크 사용, 네트워크 트래픽 등이 생성될 수 있다.

이를 제작한 공격자들이 원하는 것은 일반적으로 '정보'이기 때문에 많은 정보를 수집하기 위해 개인 PC뿐만 아니라 사람들이 많이 오가는 공용 도서관이나 PC방과 같은 곳 또한 선호한다. 여기서 스파이웨어가 더욱 문제화되는 것은 범죄자들만 스파이웨어를 이용하는 것이 아니라 정부에서 민간인이나 다른 주요 기업들을 감시하고자 사용하고자 하는 경우가 있기 때문이다. 만약 정부에서 이러한 기능을 일반 사용자들이 많이 사용하는 제품에 추가할 경우 정부가 사용자의 일거수일투족 감시가 가능하게 되기 때문에 충분히 압력을 넣을 수가 있다. 이러한 경우 해당 제품 제조사의 윤리성을 믿어야 하기에 일반 사용자의 입장은 난처할 수밖에 없다.

스파이웨어는 많은 기능을 포함한 말로 이는 다시 패스워드 스틸러나 키로거와 같이 세분화될 수 있다. 패스워드 스틸러의 경우 브라우저를 통해 로그인한 사용자의 정보를 탈취하며, 키로거의 경우 사용자가 입력하는 모든 키 이벤트를 공격자에게 전송한다. 하지만 점차 진화하므로 더 이상 키 이벤트가 아니라 어떠한 화면을 보고 있는지, 캠이나 마이크가 있을 경우 어떠한 모습으로 어떠한 소리와 함께 사용자가 존재하고 있는지까지 공격자에게 노출될 수 있다. 따라서 개인정보가 중요시되는 만큼 스파이웨어는 컴퓨터가 아닌 우리 자신에게 치명적인 피해를 줄 수 있기에 더욱 주의해야 한다.

3.6 Ransomware

랜섬웨어란 Ransom(인질의 몸 값)과 Software의 합성어로 최근 급격히 퍼지고 있는 악성코드이다. 사용자에 의해 랜섬웨어가 실행될 경우 파일에 대한 암호화를 진행하며 이를 사용자가 실행이나 읽을 수 없도록 하여 사용자의 자료를 인질로 잡고 돈을 요구한다.

실행될 경우 악성코드 제작자가 정의한 조건에 해당하는 모든 파일이 암호화되는데, 주로 강력한 암호화 방식을 사용하기 때문에 복호화가 매우 어렵다. 여기서 랜섬웨어 제작자가 의도하는 것은 사용자가 돈을 지불하는 것으로 다시 파일들을 이용하고 싶을 경우 어디로 돈을 보내야 하는지 등의 안내문을 같이 출력하는 경우가 많다. 주로 암호화되는 확장자는 문서나 사진과 관련된 부분이 많으며, 암호화된 주요한 문서나 사진들에 더 이상 접근할 수 없게 된다. 

기업의 경우 중요한 프로젝트와 관련된 자료들이 한 순간에 모두 암호화돼버리면 이에 따른 손해액이 크게 증가한다. 따라서 이들은 결국 돈을 지불해서라도 자료들을 복호화하고자 하게 된다. 하지만 문제는 정작 금액을 지불하더라도 복호화가 진행되지 않는 경우가 많다는 점에서 더욱 큰 문제가 되고 있다. 결국 암호화된 자료는 더 이상 사용할 수 없게 되어버리는 것이나 마찬가지다.

이러한 랜섬웨어가 점차 진화하면서 새로운 기능들이 계속 추가되고 있다. 암호화가 진행되는 도중 프로세스를 종료하지 못하도록, 프로세스를 종료시킬 수 있는 다른 프로세스의 실행을 방해하기도 하며, 볼륨 쉐도우 카피에서 파일을 복원하지 못하도록 이를 제거하기도 한다. 따라서 실질적으로 한번 암호화된 파일은 거의 복구가 불가능하기 때문에 백업과 같은 사전 대비가 가장 중요한 화두가 된다.

3.7 Backdoor

백도어는 이름에서와 같이 '뒷 문'이라는 뜻으로, 원래는 시스템의 유지 보수나 유사시 문제 해결을 위하여 시스템 관리자가 보안 설정을 우회한 다음 시스템에 접근할 수 있도록 만든 도구이다. 하지만 최근에는 악의적인 목적을 갖은 공격자들이 쉽게 시스템에 재 침입할 수 있도록 이용하는 경우를 의미할 때가 더 많다.

백도어 프로그램은 비인가된 접근을 허용하는 프로그램으로 공격자가 이후 사용자 인증 과정 등 정상적인 절차를 거치지 않고 프로그램이나 시스템에 접근할 수 있도록 지원한다. 공격자는 시스템에 침입한 이후 재접속을 위해 백도어를 설치하기도 하지만, 프로그래머가 관리 목적으로 만들었다가 제거하지 않은 백도어를 찾아 악용하기도 한다.

대상 PC에 기존의 백도어가 존재하지 않을 경우 공격자는 최초 1회 이상 침투에 성공해야만 한다. 만약 침투에 성공했을 경우 침입한 권한에 대하여 백도어를 설치하게 되고, 이후 다시 접속하여 관리자 권한을 얻으려 할 것이다. 결국 백도어가 존재하고 있을 경우 지속적으로 공격자에게 노출되며 공격당할 수 있다. 출입이 자유로워진 공격자는 더 이상 어떠한 제약을 받지 않고 관리자 권한을 획득하기 위한 작업을 수행할 것이다. 보안 상의 취약점을 공격자가 찾아 관리자 권한을 획득한 경우 대상 PC는 공격자에게 종속된 것이나 다름없다.

3.8 Rootkit

우리가 쓰는 운영체제는 크게 두 개의 계층으로 유저 모드(Ring 3)와 커널 모드(Ring 0)로 이루어져 있다. 커널 모드에는 실제로 운영체제의 핵심적인 작업을 수행하는 코드가 동작하며, 유저 모드는 커널 모드의 코드를 사용하기 위해 API를 사용한다. 루트킷은 주로 커널 모드에 상주하고 있으며 그렇다 하여 유저 모드와 관련이 없는 것은 아니다. 커널 모드에서 작업하기에는 어려운 사항을 유저 모드에서는 간단하게 할 수 있기 때문에, 핵심적인 기능들은 커널 모드에서 수행하며 상대적으로 가벼운 기능들은 유저 모드에서 수행한다. 만약 루트킷이 유저 모드에만 있을 경우 Ring 0의 명령어들을 사용할 수 없으므로 지금과 같이 강력한 루트킷이 존재할 수 없다.

커널 모드에 있는 루트킷은 제한 없이 보안에 접근이 가능하며, 이는 운영체제와 같은 보안 등급을 가지고 운영체제의 작업을 가로채거나 손상시키는 등의 조작을 할 수 있으므로 탐지와 제거가 어렵다. 이러한 경우 시스템의 어떠한 요소도 신뢰할 수 없게 되며 안티바이러스 제품 또한 마찬가지로 취약하게 된다. 

루트킷은 컴퓨터에 접근하거나 일반적으로 허용되지 않는 영역에 접근할 수 있도록 설계된다. 일반적으로 악성코드가 시스템에 설치된 후, 들키지 않고 계속 남아 악의적인 기능을 수행하고자 할 것이다. 루트킷은 이러한 목적과 맞물려 사용되는데, 주로 설치가 자동으로 이루어지며, 공격자는 알려진 취약점 공격이나 패스워드 등을 통해 루트 권한이나 관리자 접근 권한을 획득한다. 이렇게 한번 설치되면 접근 권한을 유지하는 것뿐만 아니라 침입 사실을 숨기며 자신이나 다른 악성코드를 은닉하여 사용자로부터 탐지되지 않으려 한다.

프로세스를 은닉하는 방법으로 윈도우 커널에서 사용하는 Direct Kernel Object Manipulation(DKOM)을 사용하여 데이터 구조를 수정한다. 또한 커널 모드 루트킷은 System Service Descriptor Table(SSDT)를 후킹 할 수 있으며 커널의 기능을 손상시키기 위해 System Call Table을 수정할 수 있다.

높은 권한을 가질 수 있는 루트킷은 자신을 찾고자 하는 소프트웨어를 수정하거나 파괴할 수 있고, 또한 작업 관리자나 Process Explorer로부터 프로세스의 목록을 수정하므로, 자신이나 다른 추가적인 악성코드의 존재를 숨길 수 있다. 만약 침입자가 시스템의 기본 관리 도구를 루트킷으로 대체한다면, 침입자는 시스템의 루트 권한을 얻음과 동시에 정상적인 시스템 관리자로부터 이러한 활동을 은폐할 수 있다. 따라서 루트킷을 탐지하고 완전히 제거하는 것은 어렵다. 특히 루트킷이 커널에 상주하고 있을 경우 더욱 어려워지며 대부분의 경우 이는 운영체제를 재설치하여 해결할 수밖에 없다. 최근의 루트킷은 단순히 접근 권한을 상승시키지 않고, 다른 악성코드와 함께 스텔스 기능을 추가하여 그들의 페이로드를 감추도록 한다. 또한 단순히 프로세스를 숨기는 용도가 아니라 루트킷을 제거하려는 시도가 감지되었을 때 이에 대하여 방해하는 루틴 또한 가지고 있는 경우가 있기에 더욱 유의하여야 한다.

3.9 Exploit

Exploit은 해커가 PC에 침투하고자 공격할 때 사용하는 단어이다. 이러한 단어가 악성코드에도 붙게 된 것은 운영체제나 특정 프로그램의 취약점을 찾도록 설계되기 때문이다. 이러한 취약점은 주로 프로그래머가 실수로 놓친 부분이나, 프로그래머가 전혀 생각하지 못한 부분 등을 공격하는 방식으로 이루어진다. 

이러한 취약점은 공격자가 직접 수동으로 할 수 있지만, 악성코드로 제작하여 배포할 경우 더 많은 사용자에게 자동으로 공격해주므로 더욱 수월해진다. 만약 취약한 부분이 이미 모두 업데이트되어 사라졌다면 해당 Exploit은 아무런 효력을 갖지 못하기 때문에, 실제 Exploit에 대한 예방 방안과 같이 지속적인 보안 업데이트를 유지해야만 한다.

3.10 Botnet

봇넷은 수많은 봇들이 연결된 네트워크로 봇들이 지정된 작업을 수행하도록 통제하기 위하여 연결되어 있다. 일반적으로 Internet Relay Chat (IRC)를 통해 연결되어, 스팸 메일을 보내거나 DDoS 공격 등에 사용될 수 있다. 이러한 봇들은 악성코드에 의해 침투되었을 때 자동으로 생성되거나, 직접 공격자가 컴퓨터에 침투하여 생성하기도 하며, 이렇게 생성된 봇넷을 통제하는 것은 IRC나 HTTP와 같은 표준 네트워크 프로토콜의 형태이다. 봇넷 악성코드는 일반적으로 컴퓨터가 공격자에 의한 명령을 받고 조작될 수 있게 하는 모듈을 설치하며 호스트 컴퓨터에게 연결을 요청하는 패킷을 보낸다. 패킷을 통해 연결이 진행되면 범죄를 목적으로 원격에서 그룹을 제어할 수 있으며 이러한 제어는 Command-and-Control (C&C) 서버에 의하여 이루어진다. 

봇넷을 통해 어떠한 공격이 이루어지는 경우를 알아보자. 우선 봇넷 제작자들은 봇으로 만드는 코드를 포함한 바이러스나 웜을 통해 많은 사용자들의 컴퓨터를 감염시키고자 하며, 봇에 감염된 PC는 C&C 서버와 연결하게 된다. 이렇게 제작자가 많은 봇을 소유하고 있을 때 이를 사용하고자 하는 고객이 금액을 지불하고 수많은 봇넷을 이용할 수 있다. 이러한 과정 중에 봇으로 사용된 PC는 자신이 사용되었다는 것조차 알 수 없는 경우가 많다. 새로운 고객이 봇넷의 제작자에게 다시 어떠한 요청을 하더라도 다시 사용될 수밖에 없다.

3.11 Scareware

스케어웨어(Scareware)는 Scare(겁 주다)와 Software의 합성어다. 이름과 같이 주로 사용자를 깜짝 놀라게 하거나 겁을 주는 형태로 동작하는데, 악성코드처럼 보이지만 실제로 악의적인 기능을 하지 않는다. 보통 실제 악성코드에 감염되지 않았음에도 불구하고, 악성코드 감염을 탐지하였으므로 자사의 안티바이러스 제품을 구매하여 이를 제거해야 한다는 식으로 구매를 유도하는 용도로 많이 사용되고 있다. 이 경우 실제 제품을 구매하더라도 제거되는 것은 바로 스케어웨어이다.

로그 웨어(Rogueware) 또한 이러한 스케어웨어의 변종으로 합법적인 소프트웨어처럼 보이지만 실제로는 사용자를 속이기 위한 상품 광고인 경우가 있다. 이렇듯 대부분의 스케어웨어는 안티바이러스 제품으로 위장하고 있다. 하지만 스케어웨어 또한 점차 진화하여 추가적인 보안 프로그램 설치를 유도하며 사용자가 추가적인 악성코드를 다운로드하도록 한다. 실제 스케어웨어가 진짜 안티바이러스 제품과 유사하게 제작되는 만큼 사용자는 이에 대해 신뢰할 수밖에 없게 된다.

Reference

https://ko.wikipedia.org/wiki/컴퓨터_바이러스

https://ko.wikipedia.org/wiki/웜

https://www.ahnlab.com/kr/site/securityinfo/secunews/secuNewsView.do?menu_dist=2&seq=21481

https://en.wikipedia.org/wiki/Potentially_unwanted_program

https://ko.wikipedia.org/wiki/트로이_목마_(컴퓨팅)

http://yjlee.delighit.net/tag/스케어웨어

https://en.wikipedia.org/wiki/Spyware

https://en.wikipedia.org/wiki/Rootkit

http://malware.wikia.com/wiki/Rootkit

http://codeengn.com/archive/Reverse%20Engineering/Rootkit/Rootkit%20%5Bmoltak%5D.pdf

https://en.wikipedia.org/wiki/Botnet

https://securingthehuman.sans.org/newsletters/ouch/issues/OUCH-201402_kr.pdf

http://jsblab.com/30046494923

http://sergeswin.com/1127#

http://skccblog.tistory.com/837

http://proneer.tistory.com/entry/백도어에-대한-이해

악성코드 분석 방법

악성코드를 분석하는 방법에 있어 분석가에 따라 이를 다르게 정의하는 경우가 많다. 따라서 이번에 다룰 내용은 일반적으로 언급되는 4가지 방법을 기준으로 정의하고 설명할 것이다. 아래의 그림을 보자.

그림 1. 분석 방법

그림에서 보듯이 자동화 분석, 정적 분석, 동적 분석, 상세 분석과 같이 4가지 항목으로 분류 할 수 있다. 여기서 말하는 난이도란, 분석가의 입장에서 이러한 방법을 사용할 때 필요한 시간, 지식 등을 고려했을 때를 나타낸 것이다. 이러한 4가지 항목에 대하여 낮은 난이도를 기준으로 하여 하나씩 알아보자.

자동화 분석

자동화 분석은 악성코드의 급격한 증가로 인해 점차 이에 대하여 많은 시간과 인력이 필요하게 되었다. 하지만 모든 악성코드를 수동으로 분석하기에는 이러한 요소들이 많이 부족하다. 그렇기에 악성코드를 자동으로 분석해주는 방법이 지속적으로 발전하고 있다.

의심되는 파일이 있을 때 가장 손쉽게 접근하는 방법이 자동화 분석이다. 이러한 자동화 분석 도구를 직접 제작하는 것은 많은 시간과 노력이 소요되지만, 현재 이러한 자동화 분석 도구가 상용이나 무료로 많이 배포되기 때문에 이들을 이용하면 된다.

대개 자동화 분석 도구를 이용하면 보고서 형식으로 어떠한 레지스트리 키가 변화하였는지, 어느 주소와 통신이 이루어졌는지 등 자세하게 정리하기 때문에 빠르게 분석해야 하는 상황에 그 효과는 더욱 용이하다.

그림 2. 자동화 분석 도구

하지만 자동화 분석이 장점만 갖는 것은 아니다. 자동화라는 단어에서와 같이, 해당 도구는 제작된 형태로만 작동한다는 것이다. 이는 생각보다 많은 오류를 범할 수가 있다. 만약 악성코드가 특정한 명령어 옵션을 필요로 할 때, 자동화 도구들은 이를 명령어 없이 실행하는 경우가 있다. 이 경우 악성코드는 악의적인 행위를 하지 않으므로, 악성코드라 판별 되지 않을 수가 있다. 이외에도 단점에 대해서도 살펴보면 다음과 같다.

1. 자동화 분석 도구를 구축하는데 시간이 오래 걸리며, 분석환경을 구성하기 위해 비용과 노력이 들어간다. 예를 들면 윈도우 악성코드를 분석하고자 윈도우 운영체제를 설치하는데 라이선스 비용이 들어가며, 특정 플랫폼에서만 동작하는 악성코드일 경우 그 버전에 맞는 플랫폼과 환경을 구성하는데 노력이 들어간다.
2. 악성코드가 Anti-VM 기능을 가지고 있을 경우, 이에 대하여 우회하지 못한다. 우회하기 위해선 가상머신을 튜닝하는 노력과 비용이 따른다. 이러한 문제를 해결하기 위해 실 환경을 도입할 수 있지만,  이 경우도 물리적 하드웨어의 구성에 따른 추가 비용이 따른다.
3. 분석 방법이 자동화 분석 제작자의 의도대로만 분석이 가능하다는 점이 직접 분석하는 것과는 다른 결과를 보여준다. 이러한 경우 단편적인 면만 보게 되어 본질적인 악성코드의 행위를 판단할 수 없다.
4. 악의적인 행위란 사람의 기준으로 분류하는 요소이다. 이는 시그니처나 패턴을 통해 악성코드의 유무를 탐지하는 자동화 시스템의 경우, 악성코드가 악의적인 행위를 하지 않는 것으로 판단할 수 있다는 것이다. 따라서 악의적인 행위의 정확한 판단을 위해서는 전문가의 시선이 필요하다. 

이와 같이 자동화 분석에 대하여 알아보았다. 자동화 많은 부분에 있어 분석가의 시간을 단축해주는 사실은 분명하다. 하지만 결코 완벽하지 않기 때문에 분석가가 직접 분석을 하는 상황도 필요하다. 다음 절부터 이러한 직접 분석 방법에 대하여 알아보자.

정적 분석

정적 분석이란 악성코드를 실행하지 않고 그 자체가 갖고 있는 내용들을 통해 악의적인 여부를 진단하는 것이다. 그렇기에 비교적 쉽고 빠르며, 별도의 지식 없이 이러한 정보들을 수집할 수가 있다. 모든 파일들은 자신만의 해시를 갖거나, 사용되는 API, 그리고 문자열 등을 갖는다. 분석가는 이러한 요소들이 나타나 있는 파일을 발견했을 때, 추가적인 분석 여부나 이후 분석 방향에 대하여 선정할 수 있게 도움을 준다.

해시 값의 경우 VirusTotal과 같이 많은 백신들의 엔진을 통해서 비교하여 결과를 출력할 수가 있다. 만약 파일이 이미 악성코드로 판단된 해시 값을 갖는다면, 해당 안티 바이러스 제품들의 조치를 취할 것이다. 하지만 해시 값의 경우 악성코드가 자가 변조를 할 수 있는 경우 완전히 신뢰할 수 없게 된다.

이외에도 EXE, DLL, SYS 등의 경우 PE 구조를 가지고 있는데, 이러한 PE 구조에서 악성 행위와 관련된 정보들을 파악할 수가 있다. 사용되는 API와 문자열의 경우 중요한 정보를 갖는다. 사용되는 API의 목록을 가지는 IAT(Import Address Table)의 경우 어떠한 DLL을 필요로 하며, 해당 DLL에서 어떠한 함수를 사용하는지 확인할 수가 있다. 이는 꽤 중요한 지표가 되는데 만약 계산기가 네트워크와 관련된 DLL을 임포트하며, socket과 같은 API를 사용한다면, 이는 충분히 추가적인 분석을 진행할 요지를 갖는다.

문자열의 경우에도 새로운 프로세스나 파일을 생성하거나 제거, 외부 통신을 위한 IP 주소, 지속성을 위해 레지스트리에 남기는 키 값 등 악성코드의 기능과 직접적으로 관련된 문자를 포함하고 있을 수 있다. 이렇게 IAT와 문자열을 서로 비교하면 행위에 대한 큰 틀을 작성할 수 있다.

정적 분석에 사용할 수 있는 도구는 다른 방법에 비하여 비하여 많다. 이는 PE 구조를 갖는 파일의 경우 PE구조를 직접 분석할 수 있다면 헥사 값을 통해 이를 확인할 수도 있을 만큼 단조롭기 때문에, 제작이 상대적으로 쉽기 때문이다. 아래의 표에 필자가 사용해본 적이 있거나 사용하고 있는 몇 가지 도구를 적어놓았다.

표 1. 정적 분석 도구

이렇게 정적 분석을 통해 확인할 수 있는 요소들에 대하여 알아보았다. 분명 간단하고 쉽게 유용한 정보들을 확인할 수 있다는 점에선 틀림없다. 하지만 악성코드들도 점차 진화함에 따라, 현대의 악성코드들은 패킹이나 난독화와 같은 방법을 사용하여 이러한 정보를 확인할 수 없도록 한다. 따라서 이러한 경우 각 방법에 맞게 언패킹을 진행하거나 난독화를 풀어야 한다. 여기서 언패킹 된 파일은 패킹 되었던 정보를 노출 시키기 때문에, 패킹의 여부가 확인되었다면 이를 언패킹하는 것 또한 정적 분석의 과정이라 할 수 있다.

정적 분석에 대하여 알아보았으며 여기서 가장 중요한 것은 API나 문자열을 통해 확인하였을 때, 악의적인 기능으로 보이는 요소들이 있다고 해서 이를 무조건 악성코드라 단정지으면 안 된다는 것이다. 이는 하나의 의심되는 요소일 뿐이지 이것이 해당 파일의 전체 기능인 경우는 아니다. 따라서 이후 분석 과정이 필요하며, 정적 분석을 통해 수집된 정보는 동적 분석과 상세 분석을 함에 있어 방향을 잡도록 해주는 요소이어야 한다.

동적 분석

의심되는 파일을 실행하지 않는 정적 분석과는 다르게, 동적 분석은 해당 파일을 실행하므로 나타나는 변화를 모니터링하며 어떠한 기능을 수행하는지 확인한다. 의심되는 파일이 실제 악성 행위를 할 수 있으므로, 보통 가상 환경에서 동적 분석을 수행한다. 가상환경에서 독립된 네트워크와 같이 필요한 설정들을 구축한 뒤, 동적 분석 도구들을 통해 어떠한 동작을 하는지 확인한다.

먼저, 의심되는 파일을 실행했을 때 생성되는 프로세스를 살펴보아야 한다. 어떠한 이름의 프로세스가 생성되는지 확인하며, 하위 프로세스로 생성되는 것이 있다면 이에 대해서도 추가적인 분석이 필요하다. 프로세스를 모니터링 하는 것이 중요한 이유는, 악성코드를 실행했을 때, svchost.exe나 explorer.exe와 같이 윈도우 기본 프로세스와 같은 이름으로 실행되는 경우가 있기 때문에 이를 모니터링 하여야 한다. 프로세스 모니터링에는 작업관리자를 통해 관찰 할 수도 있지만, Process Explorer와 같이 강력한 툴을 이용하면 어떠한 DLL을 포함하고 있는지 까지 상세하게 확인할 수 있다.

악성코드가 프로세스를 진행하며 어떠한 파일에 변화가 생기는지 확인하는 것 또한 중요하다. 파일과 관련하여 악의적인 기능으로 랜섬웨어와 같이 파일이 암호화 되는 경우가 있지만, 그 외에도 특정 파일이 생성되거나 삭제되는 경우도 있다. 이러한 경우 이는 악성코드의 행위에 관한 중요한 단서가 된다.. 예를 들어, 네트워크를 통해 파일을 생성할 수도 있으며, 자기 자신을 특정 폴더로 이동시킨 뒤 레지스트리에 등록하여 지속성을 유지하고자 하는 경우도 많다. 따라서 파일과 관련하여 나타나는 변화를 유심히 관찰하여야 한다.

파일과 관련하여 레지스트리와 네트워크에 대해서도 알아보자. 레지스트리의 경우 남겨진 파일과 관련하여 윈도우 부팅 시 자동으로 실행되게 하거나, 서비스로 등록하여 이후에 확인을 더 어렵게 만든다. 따라서 레지스트리에 대한 변화를 관찰하여야 한다.

네트워크의 경우, 어떠한 곳과 어떠한 네트워킹이 일어나는지 파악하는 것이 중요하다. 악성코드가 네트워크를 통해 특정한 곳에서 추가적인 파일을 다운 받을 수가 있으며, 사용자가 입력하는 키 이벤트를 네트워크를 통해 보낼 수도 있다. 또한 이후 백도어 기능을 위하여 특정 포트를 열어놓기도 한다. 이처럼 네트워크 기능이 추가된다면 패킷에 대하여 분석이 필요하다.

표 2. 동적 분석 도구

위의 표는 분석에 사용되는 도구들을 몇 가지 정리한 것이다. 상황에 따라 더 많은 도구가 필요하기도 하고, 더 적은 도구가 필요하기도 하다. 따라서 각 도구에 대하여 사용 방법을 알고 있어야 한다. 하지만 이러한 도구들을 통해 모니터링을 해도 동적 분석의 한계가 존재한다.

우선 동적 분석의 가장 큰 단점이란, 해당 파일을 실행해야 한다는 것이다. 실제 환경에서 해당 파일을 실행하면 감염되기 때문에, 이후 이를 치료하거나 다시 실행 환경을 만들기에 큰 위험성과 수고가 따른다. 그러므로 대개 가상 환경에서 분석을 진행한다. 하지만 가상환경에서 분석을 진행하는 것에 있어 몇 가지 단점을 1.1 자동화 분석에서도 언급하였다. 1.1에서 명령어 옵션을 지정해줄 수 있다는 점을 제외한 나머지 단점 4가지가 마찬가지로 해당된다.

따라서, 랜섬웨어나 키로깅 같이 행위가 명확한 악성코드는 동적 분석만으로도 정확히 어떠한 행위를 하는지 판단이 가능하지만, 백도어나 일정시간 잠복기를 갖는 경우 아무런 증상이 나타나지 않기 때문에 어렵다. 또한 분석가가 직접 행동하며 판단하는 것이기 때문에, 놓치는 항목이 있을 수 있다. 이러한 이유들로 인하여 이후의 상세 분석이 필요하다.

상세 분석

앞의 분석 과정들을 통하여 악성코드 행위에 대하여 살펴볼 수 있지만, 모든 부분에 대하여 다룰 수 있는 것은 아니다. 또한 놓치는 요소가 존재할 수 있다고 언급하였다. 상세 분석 과정에서는 악성코드의 행위에 대하여 상세하게 다룰 수가 있다. 이에 대해 알기 전에 컴파일과 디스어셈블에 대하여 알아보자.

그림 3. 컴파일과 디스어셈블

우선 악성코드에 가장 자주 쓰이는 C와 C++등으로 코드를 작성하면 컴파일을 진행한다. 컴파일은 해당 언어로부터 하드웨어가 읽을 수 있도록 하기 위한 2진수 코드로의 변환작업이다. 이렇게 2진수의 형태로 된 코드는 인간이 읽을 수 없다. 따라서 디스어셈블이라는 과정이 필요하다. 디스어셈블을 통해 2진수 코드에서 어셈블리 언어로 변환이 이루어진다. 디스어셈블링된 코드를 통해 상세 분석이 가능해진다.

우리가 일반적으로 사용하는 C나 C++, Python 등에 비하여 어셈블리 언어는 가독성이 떨어지며 생소하다. 그렇기에 상세 분석 과정에서는 어셈블리 언어에 대한 지식과 디스어셈블러에 대한 지식 등이 필요하다. 이렇게 디스어셈블링된 코드에는 어떠한 API가 호출되며, 해당 API에 어떠한 인자가 사용되는지 확인할 수가 있다. 또한 코드를 직접 하나씩 실행해가며 흐름을 추적할 수가 있다. 이러한 요소들로 인해 이전에는 놓쳤던 요소들을 파악할 수 있다.

상세 분석 과정에 사용되는 도구는 다른 과정보다 적다. 목적에 따라 사용방법이 조금씩 상이하지만, 하나의 도구를 잘 다루는 것이 어중간하게 여러 개 다루는 것보다 좋다. 사용되는 도구와 용도는 아래의 표와 같다.

표 3. 상세 분석 도구

분명히 디스어셈블링을 통한 분석은 많은 정보를 주지만, 그만큼 과정이 어렵다. 안티디버깅 기법에 따라 더욱 복잡해지기 때문에 어셈블리뿐만 아니라 이러한 기법 또한 학습이 필요하다. 제대로 이러한 요소들을 다룰 수 있게 된다면, 하나의 악성코드에서부터 많은 정보들을 알 수가 있다.

이렇게 총 4가지 분석 과정에 대하여 알아보았다. 이러한 분석 과정들을 각 각 방법이 다르다 하여 하나의 개별적인 요소로 간주하면 안 된다. 자동화 분석에서부터 상세 분석에 이르기까지 모든 분석 과정은 연계되어야 하며, 이전의 과정들을 통해 하나의 방향을 잡으며 다음 과정을 통해 좀 더 구체적으로 파악하는 방식이 되어야 한다.

참고 자료

[+] 악성코드 4가지 분석 방법, "Mastering 4 Stages of Malware Ananlysis"

• zeltser.com/mastering-4-stages-of-malware-analysis

[+] 무료 악성코드 자동화 분석 도구, "Malware Analysis tool frameworks"

• zeltser.com/malware-analysis-tool-frameworks

[+] 각 분석 확인 요소, "09 동적 분석과 정적 분석"

• blog.daum.net/boy7407/17463080

[+] 컴파일과 어셈블리, "So You Want to be a malware analyst"

• blog.malwarebytes.org/intelligence/2012/09/so-you-want-to-be-a-malware-analyst/

선호 경로

악성코드는 보통 자신의 존재를 은닉하고자 하며, 떄로는 사용자로부터 간단한 방법을 통하여 속이고자 한다. 우선 파일의 이름을 실제 윈도우 파일과 비슷하게 kernei32.dll 로 변경하는 등 다양한 방법을 사용한다. 그 중에서 경로를 통하여 은닉하고자 할 때 주로 쓰이는 경로는 아래와 같다. 한번 살펴 보자.

# 시스템 폴더

시스템 폴더는 윈도우의 주요 시스템 파일이 존재하는 곳으로 은닉을 위해 시스템 파일과 파일명을 유사하게 변경하거나 경로를 바꿔 저장한다. 자주 사용되는 경로는 다음과 같다.

SysWOW64는 64비트 시스템에서만 존재하는 폴더로 32비트와의 호환성을 위해 존재하는 폴더이다. “%SystemRoot%\system32\” 폴더에 64비트 시스템 파일이 위치한다면 “%SystemRoot%\SysWOW64\”에는 32비트 시스템 파일이 위치한다. 따라서, 64비트 시스템에서는 2개의 폴더를 모두 조사할 필요가 있다.

# 사용자 기본 폴더

윈도우 비스타 이후부터 사용자의 홈 폴더는 “%SystemDrive%\Users\” 하위에 존재한다. 해당 폴더 하위를 살펴보면 사용자의 홈 폴더 이외에도 기본 폴더인 “Public(공용)”, “Default”가 존재한다. “Public” 폴더에는 각 사용자가 공통으로 가지는 파일(공용 사진, 비디오 등)이 저장되어 있고, “Default” 폴더에는 새로운 사용자 생성 시 초기 구성을 위한 파일이 저장되어 있다. 이런 폴더는 일반적으로 직접 들어가지 않기 때문에 공격자가 자주 은닉의 대상으로 삼는다. 또한 “Default”에 악성코드를 위치시키면 새로운 사용자가 생성될 때마다 자동 복사되기도 한다.

# 사용자 데이터 폴더

각 사용자의 응용프로그램 데이터가 저장되는 데이터 폴더는 숨긴 폴더이기 때문에 폴더 속성을 변경해야만 나타난다. 데이터 폴더도 일반적으로는 들어가지 않기 때문에 해당 경로가 악성코드 은닉에 자주 사용된다.

# 휴지통 폴더

윈도우의 휴지통 폴더는 운영체제에 의해 보호되어 있기 때문에 폴더 속성을 변경해야만 나타난다. 휴지통 폴더 하위에는 각 사용자의 SID 폴더가 나타나도 SID 폴더에 각 사용자가 삭제한 파일이 위치한다. 바탕화면에서 살펴보는 휴지통 내용은 로그인 사용자의 SID 폴더 내용이다. 악성코드는 휴지통 하위 SID 폴더와 동일한 수준으로 자주 은닉한다.

# 시스템 볼륨 정보 폴더

시스템 복원 지점이나 볼륨 섀도 복사본이 저장되는 시스템 볼륨 정보 폴더는 운영체제에 의해 보호되어 있다. 폴더 속성을 변경하면 폴더의 존재는 확인할 수 있지만 폴더 내용은 확인할 수 없다. 폴더 내용을 확인하기 위해서는 폴더의 접근 권한을 변경해주어야 한다. 따라서, 악성코드를 장기간 안전하게 은닉할 수 있고 일부 보안 솔루션은 이런 이유로 해당 폴더 하위를 진단하지 못하기 때문에 악성코드가 종종 사용한다.

# 임시 폴더

임시 폴더는 공격자가 의도하기 보다는 악성코드가 시스템에 자동 유입되거나 드롭퍼가 드롭할 때 임시로 사용하는 경로로 악성코드의 복사본이 자주 존재한다.

# 웹 브라우저 다운로드 경로

웹 브라우저의 기본 다운로드 경로나 액티브 X, 자바 애플릿 경로 등도 웹 브라우저를 이용하는 악성코드가 다운되어 있을 가능성이 많다.

# 알려진 폴더

조직마다 공통된 사양의 표준 PC를 사용하다보니 모든 사용자에게 공통으로 존재하는 폴더가 있다. 특정 조직을 공격할 때 이런 폴더들이 종종 사용되곤 한다.

# 그 밖에 폴더

앞서 언급한 폴더 이외에도 악성코드가 자주 위치하는 경로는 다음과 같다.

Reference

nt!_PEB
+0x000 InheritedAddressSpace : UChar
+0x001 ReadImageFileExecOptions : UChar
+0x002 BeingDebugged : UChar
+0x003 SpareBool : UChar
+0x004 Mutant : Ptr32 Void
+0x008 ImageBaseAddress : Ptr32 Void
+0x00c Ldr : Ptr32 _PEB_LDR_DATA
+0x010 ProcessParameters : Ptr32 _RTL_USER_PROCESS_PARAMETERS
+0x014 SubSystemData : Ptr32 Void
+0x018 ProcessHeap : Ptr32 Void
+0x01c FastPebLock : Ptr32 _RTL_CRITICAL_SECTION
+0x020 FastPebLockRoutine : Ptr32 Void
+0x024 FastPebUnlockRoutine : Ptr32 Void
+0x028 EnvironmentUpdateCount : Uint4B
+0x02c KernelCallbackTable : Ptr32 Void
+0x030 SystemReserved : [1] Uint4B
+0x034 AtlThunkSListPtr32 : Uint4B
+0x038 FreeList : Ptr32 _PEB_FREE_BLOCK
+0x03c TlsExpansionCounter : Uint4B
+0x040 TlsBitmap : Ptr32 Void
+0x044 TlsBitmapBits : [2] Uint4B
+0x04c ReadOnlySharedMemoryBase : Ptr32 Void
+0x050 ReadOnlySharedMemoryHeap : Ptr32 Void
+0x054 ReadOnlyStaticServerData : Ptr32 Ptr32 Void
+0x058 AnsiCodePageData : Ptr32 Void
+0x05c OemCodePageData : Ptr32 Void
+0x060 UnicodeCaseTableData : Ptr32 Void
+0x064 NumberOfProcessors : Uint4B
+0x068 NtGlobalFlag : Uint4B
+0x070 CriticalSectionTimeout : _LARGE_INTEGER
+0x078 HeapSegmentReserve : Uint4B
+0x07c HeapSegmentCommit : Uint4B
+0x080 HeapDeCommitTotalFreeThreshold : Uint4B
+0x084 HeapDeCommitFreeBlockThreshold : Uint4B
+0x088 NumberOfHeaps : Uint4B
+0x08c MaximumNumberOfHeaps : Uint4B
+0x090 ProcessHeaps : Ptr32 Ptr32 Void
+0x094 GdiSharedHandleTable : Ptr32 Void
+0x098 ProcessStarterHelper : Ptr32 Void
+0x09c GdiDCAttributeList : Uint4B
+0x0a0 LoaderLock : Ptr32 Void
+0x0a4 OSMajorVersion : Uint4B
+0x0a8 OSMinorVersion : Uint4B
+0x0ac OSBuildNumber : Uint2B
+0x0ae OSCSDVersion : Uint2B
+0x0b0 OSPlatformId : Uint4B
+0x0b4 ImageSubsystem : Uint4B
+0x0b8 ImageSubsystemMajorVersion : Uint4B
+0x0bc ImageSubsystemMinorVersion : Uint4B
+0x0c0 ImageProcessAffinityMask : Uint4B
+0x0c4 GdiHandleBuffer : [34] Uint4B
+0x14c PostProcessInitRoutine : Ptr32 void 
+0x150 TlsExpansionBitmap : Ptr32 Void
+0x154 TlsExpansionBitmapBits : [32] Uint4B
+0x1d4 SessionId : Uint4B
+0x1d8 AppCompatFlags : _ULARGE_INTEGER
+0x1e0 AppCompatFlagsUser : _ULARGE_INTEGER
+0x1e8 pShimData : Ptr32 Void
+0x1ec AppCompatInfo : Ptr32 Void
+0x1f0 CSDVersion : _UNICODE_STRING
+0x1f8 ActivationContextData : Ptr32 Void
+0x1fc ProcessAssemblyStorageMap : Ptr32 Void
+0x200 SystemDefaultActivationContextData : Ptr32 Void
+0x204 SystemAssemblyStorageMap : Ptr32 Void
+0x208 MinimumStackCommit : Uint4B

packers.pdf

http://corkami.googlecode.com/files/packers.pdf

Packers are most commonly used for compression, code obfuscation, and malware anti-reversing. While not always malicious, packers are often a clue to look a little deeper into a particular binary. Ange Albertini did a marvelous job of representing the (known) universe of executable packers in this infographic.

Contents of the TIB (32-bit Windows)[edit]

참고

https://en.wikipedia.org/wiki/Win32_Thread_Information_Block#Accessing_the_TIB        ; FS 레지스터를 참고한 사이트

https://en.wikipedia.org/wiki/Process_Environment_Block                                ; FS:[0x30]에 있는 PEB에 관한 더 자세한 자료