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를 이용한 악성코드 시그니처 확인)

악성코드 분석 방법

악성코드를 분석하는 방법에 있어 분석가에 따라 이를 다르게 정의하는 경우가 많다. 따라서 이번에 다룰 내용은 일반적으로 언급되는 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/

Ransomware_Micro.pdf

* 참고 : PDF를 기준으로 만든 내용이기 때문에, 포스팅보다는 PDF 파일을 보는 것이 더 좋습니다.

1. 요약

대상 악성코드에 대해 이후에 분석한 내용을 정리한 페이지다. 해당 악성코드는 랜섬웨어로 파일들을 암호화 하여 금액을 요구한다. 암호화 방식은 RSA 방식을 사용하며, 암호화 대상 파일은 크기가 32 Bytes에서 327,155,712 Bytes 사이에 있을 경우에 암호화 된다. 만약 파일의 크기가 이에 해당하지 않을 경우 진행되지 않는다.

그림 1. Malware Summary

   최초 26.exe를 실행할 경우 %AppData%\Roaming에 새로운 이름으로 같은 파일을 생성 한 뒤 이를 실행한다. 이렇게 실행된 새로운 프로세스는 vssadmin 명령을 통해 볼륨 쉐도우를 제거하는 작업을 수행하는 스레드를 생성한다. 또한 CMD나 작업관리자, 또는 Process Explorer와 같은 프로세스의 실행 및 동작을 방해하도록 이들을 계속 종료한다.

  암호화가 진행되는 동안 해당 프로세스는 자기 자신을 레지스트리에 지속성을 위하여 등록한다. 하지만 여기서 말하는 지속성이란, 암호화가 완료되지 않은 채로 PC가 종료되었을 경우 다시 PC가 부팅되었을 때 암호화를 마저 진행하도록 하기 위함이다. 랜섬웨어는 모든 암호화가 완료되었을 경우, 자기 자신을 삭제한 뒤 프로세스 또한 종료한다.

2. 개요

분석하고자 하는 대상 악성코드는 랜섬웨어(Ransomware)로 파일을 암호화하여 이에 대하여 금전적인 요구를 강요하는 것이다. 일반적으로 랜섬웨어의 경우 복잡한 암호화 알고리즘을 사용하는 것이 대부분이기 때문에, 실질적으로 복구는 힘들다. 따라서 암호화 키를 찾는 것이 아닌, 어떻게 랜섬웨어가 동작하는지 확인하기 위하여 분석을 진행할 것이다.

  악성코드를 분석하는데 있어 크게 2 단계로 나누어 살펴볼 것이다. 동적 분석과 정적 분석으로, 동적 분석은 악성코드를 직접 실행시키므로 나타난 결과들에 대하여 살펴볼 것이다. 반대로 정적 분석의 경우 악성코드를 디버거를 통해 실행했을 때의 결과에 대하여 살펴볼 것이다. 필요하다면 메모리 분석 기법까지 사용할 것이다. 각 분석에 사용된 도구들은 다음의 표와 같다.

표 1. 사용 도구

  위의 도구들을 이용하여 전체적인 분석을 진행하였다. 동적 분석을 먼저 진행하여 어떠한 동작들이 이루어지는지 확인한 뒤, 정적 분석을 통해 이에 대하여 좀 더 구체적으로 알아볼 것이다.

3. 동적 분석

동적 분석은 악성코드를 실행하므로 나타나는 증상에 대하여 정리한 페이지다. 이러한 동적 분석을 통해, 나타나는 결과들을 명확하게 확인할 수 있다는 장점이 있다. 다만, 실행할 때 가상 환경에서 진행하여야 한다는 점과 놓치는 측면이 있을 수 있다는 단점이 존재한다. 분석 환경은 Windows 7 x64이며 구분을 위하여 최초 실행하는 악성코드의 이름은 26.exe로 변경 후 분석을 진행하였다.

3.1 Process 분석

해당 악성코드를 실행하면 새로운 프로세스를 생성한다. 여기서 해당 프로세스의 이름은 무작위로 정해진다. 분석을 하면서 생성된 프로세스의 이름이 ltwpiwd.exe였다. 해당 파일의 위치를 찾아 해시 값을 비교해본 결과, 최초 26.exe와 같은 해시 값을 가지고 있었다. 따라서 26.exe는 자신을 감추기 위해, 본래의 26.exe를 제거하고 새로운 파일을 %AppData%\Roaming\에 생성한 뒤 이를 실행한다.

그림 2. Process Hacker

  암호화 동작을 진행하며 볼륨 섀도우 카피와 관련된 프로그램들이 실행되는 것을 확인할 수가 있다. 이는 VSS를 통해 데이터 복구하는 것을 방지하기 위하여 존재하고 있는 VSS를 제거하는 동작(vssadmin delete shadows /all / Quiet)을 한다. 또한 암호화가 진행되는 동안 HELP_RECOVER_instructions+pgv(이하 Help파일) 라는 암호화를 풀기 위한 방법을 나타내는 파일이 Txt, Html, Png의 형태로 각 폴더에 생성된다.

  여기서 해당 프로세스가 진행되는 동안 cmd.exe, ProcessExp 등을 비롯한 몇 가지 프로그램이 계속 종료되는 현상이 나타났다. 이는 랜섬웨어 파일이 분석 또는 감염자가 다른 행동을 하지 못하도록 하기 위함으로 보인다. 암호화가 완료된 후, HELP파일들이 ltpiwd.exe의 하위 프로세스로 txt, html, png로생성된다. 그 후 해당 프로세스는 종료한다. Help 파일 중 html은 아래의 그림을 보자.

그림 3. HELP_RECOVER_instructions+pgv.html

  해당 내용을 확인해보면, 전형적인 랜섬웨어가 가지는 특성을 보인다. RSA 암호화 방식을 사용하고 있으므로 해제가 어려울 것이다라는 것을 경고하며, 퍼스널 홈 페이지를 제공한다. 각 페이지에 접속을 시도해본 결과 현재 접근할 수 없는 페이지로 나타난다.

3.2 MFT 분석

MFT에는 파일에 대한 메타정보들이 저장되어 있다. 여기서 $UsnJrnl에는 저널 로그가 기록되어있으며 $LogFile에 비하여 상대적으로 기록할 수 있는 로그의 크기가 크다. 따라서 $LogFile을 통해 트랜젝션 로그를 살펴볼 수 있으며, $UsnJrnl을 통해서는 많은 양의 저널 로그를 살펴볼 수 있다.

  일반적으로 랜섬웨어의 경우 많은 이벤트들이 발생하기 때문에, $LogFile의 경우 많은 부분이 덮어씌워진다. 따라서 해당 랜섬웨어가 초반에 남기는 정보들이 지워지게 된다. 이 경우 $UsnJrml을 확인할 경우 상대적으로 $LogFIle에 비하여 기록이 남아 있는 확률이 높다. 그러므로 각 용도에 맞게 이를 참고하면 된다.

표 2. NTFS Log Tracker

  위 표는 랜섬웨어가 종료된 후의 MFT이다. 우선 실행을 한 후 최초 실행된 26.exe와 같은 파일을 'Roaming'에 생성한다. 그 다음, recover_file_hbmmvstaw.txt라는 파일이 생성되었다는 것을 알 수 있다. 해당 파일은 4줄의 문자열이 구성되어 있다. 해당 파일이 어떠한 용도인지는 알 수가 없다. 내용은 아래와 같다. 

표 3. Recover_file_hbmmvstaw.txt

3.3 Prefetch 분석

프로세스가 실행되면 Prefetch 파일을 생성하게 된다. 이러한 프리패치 파일의 경우 어떠한 파일이 같이 로드되었는지 확인할 수가 있기 때문에, 좋은 단서들이 될 수 있다. 해당 파일의 경로와 관련된 다른 파일들에 대한 정보까지 확인할 수가 있다. 아래의 표를 확인하자.

표 4. WinPrefetchView

  표에서 볼 수 있듯이, 최초에 실행된 26.exe는 itpiwd.exe를 로드한 항목으로 가지고 있다. 이는 26.exe가 하위 프로세스로 생성한다는 점에서 알 수가 있다. 그리고 3.1에서 확인했듯이, 해당 랜섬웨어는 여러 번 VSSVS나 VSSADMIN과 관련하여 실행여부를 확인한다. 만약 이에 대해 "Yes"를 누르지 않을 경우, VSS가 삭제되지 않는다. 따라서 해당 여부를 묻는다면 "No"를 약 2초 간격마다 프로세스가 종료될 때까지 반복해서 눌러주거나 무시하여야 한다.

3.4 Registry 분석

해당 랜섬웨어를 실행한 뒤, 레지스트리에도 변화가 있다. 이를 확인하기 위하여 REGA를 사용하였다. 변화된 레지스트리 키 중 아래의 키를 보자. 해당 경로는 악성코드가 지속성을 유지하기 위하여 생성되는 부분이다.

표 5. REGA

  여기서 해당 레지스트리에 등록되는 새로운 26.exe(ltpiwd.exe)는 3.2의 표에서 나타낸 바와 같이, 프로세스의 기능을 다하면 자기 자신을 삭제한다. 이럴 경우 해당 키는 아무런 쓸모가 없다고 보일 수 있다. 하지만 해당 키에 등록되는 것은, 암호화가 진행되는 동안 사용자가 강제적으로 프로세스를 종료하거나, 컴퓨터를 종료하였을 경우를 대비한 행동이라 볼 수 이다. 다시 말해 프로세스가 진행 중에 종료가 되면 랜섬웨어는 암호화가 된 결과물이 적게 산출되기 때문에, 이를 방지하기 위함이라 볼 수가 있다.

3.5 Network 분석

암호화가 진행되는 동안 "212.85.98.241"와 네트워크 연결이 진행되는 것을 확인할 수 있다. 해당 패킷은 WireShark를 통해 캡처하여 확인할 수 있다. "212.85.98.241"와 네트워크 연결이 진행되기 때문에 Whois를 통해 해당 IP를 조회할 수가 있다. 조회한 결과는 아래의 표와 같다.

표 6. Whois

  여기서 해당 도메인 주소를 알 수가 있다. Southinstrument.org라는 사이트로 해당 사이트에 접속하려는 결과 백신으로부터 해당 사이트가 차단된다. 따라서 VM을 통해 접속해본 결과, 일반적인 장비 판매 업체의 사이트로 확인된다.

4. 정적 분석

정적 분석에서는 동적 분석을 통해 얻은 행위들에 대하여 좀 더 세부적으로 살펴볼 것이다. 분석을 진행하는데 있어 안티 디버깅 기법에 의하여 디버거로 분석을 계속 진행할 수 없었다. 따라서 실행되고 있는 해당 프로세스를 메모리에서 추출하여 이를 분석할 것이다.

  프로세스가 패킹이나 암호화 되어있을 때, 이를 디버거로 분석하기에는 난해하다. 하지만 이러한 프로세스들도 메모리에 올라오게 되면, CPU가 알아볼 수 있는 명령어로 전달되어야 하기 때문에 결국 암호화나 패킹을 해제한 상태로 메모리에 올라오게 된다. 이러한 측면을 활용하고자 메모리에서 추출한 것이다.

추출한 프로세스를 IDA를 통해 분석을 진행하였다. 해당 프로세스에서는 0041F3E0에 주요 함수들이 있는 것으로 확인된다. 해당 부분의 앞부분에 SHGetFolderPath API를 통해 여러 폴더의 경로를 구해오는 것을 확인할 수가 있다.

이렇게 진행된 후 CopyFile API와 CreateProcess API가 오는 것을 확인할 수 있다. 3.1에서 동작을 확인했던 바에 비추어 26.exe가 새로운 파일 이름을 갖는 ECX에 맞게 생성되는 것으로 보인다. 그 후 이를 실행하여 프로세스로 생성하는 것임을 알 수 있다.

그림 4. IDA – CreateProcess & CopyFile

3.1에 따르면 새로운 프로세스 ltwpiwd.exe이 생성된 것으로 확인할 수 있다. 이러한 프로세스는 암호화를 진행한다. 여기서 암호화가 진행되는 동안 vssadmin.exe가 실행되는 것을 확인할 수 있었다. 또한 해당 명령어가 "vssadmin.exe delete shadows /all /Quiet"로 기존의 VSC를 삭제하는 명령어였다. IDA를 통해 확인할 결과 해당 명령어는 스레드를 통해 진행된다. 다음 그림에서 CreateThread API가 사용되는 것을 확인할 수 있다. 여기서 해당 스레드의 내용은 StartAddress의 내용을 실행하는 것으로 해당 부분에 인자로 사용되는 명령어는 위에서 언급했던 vssadmin 명령어이다. 이렇게 vssadmin이 스레드를 통해 진행되는 것이다.

그림 5. IDA - CreateThread

VSS와 관련된 스레드가 생성된 후, 가장 핵심적인 스레드가 생성된다. 해당 스레드에 사용된 API들은 우측의 주석에 적어놓았다. 위에서와 마찬가지로 Start Address에 스레드가 수행할 명령어와 함수가 존재하고 있다. 주석을 보자. Wnet-으로 네트워크와 관련된 API들이 있으며, 그 외에 파일을 찾는 API들이 보이며, 찾은 파일들을 수정하는 함수들도 존재하고 있다.

그림 6. IDA – CreateThread

해당 Start Address를 좀 더 자세히 확인하면, 우선 FindFirstFile API를 통해 암호화 하고자 하는 첫 대상 파일을 찾는다. 대상이 된 파일은 CreateFile의 OPEN_EXISTING 인자를 통해 해당 파일 연다. 그리고 만약 파일의 사이즈가 32 Bytes보다 작거나, 327,155,712 Bytes 보다 클 경우 암호화가 진행되지 않고 다음 파일로 넘어가게 된다. 반대로, 사이즈가 이에 부합할 경우 해당 파일을 ReadFile을 통해 파일의 내용을 읽는다.

이렇게 읽은 후 해당 파일의 앞 부분에 0x170만큼 데이터가 기록된다. 여기서 0x16C까지의 내용은 모두 공통적인 바이트를 갖고 뒤 바이트부터는 서로 상이하다. 파일에 대한 기록이 완료되면 FindNextFile API를 통해 다음 파일에 대한 활동을 시작한다. 이렇게 스레드가 생성이 되고 스레드가 대상 모든 파일에 암호화가 진행되면, 스레드가 종료되며 해당 프로세스도 종료된다.

Malware_ixaobny분석.pdf

분석을 하는데 있어 처음으로 IDA를 중점으로 사용하게 된 계기가 되었다. 막힌 부분도 많았던지라 구체적으로 어떠한 기능을 하는지 확인하기는 힘들었지만, 그래도 일단 문서로 남겨놓자.

1. 개요

 분석하고자 하는 파일에 대한 정보는 위의 표와 같다. 이제 이 파일을 가지고 정적 분석과, 동적 분석, 그리고 마지막으로 상세 분석을 진행할 것이다. 정적 분석에서는 해당 파일의 실행 없이 진행이 되며, 동적 분석은 해당 파일을 실행한 결과를 나타낸다. 상세 분석은 이 2가지를 종합하여 얻은 정보를 통해 좀 더 구체적으로 분석을 진행한다.

2. 정적 분석

 정적 분석에서는 해당 악성코드의 실행 없이 분석을 진행한다. PE 구조에서 특이사항이나 문자열, 함수 등을 확인할 것이며 의심스러운 사항이 있을 경우 이에 대하여 나타낼 것이다. 이를 토대로 이후 동적 분석과 함께 상세 분석에서 토대가 된다.

2.1 PE구조 분석

 PE구조에 있어 우선 Detect It Easy를 통해 패킹의 여부와 어떤 컴파일러를 사용했는지를 확인해볼 것이다. 어떤 언어로 제작이 되었는지에 따라 해당 소스를 복구할 수도 있기 때문에 이는 반드시 확인을 해주어야 한다.

그림 1. Detect It Easy

 C/C++로 작성된 것을 확인할 수가 있으며, 별 다른 패킹이 되었는지는 나타나지 않는다. 이제 PE View를 통해 좀 더 PE구조에 대하여 자세히 살펴보자. 아래의 그림을 확인해보자.

그림 2. PE view

 특이한 사항을 바로 확인할 수가 있을 것이다. 우선 Gangnam, freebody, wtf 섹션은 일반적인 파일에는 존재하지 않는 다는 점이다. 각 섹션의 내용을 확인해본 결과 문자열들이 존재하였으며 해당 문자열은 다음과 같다.

 일반적으로 장난과 같은 느낌이 든다. 이 세 섹션은 별 중요한 내용이 없는 것 같고 이 외에 한 가지를 제외하고 다른 특이사항은 없는 것 같다. 리소스 섹션에는 .png 파일의 signature인 {89 50 4E 47 0D 0A 1A 0A}가 존재하고 있다. 아래의 그림을 보자.

그림 3. PE view – Resource Section

 그림 파일이 안에 있다는 것임으로 이를 추출해보고자 했다. 7zip을 통해 파일에서 png signature를 갖는 부분을 찾았으며 해당 파일의 이름은 87로 되어있다. 확장자를 png로 변환하고 열어서 확인해본 결과는 아래와 같다.

그림 4. Error – PNG File

 해당 파일이 손상되어 확인을 할 수 없다는 화면이 출력되는 것을 확인할 수가 있다. 그렇다면 이제 다른 부분을 분석하여 보자.

2.2 Import Address Table 분석

 문자열에서는 별다른 내용이 확인되지 않았으니 함수를 확인하였다. Import 하는 DLL은 6개이며 각 DLL에서 의심스러운 행위와 관련된 몇 가지 함수들을 선별하여 표에 정리하였다. 아래의 표를 보자.

 특정 디렉터리를 생성한다는 점과 파일과 관련하여 찾기, 생성, 삭제, 이동, 읽기, 쓰기 기능이 있다는 점에서 어떤 파일과 관련되는지 이름을 찾는 것이 중요하겠다. 프로세스와 스레드도 어떤 기능의 프로세스와 스레드가 생성되는지를 상세분석에서 확인해보자.

3. 동적 분석

 동적 분석에서는 위 정적 분석에서 확인하였던 내용을 중점적으로 어떠한 기능을 하는지 확인할 것이다. 그 외에도 정적 분석에서 확인하지 못하였던 부분이 있다면 추가로 인지를 하고 종합하여 상세분석을 진행하는데 참고할 것이다.

3.1 프로세스 분석

 해당 프로그램 90u7f65d.exe를 실행할 경우 90u7f65d가 프로세스로 생성된다. 하위 프로세스는 생성되지 않는 것으로 보인다.

그림 5. Process Explorer

3.2 네트워크 분석

 우선 다른 곳과 연결이 되는지를 확인해보자. 여기에는 TCP View를 사용하였으며 결과는 아래의 그림과 같다.

그림 6. TCP View

 해당 프로세스가 연결을 SYN 패킷을 보내는 것을 확인할 수 있지만 정확한 원격 주소가 출력되지 않고 있다. 따라서 다른 방법을 통해 해당 주소를 확인할 수 있는지 알아보자.

그림 7. Rekall – Netscan

 프로세스가 실행 중인 메모리를 덤프 떠서 메모리 분석 도구인 Rekall을 통해 어떠한 곳과 연결을 하려는 지 확인해 보았다. 결과는 위의 그림과 같으며 90u7f65d.exe 외에 System(pid=4)도 해당 주소와 연결을 하려고 했던 것을 확인할 수가 있다.

그림 8. WireShark – packet

 WireShark를 통해 캡처한 많은 패킷 중 해당 주소를 필터로 나타낸 결과이다. 위의 그림과 같이 3번의 연결을 시도하려는 작업을 하지만 닫힌 포트이므로 연결이 제대로 이루어지지 않는 것을 확인할 수가 있다. 그 다음, 해당 IP에 대한 정보를 찾아보았다.

그림 9. 해당 IP 정보

 위의 정보는 Whois를 통해 찾아본 결과이다. 프랑스 국적으로 등록이 되어 있으며 해당 사이트의 주소가 나와있는 것을 볼 수가 있다. 해당 웹사이트에 접속하여 화인해보자.

그림 10. 해당 웹 사이트

 해당 사이트에 접속해보니 서버를 빌려주는 등의 서비스를 하는 업체인 것 같다. 이 외에 별다른 정보를 알아내지는 못했다. 그러므로 임대 받은 서버 등을 통해 악성코드와 관련되는 것이라 볼 수 있다.

3.3 레지스트리 분석

 악성코드가 지속성을 유지하기 위해 레지스트리에 등록을 했을 경우도 있다. 그러므로 레지스트리에 어떠한 변화가 생겼는지 REGA와 Regshot을 통해 확인해보았다. 아래의 그림과 같은 변화가 나타났다.

그림 11. REGA

 Internet Settings와 관련하여 동작이 이루어지는 것을 확인할 수가 있다. 이 외에도 Tcpip, Tracing 등 레지스트리를 조작하는 것을 확인할 수 있었지만 지속성과 관련된 레지스트리 항목은 보이지 않았다.

3.4 MFT 분석

 MFT 분석을 위하여 WinHex를 통하여 $MFT, $LogFile, $UsnJrnl:$J를 수집하였다. 이렇게 수집된 정보를 통해 분석은 NTFS Log Tracker를 통해 진행하였으며, 실행 후 변화가 일어난 .pf 파일을 제외한 사항은 다음과 같다.

그림 12. NTFS Log Tracker – Excel

 위의 그림과 같이 IE와 관련이 있는 Content.IE5, Cookies, History 디렉터리의 각 index.dat 파일과 어떠한 행위를 하는 것을 알 수가 있다. 대부분 이를 통해 개인정보를 가져온다는 점을 고려했을 때, 이 또한 이러한 가능성을 배제할 수 없다.

4. 상세 분석

 이번 장에선 위 정적 분석과 동적 분석을 통해 얻은 정보들을 바탕으로 더 자세히 알아보는 과정을 포함하고 있다. 주로 OllyDBG와 Rekall을 통해 분석이 진행되며 그 외에 IDA pro와 Volatility를 같이 사용하고 있다.

4.1 메모리 분석

 메모리를 통해 우선 해당 프로세스가 가지는 핸들을 확인해보았다. 어떠한 파일을 핸들로 갖는지 먼저 확인해보았다. 아래의 그림과 같이 이전에 MFT를 통해 확인한 index.dat과 관련하여, 악성코드로 인한 것임을 확인할 수 있다.

그림 13. Volatility – handles

 Malfind Plugin을 통해 인젝션이 일어났는지 확인해보았다. 그 결과 아래와 같이 나타난 것을 확인할 수가 있다. 실행, 읽기, 쓰기 권한이 있는 페이지에 MZ 헤더가 있는 것을 확인할 수가 있다.

그림 14. Rekall – Malfind

 이를 추출하기 위해 dlldump Plugin을 사용하였으며 해당 주소를 베이스로 주어 추출하였으며 성공적으로 추출이 되었다.

그림 15. Volatility - dlldump

 추출한 dll에서 특이한 문자열과 API는 찾을 수가 없었기에 간단하게 Virustotal을 통해 확인해보았다. 결과는 아래의 그림과 같으며 53개의 엔진 중 4곳에서 악의적인 기능이라 의심을 받는 결과가 나왔다.

그림 16. Virustotal

4.2 디버깅 분석

 GetProcAddress API는 지정된 모듈에서 함수의 주소를 구할 때 사용되는 API이다. 여기선 EncodePointer와 DecodePointer 함수의 주소를 구하는 것을 아래의 그림과 같이 확인할 수 있다.

그림 17. GetProcAddress

 Thread를 생성할 때 사용하는 CreateThread를 호출하는 것을 볼 수가 있다. 여기서 스레드를 CREATE_SUSPENDED로 CreateionFlags를 주므로 생성된 스레드는 바로 대기 상태가 되며 ResumeThread API를 호출해야 본 기능을 진행하게 된다.

그림 18. CreateThread

 생성된 스레드는 바로 대기상태에 진입을 하였기 때문에 ResumeThread를 호출해야 하며 이를 밑의 그림과 같이 바로 호출하는 것을 확인할 수가 있다. 만약 비교문에서 값이 같을 경우엔 스레드를 재개시키지 않는다는 것 또한 같이 확인할 수가 있다.

그림 19. ResumeThread

 CreateFile API는 파일을 생성하는 것뿐만이 아니라 해당 이름의 파일이 존재하고 있는 지의 여부를 확인하는데도 사용된다. 여기선 OPEN_EXISTING 이므로 해당 파일이 존재하는지를 확인하는 것으로 반환 값이 'FFFFFFFF'이므로 존재하지 않음을 알 수 있다.

그림 20. CreateFile

 Sleep 함수를 호출한 뒤 아래의 부분과 같이 값을 이동하는 과정을 볼 수가 있다. 마치 유니코드와 같이 1바이트는 NULL이 위치하고 있으며 많은 부분이 바뀌며 아래의 그림을 보자.

그림 21. Decoding

 변환된 부분 중에서 아래의 그림과 같이 "vcltest3.dll" 과 "RegisterAutomation"이라는 문자열을 확인할 수가 있다. 그 외에 다른 부분은 특정한 문자열을 확인할 수는 없었다.

그림 22. Decoding – String

 하지만 분석을 하는 도중 에러가 발생하였다. 디코딩을 진행한 부분의 주소를 ESI에 넣고 이를 CALL 명령어를 통해 호출하는 과정이다. 하지만 해당 호출 부분으로 이동한 후 디버거로 더 이상 분석이 불가능하게 된다.

그림 23. Error

 혹시나 해서 IDA Pro로 열어본 결과 아래와 같은 결과를 확인할 수가 있었다. 따라서 어떻게 해야 할지 모르므로 더 이상 분석은 어려울 것 같다.

그림 24. Error

5. 결론

 전체적으로 분석하는 내용을 실패하였다. 분석한 범위에서 내릴 수 있는 결론은 하나뿐이다. 인터넷 브라우저를 통해 개인정보 유출의 가능성이 있다는 것이다. 이제 Cuckoo Sand Box를 통한 결과를 확인해보자.

• 인터넷 브라우저에서 개인 정보를 가로채는 기능을 함
• 시스템의 정보를 수집하는 기능
• 자동 실행을 위해 \Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon 등록
• C:\에 autoexec.bat이 Drop 됨

 위와 같이 정리할 수 있다. 하지만 여기서 의문이 남는다. 본인의 VM에서 일반적으로 실행(디버거 없이)한 경우에도 autoexec.bat은 생성되지 않았다. 또한 지속성을 위한 해당 레지스트리 값이 변화하지 않았다. 다음과 같이 생각해볼 수가 있다.

1. 해당 서버와의 연결이 이루어진 뒤에 주요한 기능들이 실행되는데 현재 서버가 닫힌 상태이므로 본 기능을 진행하지 않는다.
2. 가상 머신에서 실행을 했기 때문에 이를 인지하고 본래의 기능을 진행하지 않는다.

 본인의 실력이 부족한 것도 사실이지만, Cuckoo를 통한 결과에 따르면 생성되었어야 할 파일이 생성되지 않는다는 점부터 결국 찜찜하게 분석을 마무리 짓는다.

# Cuckoo 분석 결과

/malwr.com/analysis/YzRjOTg0ZThmYWYzNDgxYWIyM2QwNGRkNWMxZTE4ODk/

Control registers in x86 series[edit]

CR0[edit]

The CR0 register is 32 bits long on the 386 and higher processors. On x86-64 processors in long mode, it (and the other control registers) is 64 bits long. CR0 has various control flags that modify the basic operation of the processor.

CR1[edit]

Reserved

CR2[edit]

Contains a value called Page Fault Linear Address (PFLA). When a page fault occurs, the address the program attempted to access is stored in the CR2 register.

CR3[edit]

Typical use of CR3 in address translation with 4 KiB pages.

Used when virtual addressing is enabled, hence when the PG bit is set in CR0. CR3 enables the processor to translate linear addresses into physical addresses by locating the page directory and page tables for the current task. Typically, the upper 20 bits of CR3 become the page directory base register (PDBR), which stores the physical address of the first page directory entry.

CR4[edit]

Used in protected mode to control operations such as virtual-8086 support, enabling I/O breakpoints, page size extension and machine check exceptions.

Additional Control registers in x86-64 series[edit]

EFER[edit]

Extended Feature Enable Register (EFER) is a model-specific register added in the AMD K6 processor, to allow enabling the SYSCALL/SYSRET instruction, and later for entering and exiting long mode. This register becomes architectural in AMD64 and has been adopted by Intel. Its MSR number is 0xC0000080.

CR8[edit]

CR8 is a new register accessible in 64-bit mode using the REX prefix. CR8 is used to prioritize external interrupts and is referred to as the task-priority register (TPR).^[2]

The AMD64 architecture allows software to define up to 15 external interrupt-priority classes. Priority classes are numbered from 1 to 15, with priority-class 1 being the lowest and priority-class 15 the highest. CR8 uses the four low-order bits for specifying a task priority and the remaining 60 bits are reserved and must be written with zeros.

System software can use the TPR register to temporarily block low-priority interrupts from interrupting a high-priority task. This is accomplished by loading TPR with a value corresponding to the highest-priority interrupt that is to be blocked. For example, loading TPR with a value of 9 (1001b) blocks all interrupts with a priority class of 9 or less, while allowing all interrupts with a priority class of 10 or more to be recognized. Loading TPR with 0 enables all external interrupts. Loading TPR with 15 (1111b) disables all external interrupts.

The TPR is cleared to 0 on reset.

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

Analyzing-server.pdf

Server.exe 악성코드 분석

선호 경로

악성코드는 보통 자신의 존재를 은닉하고자 하며, 떄로는 사용자로부터 간단한 방법을 통하여 속이고자 한다. 우선 파일의 이름을 실제 윈도우 파일과 비슷하게 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