Gflow

버그바운티란?

www.gflow.co.kr — Wed, 12 Jul 2023 14:09:10 +0900

안녕하세요. 오랜만에 새로운 포스팅입니다.

오늘은 버그바운티에 대해서 소개해 드리도록 하겠습니다.

1. 버그바운티란?

버그 바운티는 기업이 보유한 소프트웨어, 웹 사이트 또는 시스템의 취약성을 식별하고 보고하는 윤리적 해커 및 보안 연구자에게 제공하는 보상 프로그램을 의미합니다.

버그헌터로 불리는 버그바운티 참가자들은 기업 자산에 대한 보안상의 결함을 찾아내고 취약점 보고서를 제출합니다.

이를 통하여 버그헌터들은 금전적 보상(현상금), 스웨그 또는 기타 인센티브로 보상을 받습니다.

버그 바운티 프로그램은 해커 커뮤니티의 집단적 전문 지식을 활용하여 조직의 보안을 개선하는 동시에 버그헌터가 자신의 기술을 선보이고 보상을 받을 수 있는 기회를 제공합니다.

해외에서는 이미 보편화된 서비스로 상당히 다양한 회사에서 프로그램을 운영하고 이를 통하여 보안성 향상을 꾀하고 있습니다. google, microsoft, apple 등 글로벌 기업에서는 자체 버그바운티를 운영하고 있으며 이외에도 많은 기업들이 해커원(HackerOne), 버그크라우드(BugCrowd) 등의 플랫폼을 이용하여 버그바운티를 운영하고 있습니다. 실제로 많은 버그헌터들이 버그바운티를 주업으로 하여 생활하고 있을 정도로 국내에 비해 광범위하게 운영되고 있습니다.

물론, 국내에서도 이런 국제 정세에 맞춰 일부 기업들이 버그바운티를 운영하고 있는데요. 대표적으로 삼성전자, 네이버등의 일부 대기업에서 자체적으로 버그바운티를 운영하고 있고 한국인터넷진흥원에서 취약점 신고포상제 제도를 운영하고있습니다. 또한 최근 몇 년 사이에 국내에서도 파인더갭(FINDtheGAP), 패치데이(PatchDay)등의 버그바운티 플랫폼이 등장하여 운영되고 있습니다. 보안 업게 종사자로서 참으로 반가운 소식입니다!

아무쪼록 버그바운티 산업이 커져서 많은 기업들이 기업의 자산을 보호하는데 버그바운티를 활용할 수 있게 되기를 바랍니다.

P.S.

저와 회사 동료들도 버그바운티를 통하여 소소하게 용돈벌이를 하고있습니다.

모두 소개해드릴 수는 없겠지만 앞으로 저와 동료들이 경험한 버그바운티 후기를 조금씩 작성해보려 합니다.

또한, 공개된 흥미로운 바운티들을 포스팅하려고 합니다.

그럼 빠른 시일 내에 다음 포스팅으로 인사드리도록 하겠습니다!

iOS App Hooking with Frida(1)

www.gflow.co.kr — Fri, 11 Jan 2019 11:03:20 +0900

이번 포스팅에서는 Frida를 사용한 iOS App hooking에 대하여 다루도록 하겠습니다.

(도구 설치와 같은 기초 지식은 다루지 않습니다.)

문제파일은 아래 경로를 통하여 다운받을 수 있습니다.

https://github.com/OWASP/owasp-mstg/tree/master/Crackmes

분석환경

OS: Ubuntu 18.04 LTS

Tools: Frida, Frida-Server

ipa 파일 설치 과정은 iOS의 버전에 따라 다르기 때문에 생략하였습니다.

먼저 앱을 iOS 기기에 설치합니다.

[그림 1 앱 설치]

앱을 실행 시키면 "A Secret is Found In The Hidden Label!" 이라는 문구가 적혀있는 앱의 메인이 출력됩니다.

[그림 2 앱 메인 화면]

아이폰과 PC를 USB로 연결 후 frida-ps를 이용해 앱의 프로세스 정보를 확인합니다.

[그림 3 frida-ps 정보 확인]

아무런 문자나 입력하고 Verify를 클릭하면 키 값을 찾는데 실패했다는 문구가 출력됩니다.

[그림 4 키 값 검증 실패]

힌트의 내용으로 볼 때 비밀 키의 값은 숨겨진 라벨에 존재하는 것으로 추측할 수 있습니다.

Apple의 Developer Document를 보면 UIWindow라는 클래스가 앱의 사용자 인터페이스와 뷰에 이벤트를 전달하는 객체의 배경이며

라벨과 관련된 이벤트를 다룬다는 것을 알 수 있습니다.

위에서 얻은 정보를 통해 Frida로 앱의 UI 인터페이스를 살펴보겠습니다.

Frida를 실행시켜 앱의 프로세스에 Attach합니다.

[그림 5 frida Attach]

Frida의 ObjC 함수를 이용해 UIWinodw에서 최상위 뷰를 확인하기 위해 다음과 같이 입력합니다.

[그림 6 keyWindow()함수를 이용한 최상위 뷰 확인]

이제 해당 뷰의 rootViewController를 통해 UIWindow를 구성하는데 사용된 항목들을 살펴보겠습니다.

명령어는 다음과 같이 입력합니다.

1
console.log(ObjC.classes.UIWindow.keyWindow().rootViewController().view().subviews().toString())
cs

[그림 7 UIWindow 필드 확인]

UILabel의 text에 "i am groot!"라는 값이 hidden=YES 속성으로 숨겨져 있으며 그 밑에는 힌트에 해당하는 문자열 값이 존재합니다.

UITextField에도 키 입력창에 입력했던 키 값이 보입니다.

따라서 힌트에 해당하는 숨겨져 있는 라벨의 값인 "i am groot!"를 입력하면 성공 메시지가 출력됩니다.

지금까지 Frida를 사용한 iOS App Hooking에 대하여 알아봤습니다.

다음 포스팅에서는 두번째 Crackme 문제를 가지고 포스팅을 이어가도록 하겠습니다.

참고 : https://www.nowsecure.com/blog/2017/04/27/owasp-ios-crackme-tutorial-frida/

Android App Hooking with Frida(3)

www.gflow.co.kr — Mon, 7 Jan 2019 11:19:37 +0900

이번 포스팅에서는지난시간에 이어서 Frida를 사용한 android app hooking에 대하여 다루도록 하겠습니다.

(도구 설치와 같은 기초 지식은 다루지 않습니다.)

문제파일은 아래 경로를 통하여 다운받을 수 있습니다.

https://github.com/OWASP/owasp-mstg/tree/master/Crackmes

분석환경

OS: Windows10

Tools: Frida, Frida-Server, adb, Python3.7, NOX App Player

문제파일(UnCrackable-Level3.apk)을 다운로드 하여 설치합니다.

[그림 1 apk 설치]

앱 설치 후 실행 시 루팅 탐지가 동작하며 OK 버튼 클릭 시 앱이 강제로 종료됩니다.

[그림 2 루팅탐지]

기존 앱들과 달리 frida-ps -U를 했을 때 앱의 프로세스 두개가 동작 중인것을 확인할 수 있습니다.

[그림 3 frids-ps 확인]

jadx-gui를 이용해 소스코드를 분석합니다.

[그림 4 MainActivity 분석]

Level2와 같이 libfoo.so를 불러와 사용하며 루팅탐지가 되면 OK 버튼 클릭 시 System.exit() 함수를 호출합니다.

[그림 5 MainActivity 분석2]

sub_3250에서 fork와 pthread_create, ptrace 함수를 호출하여 앱의 프로세스가 [그림 3]처럼 하나 더 생성되어 동작하는 것을 알 수 있습니다.

[그림 6 JNI에 의해 라이브러리에서 호출되는 함수]

Level2에서 구현한 코드를 사용했을 때 System.exit()에 대한 후킹에 실패하였고 로그캣에는 앱에 대한 조작행위가 발견되어 앱을 종료한다는 메시지가 남겨져 있습니다.

[그림 7 후킹 실패 후 나타나는 로그캣 정보]

libfoo.so를 다시 살펴보면 sub_3080에서 기기에 frida와 xposed 프로세스가 동작하는지 검사하는 로직이 보입니다.

[그림 8 sub_3080의 frida 프로세스 검사 로직 분석]

따라서 libfoo.so 라이브러리에 후킹방지를 위한 로직이 존재하며 우리는 두가지의 방법으로 로직을 우회할 수 있습니다.

첫번째로 sub_3080의 strstr 함수를 후킹하는 방법입니다.

[그림 9 strstr 함수 분석]

strstr 함수의 구조는 다음과 같습니다.

1
char *strstr(const char *haystack, const char *needle);
cs

strstr 함수의 haystack과 needle 포인터에 대해 후킹을 시도하며 소스코드는 다음과 같습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Interceptor.attach(Module.findExportByName("libc.so", "strstr"), {
 
    onEnter: function (args) {
 
    this.haystack = args[0];
    this.needle = args[1];
    this.frida = Boolean(0);
 
    haystack = Memory.readUtf8String(this.haystack);
    needle = Memory.readUtf8String(this.needle);
 
    if ( haystack.indexOf("frida") !== -1 || haystack.indexOf("xposed") !== -1 ) {
           this.frida = Boolean(1);
    }
},
 
    onLeave: function (retval) {
 
    if (this.frida) {
       var fakeRet = ptr(0);
       retval.replace(0);
    }
    return retval;
    }
});
Colored by Color Scripter
cs

두번째 방법은 pthread_create를 이용한 방법입니다.

pthread_create의 구조는 다음과 같습니다.

1
int pthread_create(pthread_t *thread, const pthread_attr_t *attr, void *(*start_routine) (void *), void *arg);
cs

함수를 추적해보면 pthread_create는 두 군데에서 호출하는 것을 확인할 수 있습니다.

[그림 10 pthread_create 호출]

또한 첫번째와 세번째 인수가 0인 것을 확인할 수 있습니다.

따라서 pthread_create를 가져와 오버로드하여 조작된 값(0)으로 바꾸고 frida를 탐지할 때 콜백을 조작하여 frida를 사용하지 않는 것 처럼 속일 수 있습니다.

소스코드는 다음과 같습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
var p_pthread_create = Module.findExportByName("libc.so", "pthread_create");
var pthread_create = new NativeFunction( p_pthread_create, "int", ["pointer", "pointer", "pointer", "pointer"]);
send("NativeFunction pthread_create() replaced @ " + pthread_create);
 
Interceptor.replace( p_pthread_create, new NativeCallback(function (ptr0, ptr1, ptr2, ptr3) {
    send("pthread_create() overloaded");
    var ret = ptr(0);
    if (ptr1.isNull() && ptr3.isNull()) {
        send("loading fake pthread_create because ptr1 and ptr3 are equal to 0!");
    } else {
        send("loading real pthread_create()");
        ret = pthread_create(ptr0,ptr1,ptr2,ptr3);
    }
 
    do_native_hooks_libfoo();
 
    send("ret: " + ret);
 
}, "int", ["pointer", "pointer", "pointer", "pointer"]));
Colored by Color Scripter
cs

우리는 두가지 방법 중 strstr 함수를 속이는 방식으로 루팅과 후킹 방지에 대한 우회를 시도하겠습니다.

소스코드는 다음과 같습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
import sys, frida
def on_message(message, data):
    if message['type'] == 'send':
        print("[*] {0}".format(message['payload']))
    else:
        print(message)
PACKAGE_NAME = "owasp.mstg.uncrackable3"
jscode = """
send("Starting script");
// char *strstr(const char *haystack, const char *needle);
Interceptor.attach(Module.findExportByName("libc.so", "strstr"), {
onEnter: function (args) {
this.haystack = args[0];
this.needle = args[1];
this.frida = Boolean(0);
haystack = Memory.readUtf8String(this.haystack);
needle = Memory.readUtf8String(this.needle);
if ( haystack.indexOf("frida") !== -1 || haystack.indexOf("xposed") !== -1 ) {
    
            this.frida = Boolean(1);
}
},
onLeave: function (retval) {
if (this.frida) {
    var fakeRet = ptr(0);
    
    retval.replace(0);
}
return retval;
}
});
send("Done with native hooks....");
Java.perform(function () {
    send("Hooking calls to System.exit");
    var sys = Java.use("java.lang.System");
    sys.exit.overload("int").implementation = function(var_0) {
        send("System.exit called");
    };
    send("Done Java hooks installed.");
});
"""
try:
    device = frida.get_usb_device(timeout=5)
    pid = device.spawn([PACKAGE_NAME])
    print("App is Starting.... pid : {}".format(pid))
    process = device.attach(pid)
    device.resume(pid)
    script = process.create_script(jscode)
    script.on('message', on_message)
    print("[*] Running Hook")
    script.load()
    sys.stdin.read()
except Exception as e:
    print(e)
Colored by Color Scripter
cs

스크립트를 실행시키면 앱이 자동으로 실행되면서 똑같이 루팅이 탐지 되었다는 메시지가 뜨지만 OK를 클릭하면 우회가 됩니다.

[그림 11 System.exit() 후킹]

이제 앱에서 키값을 입력할 수 있게 되었습니다.

[그림 12 루팅 및 후킹 방지 우회된 상태의 앱]

다시 jadx-gui로 돌아와서 CodeCheck 클래스의 소스코드를 살펴보면 그림과 같이 JNI 기법에 의해 libfoo.so의 함수로 입력한 값이 전달됩니다.

[그림 13 CodeCheck 클래스]

libfoo.so에서 Java_sg_vantagepoint_uncrackable3_CodeCheck_bar 함수를 확인할 수 있습니다.

[그림 14 Java_sg_vantagepoint_uncrackable3_CodeCheck_bar]

CodeCheck_bar를 분석해보면 MainActivity에서 보았던 "pizzapizzapizzapizzapizz"와 사용자가 입력한 키값을 XOR하여 실제 키값과 일치하는지 비교하여 성공과 실패를 반환하는 방식입니다. 또한 0x0000344D에서 eax와 18h(24글자)인지 비교하는 로직으로 볼때 키값의 길이는 24자인 것을 확인할 수 있습니다.

[그림 15 키 검증 로직 분석]

위 처럼 분석한 내용을 토대로 hooking 코드를 작성하였을 때 소스코드는 다음과 같습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
import sys, frida
def on_message(message, data):
    if message['type'] == 'send':
        print("[*] {0}".format(message['payload']))
    else:
        print(message)
PACKAGE_NAME = "owasp.mstg.uncrackable3"
jscode = """
send("Starting script");
// char *strstr(const char *haystack, const char *needle);
Interceptor.attach(Module.findExportByName("libc.so", "strstr"), {
    onEnter: function (args) {
        this.haystack = args[0];
        this.needle = args[1];
        this.frida = Boolean(0);
    haystack = Memory.readUtf8String(this.haystack);
    needle = Memory.readUtf8String(this.needle);
    if ( haystack.indexOf("frida") !== -1 || haystack.indexOf("xposed") !== -1 ) {
    this.frida = Boolean(1);
    }
},
    onLeave: function (retval) {
        if (this.frida) {
            var fakeRet = ptr(0);
            retval.replace(0);
        }
    return retval;
    }
});
var address = 0x00003446;
//var address2 = 0x000033ee;
function hook(){
    //libfoo.so Address
    var p_foo = Module.findBaseAddress('libfoo.so');
    send("libfoo.so @ " + p_foo.toString());
    var target_address = p_foo.add(address);
    send("target_Address @ " + target_address.toString());
    Interceptor.attach(target_address, {
        onEnter: function (args) {
        send("onEnter() target_Address");
        send("Context : " + JSON.stringify(this.context));
        var ecx = this.context.ecx;
        send("ecx:"+ecx);
        send(hexdump(ecx,{
            offset: 0,
            length: 24,
            header: false,
            ansi:false
        }));
        var ebx = this.context.ebx;
        send("ebx:"+ebx);
        send(hexdump(ebx,{
            offset: 0,
            length: 24,
            header: false,
            ansi:false
        }));
         var esi = this.context.esi;
        send("esi:"+esi);
        send(hexdump(esi,{
            offset: 0,
            length: 24,
            header: false,
            ansi:false
        }));
        var edi = this.context.edi;
        send("edi:"+edi);
        send(hexdump(edi,{
            offset: 0,
            length: 24,
            header: false,
            ansi:false
        }));
        var ebp = this.context.ebp;
        send("ebp:"+ebp);
        send(hexdump(ebp,{
            offset: 0,
            length: 24,
            header: false,
            ansi:false
        }));
        var esp = this.context.esp;
        send("esp:"+esp);
        send(hexdump(esp,{
            offset: 0,
            length: 24,
            header: false,
            ansi:false
        }));
     },
     onLeave: function (retval) {
        send("onLeave() p_strncmp_xor64");
        send(retval);
     }
    
    });
}
    send("Done with native hooks....");
Java.perform(function () {
    send("Hooking calls to System.exit");
    var sys = Java.use("java.lang.System");
    sys.exit.overload("int").implementation = function(var_0) {
        send("System.exit called");
    };
    hook();
    send("Done Java hooks installed.");
});
"""
try:
    device = frida.get_usb_device(timeout=5)
    pid = device.spawn([PACKAGE_NAME])
    print("App is Starting.... pid : {}".format(pid))
    process = device.attach(pid)
    device.resume(pid)
    script = process.create_script(jscode)
    script.on('message', on_message)
    print("[*] Running Hook")
    script.load()
    sys.stdin.read()
except Exception as e:
    print(e)
Colored by Color Scripter
cs

위 스크립트를 실행하면 다음과 같이 키 값을 입력받기 위한 대기 상태가 됩니다.

[그림 16 루팅 우회된 상태의 스크립트]

앱에서 24자의 조건을 충족시키기 위해 "012345678901234567890123"을 입력합니다.

[그림 17 임의 값 입력]

VERIFY를 클릭하면 실패했다는 팝업이 뜨고 스크립트에는 그림과 같이 메모리에 적재되어 있는 레지스터의 값들이 보이게 됩니다.

[그림 18 레지스터에 남아있는 키값]

여기서 esp가 키 값 비교에 사용된 실제 키 값, esi가 사용자 입력 값, ecx가 MainActivity에서 보았던 XOR에 쓰이는 키값인 것을 알 수 있습니다. 위 로직 대로 실제 키 값과 XOR에 쓰이는 키 값을 이용해 정답이 무엇인지 확인해보겠습니다.

1
2
3
4
5
6
7
8
9
secret = bytes.fromhex('1d0811130f1749150d0003195a1d1315080e5a0017081314').decode('utf-8')
key = 'pizzapizzapizzapizzapizz'
 
password = ""
 
for i in range(24):
    password += chr((ord(secret[i]) ^ ord(key[i])))
 
print ("password : ",password)
Colored by Color Scripter
cs

위 소스코드를 실행시키면 다음과 같이 키 값이 추출 됩니다.

[그림 19 추출된 키값]

추출된 키 값을 입력하면 성공 메시지가 출력됩니다.

[그림 20 키 값 검증]

지금까지 Frida를 사용한 Android App Hooking에 대하여 알아봤습니다.

참고 : http://sh3llc0d3r.com/owasp-uncrackable-android-level3/

https://enovella.github.io/android/reverse/2017/05/20/android-owasp-crackmes-level-3.html

Windows Artifact[6] - EventLog[2]

www.gflow.co.kr — Tue, 18 Dec 2018 11:09:07 +0900

이번 포스팅에서는 이벤트로그 분석방법에 대해서 살펴 보겠습니다.

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

1. 분석

앞서 포스팅에서 이벤트로그와 관련댄 구조와 저장경로를 살펴보았습니다. 이번 포스팅에서는 이벤트로그 분석방법에 대해서 알아 보겠습니다. 이벤트로그에는 사용자가 윈도우 시스템을 사용하면서 행했던 다양한 정보가 저장되어 있어 포렌식을 수행함에 있어 꼭 분석을 해야 하는 아티팩트입니다.

1) EVT 분석

EVT파일을 이용한 이벤트 로그 분석 시 아래 항목에 대한 데이터를 추출하여 분석 및 활용할 수 있습니다.

속성	설명
Record Number	기록된 이벤트의 번호
Time Generated	이벤트가 작성된 시간
Event ID	특별한 이벤트 유형을 식별하는 값. 예를 들어 6005는 이벤트로그 서비스가 시작될 때 발생되는 이벤트ID.
Event Type	이벤트의 심각도를 분류하여 나타낸다. 정보(Information), 경고(Warning), (오류)Error, (심각)Critical, 성공감사(Success Audit), 실패 감사(Failure Audit) 로 구분.
Event Category	이벤트 카테고리
Event Scource	이벤트를 기록한 소프트웨어 (이벤트가 일어난 프로세스)
Computer	컴퓨터 이름
Strings	설명에 사용된 문자열

[표 1] EVT 속성

2) EVTX 분석

EVTX파일을 이용한 이벤트 로그 분석 시 아래 항목에 대한 데이터를 추출하여 분석 및 활용 할 수 있습니다.

속성	설명
Source	이벤트를 기록한 소프트웨어 (이벤트가 일어난 프로세스)
Event ID	특별한 이벤트 유형을 식별하는 값. 예를 들어 6005는 이벤트로그 서비스가 시작될 때 발생되는 이벤트ID.
Level	이벤트의 심각도를 분류하여 나타낸다. 정보(Information), 경고(Warning), (오류)Error, (심각)Critical, 성공감사(Success Audit), 실패 감사(Failure Audit) 로 구분.
User	이벤트 발생에 대한 사용자의 이름
Operational Code	응용 프로그램에서 이벤트가 발생했을 때 활동이나 시점을 식별하는 숫자 값을 포함.
Log	이벤트가 기록된 로그의 이름입니다.
Task Category	이벤트 게시자의 하위 구성요소 또는 활동을 표현하는데 사용.
Keywords	이벤트를 검색하거나 필터링 하는데 사용할 수 있는 범주 또는 태그의 집합. ex) "네트워크", "보안", "리소스를 찾을 수 없습니다."
Computer	이벤트가 발생한 컴퓨터의 이름.
Date and Time	이벤트가 기록된 날짜 및 시간.
Process ID	이벤트를 생성하는 과정에 대한 식별번호.
Thread ID	이벤트 생성 쓰레드의 식별번호.

[표 2] EVTX 속성

3) 주요 이벤트 ID

일반적인 윈도우 로그 모니터링 시 참고하여야 할 이벤트에 대한 항목은 다음과 같습니다. 다음 표에 작성된 이벤트를 기준으로 시점기반 피해시스템 진단 시 해당 이벤트 영역을 집중적으로 분석합니다. 또한 마지막에는 다양한 이벤트로그중에서 분석가가 심도있게 봐야할 항목을 추려 놓았습니다.

범주	이벤트ID	이벤트ID	이벤트명	설명
권한이 없는 컴퓨터 사용 이벤트	528	4624	로그온 성공	워크스테이션 이름 및 사용자 계정 이름을 확인하십시오. 원본 네트워크 주소가 네트워크에 있는지 확인하십시오.
	529	4625	로그온 실패 – 알 수 없는 사용자 이름이거나 암호가 틀림	대상 계정 이름이 Administrator이거나 변경된 기본 관리자 계정인 로그온 시도를 확인하십시오. 계정 잠금 임계값보다 낮은 다수의 로그온 실패도 확인하십시오.
	530	4625	로그온 실패 - 시간 제한	허용된 시간 범위 외부에서의 로그온 시도를 나타냅니다. 사용자 계정 이름 및 워크스테이션 이름을 확인하십시오.
	531	4625	로그온 실패 – 현재 사용할 수 없는 계정	대상 계정 이름 및 워크스테이션 이름을 확인하십시오. 이 이벤트는 이전 사용자가 시도했던 침입을 나타낼 수 있으므로 조사해 볼 필요가 있습니다.
	532	4625	로그온 실패 – 지정한 사용자 계정이 만료됨	대상 계정 이름 및 워크스테이션 이름을 확인하십시오. 이 이벤트는 계약직 또는 임시직 직원의 악용 시도를 나타낼 수 있으므로 조사해 볼 필요가 있습니다.
	533	4625	로그온 실패 – 사용자가 이 시스템에 로그온이 허용되지 않았음	사용자가 제한된 워크스테이션에 로그온하려 할 수 있음을 나타냅니다.
	534	4625 / 5461	로그온 실패 – 허용되지 않은 로그온 유형	대상 계정 이름, 워크스테이션 이름 및 로그온 유형을 확인하십시오. 이 이벤트는 그룹 정책 설정에서 서비스 계정을 사용한 대화형 로그온을 금지하는 경우 해당 계정의 자격 증명을 사용한 대화형 로그온 실패 시도를 나타냅니다.
	535	4625	로그온 실패 – 지정된 계정 암호가 만료됨	사용자가 암호가 만료된 계정을 사용하여 로그온을 시도하려 한다는 것을 나타냅니다. 해당 암호의 변경 또는 지원 호출 없이 반복해서 시도할 경우 즉각적인 조사가 필요할 수 있습니다.
	536	4625	로그온 실패 - NetLogon 구성 요소가 활성화되어 있지 않음	NetLogon 서비스가 작동 중인지 확인하십시오. 작동하지 않는 경우에는 이 이벤트를 즉시 조사해 볼 필요가 있습니다.
	540	4624	로그온 성공	이 이벤트는 이벤트 528에 해당하는 네트워크입니다.
이벤트592	592	4688	새 프로세스 만들기	승인되지않은프로세스또는예기치않은시작시간이있거나,알수없는프로그램이시작되고나서곧바로중지되는경우가있는지이미지파일이름및사용자이름항목을확인하십시오.
파일 권한 변경 이벤트	560	4656	기존 개체에 부여된 액세스	개체에 대해 액세스 요청이 허가되었음을 나타냅니다. 기본 로그온 ID, 클라이언트 사용자 이름 및 기본 사용자 이름을 확인하여 무단 액세스를 찾아내십시오. 액세스 필드를 확인하여 작업 유형을 판단하십시오. 이 이벤트는 실제 액세스 발생 여부가 아닌 액세스 요청만 감지합니다.
파일 권한 변경 이벤트	567	4657 / 4663	사용된 핸들과 관련된 권한	개체에대한액세스유형의첫번째인스턴스와액세스필드에“WRITE_DAC”가포함된경우해당권한이변경되었음을나타냅니다.핸들ID필드와비교하여이벤트560에연결하십시오.
암호 재설정 이벤트	627	4723	암호 변경 시도	요청자가 원래 암호를 제공한 암호 변경 요청을 나타냅니다. 기본 계정 이름과 대상 계정 이름을 비교하여 요청하는 계정이 변경된 계정인지를 확인하십시오.
	628	4724	사용자 계정 암호 설정 또는 재설정	암호 변경 프로세스라기보다는 관리 인터페이스를 통한 암호 재설정을 나타냅니다. 요청자는 지원 센터 계정 또는 셀프 서비스 암호 재설정 계정과 같은 권한이 있는 계정이어야 합니다.
	698		디렉터리 서비스 복원 모드 암호 변경	도메인컨트롤러에서의디렉터리서비스복원모드암호변경시도를나타냅니다.워크스테이션IP및계정이름을확인하십시오.이이벤트는즉각적인조사가필요합니다.
사용자 계정 변경 이벤트	624	4720	사용자 계정 만들기	네트워크 계정 생성 작업이 발생했음을 나타냅니다.
	630	4726	사용자 계정 삭제	네트워크 계정 삭제 작업이 발생했음을 나타냅니다.
	642	4738	사용자 계정 변경	보안 관련 사용자 계정 변경 사항은 이벤트 627-630에서 다루지 않는 사항임을 나타냅니다.
	685	4781	사용자 계정 이름 변경	사용자계정 이름 변경을 나타냅니다.
그룹 구성원 변경 이벤트	631, 632, 633, 634,	4727	보안 글로벌 그룹 변경	대상 계정 이름 필드를 확인하여 변경된 그룹이 글로벌 그룹이거나 광범위한 액세스 권한을 가지고 있는지 알아보십시오.
	635, 636, 637, 638,	4731/ 4732/ 4733/ 4734	보안 로컬 그룹 변경	대상 계정 이름 필드를 확인하여 변경된 그룹이 관리자, 서버 운영자 또는 백업 운영자인지 알아보십시오.
	639, 641, 668	4735/ 4737/ 4764	보안 그룹 변경	삭제, 만들기 또는 구성원 변경 이외의 그룹에 대한 변경 사항을 나타냅니다. 대상 계정 이름을 확인하여 권한이 높은 그룹이 변경되지 않았는지 알아보십시오.
	659, 660, 661, 662	4755/ 4756/ 4757/ 4758	보안 유니버설 그룹 변경	대상계정이름필드를확인하여EnterpriseAdmins와같은권한이높은그룹이변경되지않았는지알아보십시오.
무단 로그온 이벤트	528, 540	4624	로그온 성공	528은 일반적인 이벤트입니다. 하지만 이벤트 540의 경우에는 대상 계정 이름을 확인하여 기본 관리자 계정에 의해 발생했는지 여부를 알아보아야 합니다.
	529	4625	로그온 실패 – 알 수 없는 사용자 이름 또는 암호	대상 계정 이름이 Administrator이거나 이름이 변경된 기본 관리자 계정인 경우에는 항상 조사해야 합니다. 로그온 실패 횟수가 잠금 임계값에 거의 다다른 경우에도 항상 조사해야 합니다. 또한 대상 계정 이름이 Administrator 또는 루트이거나 도메인 이름을 알 수 없는 시도도 확인하십시오.
	531	4625	로그온 실패 - 사용할 수 없는 계정	대상 계정 이름 및 워크스테이션 이름을 확인하여 출처를 파악하십시오. 이 이벤트는 이전 계정 사용자에 의한 예상 침입 시도로 간주하여 조사해야 합니다.
	532	4625	로그온 실패 - 만료된 계정	대상 계정 이름 및 워크스테이션 이름을 확인하여 출처를 파악하십시오. 이 이벤트는 이전 계정 사용자에 의한 예상 침입 시도로 간주하여 조사해야 합니다.
	576	4672	새 로그온에 할당된 특별 권한	새계정권한이나감사추적을변경하는기능을부여할수있는권한할당을나타냅니다.로그온ID필드와이벤트528또는540을비교하면계정에관리자에해당하는권한이있는지쉽게알수있습니다.
서비스 계정 자격 증명을 사용한 로그온 이벤트	528	4624	로그온 성공 – 콘솔 공격 또는 터미널 서비스	로그온 유형 10, 서비스 계정 또는 로컬 시스템 계정이 이 이벤트와 관련된 경우 진행 중인 공격을 나타냅니다. 이 이벤트는 즉시 조사해야 합니다.
	534	4625/ 5461	로그온 실패 – 허용되지 않은 로그온 유형	그룹 정책 설정에 의해 금지된 서비스 계정 자격 증명을 사용하여 대화형으로 로그온하려 했으나 실패한 시도를 나타냅니다. 이벤트가 발생하면 대상 계정 이름, 워크스테이션 이름 및 로그온 유형을 확인하십시오.
	600	4696	프로세스에 기본 토큰이 할당됨	서비스에서 명명된 계정을 사용하여 Windows XP 이상을 실행하는 시스템에 로그인하려 함을 나타냅니다. 조사하려면 이벤트 672, 673, 528 및 592의 정보와 연결하십시오.
	601	4697	사용자의 서비스 설치 시도	이이벤트는명확하게정의된허용가능한응용프로그램정책과시스템표준화프로세스를갖춘비즈니스환경에서는대체로발생하지않습니다.이러한환경에서변경제어프로세스가연결되어있지않은경우에는이이벤트를조사해야합니다.
권한이 없는 프로그램 실행 이벤트	592	4688	새 프로세스 만들기	새 프로세스가 만들어졌음을 나타냅니다. 이미지 파일 이름 및 사용자 이름 필드를 확인하고 회사에 허용 가능한 프로그램 정책이 설정되어 있는 경우 권한이 있는 프로그램 목록과 비교하십시오. 또한 LocalSystem을 사용하여 명령 프롬프트를 시작하는 것은 감사 추적을 회피하기 위한 일반적인 방법이므로 이와 같은 경우가 있는지 살펴보십시오.
권한이 없는 프로그램 실행 이벤트	602	4698/ 4699/ 4700/ 4701/ 4702	예정된 작업 만들기	이와같은이벤트가예기치않은시간에발생하는경우대상이름및작업이름을확인하십시오.
권한이 없는 리소스에 대한 엑세스 시도 이벤트	560	4656	기존 개체에 대해 거부된 액세스	개체 이름 필드를 확인하여 액세스된 리소스를 알아보고 기본 사용자 이름 및 기본 도메인 필드 또는 클라이언트 사용자 이름 및 클라이언트 도메인 필드를 연결하여 출처를 파악하십시오.
권한이 없는 리소스에 대한 엑세스 시도 이벤트	568		감사된 파일에 대한 하드 링크 만들기 시도	사용자또는프로그램에서파일이나개체에대한하드링크를만들려고했음을나타냅니다.계정에개체한대한권한이있는경우해당계정에서는설정된하드링크를통해감사추적을만들지않고도파일을조작할수있습니다.
권한이 없는 컴퓨터 사용 이벤트	529	4625	로그온 실패 – 알 수 없는 사용자 이름 또는 암호	대상 계정 이름 필드가 Administrator 또는 루트이거나 도메인 이름을 알 수 없는 로그온 시도가 있는지 확인하십시오.
	533	4625	로그온 실패 – 사용자가 이 시스템에 로그온이 허용되지 않았음	사용자가 제한된 워크스테이션에 로그온하려 할 수 있음을 나타냅니다.
	592	4688	새 프로세스 만들기	이미지파일이름및사용자이름필드를확인하여프로그램이해당계정에서지정된용도로사용되는데필요한권한이있는지알아보십시오.
신뢰관계 변경 이벤트	610, 611, 620	4706/ 4707/ 4716	다른 도메인과의 신뢰 관계가 생성, 삭제 또는 수정됨	이이벤트는신뢰관계를구축한도메인컨트롤러에생성됩니다.이이벤트가설정된변경제어요청프로세스에연결되지않은경우에는즉시조사해야합니다.사용자이름필드를확인하여요청하는계정을알아보십시오.
정책 변경 이벤트	612	4719	감사 정책 변경	감사 정책 변경을 나타냅니다. 권한이 부여되었는지 여부를 확인하려면 이 이벤트를 설정된 변경 제어 정책에 연결해야 합니다.
	613, 614, 615	존재하지 않음	IPsec 정책 변경	IPsec 정책 변경을 나타냅니다. 시스템이 시작되지 않고 발생하는 경우에는 조사해야 합니다.
	618	4714	암호화된 데이터 복구 정책	이이벤트는암호화된데이터복구정책이사용되고있는경우에발생합니다.지정된정책이아닌다른정책이사용되고있으면조사해야합니다.
인증자격증명변경이벤트	529	4625	로그온 실패 – 알 수 없는 사용자 이름 또는 암호	대상 계정 이름이 Administrator이거나 암호 변경 권한이 부여되지 않은 다른 관리 수준 계정인 로그온 시도를 확인하십시오. 또한 잠금 임계값보다 낮은 다수의 로그온 실패를 확인하고, 이벤트 529 및 이벤트 539와 연결하여 연속 계정 잠금 패턴을 식별하십시오.
	534	4625/ 5461	로그온 실패 – 허용되지 않은 로그온 유형	사용자가 네트워크, 대화형, 배치 또는 서비스 등 허용되지 않는 계정 유형을 사용하여 로그온하려 했음을 나타냅니다. 대상 계정 이름, 워크스테이션 이름 및 로그온 유형 필드를 확인하십시오.
	539	4625	계정 잠김	잠겨 있는 계정을 사용하여 로그온을 시도했음을 나타냅니다. 이벤트 529에 연결하여 연속 잠금 패턴을 확인하십시오.
	553	4649	재생 공격 탐지됨	Kerberos 같은 인증 패키지에서 사용자 자격 증명 재생을 통한 로그온 시도를 감지했음을 나타냅니다. 이 이벤트는 잘못된 네트워크 구성을 나타낼 수도 있지만 여하튼 즉시 조사해야 합니다.
	627	4627	암호 변경 시도	기존 계정 이름 필드가 대상 계정 이름 필드와 일치하지 않는 경우 계정 소유자가 아닌 사용자가 암호를 변경하려 했음을 나타냅니다.
	628	4724	사용자 계정 암호 설정 또는 재설정	이 활동을 지원 센터 계정 또는 사용자 셀프 서비스 암호 재설정 계정 등 권한이 있는 계정으로만 제한해야 합니다.
	644	4740	사용자 계정이 자동으로 잠김	연속 로그온 실패 시도 횟수가 계정 잠금 제한을 초과하여 계정이 잠겼음을 나타냅니다. 이벤트 529, 675, 681 및 676과 연결합니다(Windows 2000 Server에만 해당). 이 표의 이벤트 12294에 대한 항목도 참조하십시오.
	675	4771	사전 인증 실패	도메인에 가입되지 않은 컴퓨터 계정을 나타내거나 시간 동기화 문제를 나타냅니다. 이벤트 529와 연결하여 정확한 로그온 실패 이유를 찾아내십시오.
	12294		계정 잠금 시도	기본관리자계정에대한BruteForce공격이발생한것일수있음을나타냅니다.이계정에는계정잠금정책이적용되지않기때문에시스템이벤트로그에SAM이벤트12294로기록됩니다.권한이없는운영체제의사용을나타낼수도있으므로이이벤트항목을모두조사해야합니다.알수없는도메인의도메인이름필드확인
권한 상승 취약점의 악용으로 인해 발생하는 취약점 이벤트	528, 538	528	로컬 로그온 및 로그오프	이러한 이벤트가 경계 네트워크에서 발생할 경우 로그온 ID 필드와 연결합니다. 사용자 계정 이름, 시간 또는 워크스테이션 이름 필드에 예기치 않은 값이 포함되어 있으면 즉시 조사해야 합니다.
	551	4647	사용자가 로그오프 시도	토큰 누출로 인해 이벤트 538을 감사할 수 없지만 대신에 이벤트 551이 발생하므로 이 이벤트를 이벤트 538로 간주할 수 있습니다.
	576	4672	권한이 있는 로그온	관리자계정로그온또는TCP(신뢰할수있는컴퓨팅기초)를조작할수있는권한이나WindowsServer2003SP1이상의컴퓨터를인계할수있는권한을가진계정로그온을나타냅니다.이전버전의Windows에서는SeSecurityPrivilege또는SeDebugPrivelege등주요권한과관련된경우에만이이벤트에관심을가졌습니다.
이벤트 감사 회피 이벤트	512	4608	Windows 시작	일반적으로 이벤트 513 이후에 발생합니다. 이 경우 예기치 않은 다시 시작을 조사해야 합니다.
	513	4609	Windows 시스템 종료	일반적으로 이벤트 512 전에 발생합니다. 고부가가치 컴퓨터는 권한이 있는 사용자만이 설정된 변경 제어 절차나 다른 절차에 따라 다시 시작해야 합니다. 어떤 서버에서든 이 이벤트가 발생할 경우 즉시 조사해야 합니다.
	516	4612	감사 실패	이 이벤트는 이벤트 수가 너무 많아 이벤트 로그 버퍼 용량이 부족하거나 보안 로그가 덮어쓰도록 설정되어 있지 않은 경우에 발생할 수 있습니다. 대부분의 컴퓨터에서는 모니터링 되는 이벤트 유형을 제한하여 이러한 문제를 방지할 수 있지만, 고부가가치 컴퓨터나 취약한 컴퓨터는 보안을 위해 보다 철저하고 신중하게 모니터링 해야 합니다.
	517	1102	보안 이벤트 로그 지우기	권한이 없는 경우에는 보안 이벤트 로그를 지울 수 없도록 해야 합니다. 클라이언트 사용자 이름 및 클라이언트 도메인 필드를 확인하여 권한이 있는 사용자와 절차가 승인된 레코드를 서로 연결하십시오.
	520	4616	시스템 시간 변경	이 작업을 통해 정밀 분석을 잘못된 방향으로 이끌거나 공격자에게 거짓 알리바이를 제공할 수 있습니다. 클라이언트 사용자 이름 및 클라이언트 도메인 필드를 확인하여 권한이 있는 사용자와 서로 연결하고, 프로세스 이름이 %windir%\system32\svchost.exe로 표시되어 있는지도 확인하십시오.
	521	존재하지 않음	이벤트 기록 불가능	Windows에서 이벤트 로그에 이벤트를 쓸 수 없는 경우에 발생합니다. 이 이벤트가 모든 고부가가치 시스템에서 발생할 때마다 조사해야 합니다.
	608	4704	사용자 계정 권한이 할당됨	새 권한이 사용자 계정에 할당되는 경우에 발생합니다. 이벤트 로그는 사용자 계정 이름이 아닌 사용자 계정 SID(보안 식별자)와 함께 이 동작을 기록합니다.
	609	4705	사용자 계정 권한이 제거됨	사용자 계정에서 권한이 제거된 경우에 발생합니다. 이벤트 로그는 사용자 계정 이름이 아닌 사용자 계정의 SID와 함께 이 동작을 기록합니다.
	612	4719	감사 정책 변경	이 이벤트가 발생했다고 해서 반드시 문제가 있는 것으로 단정할 수는 없지만 공격자가 공격의 일환으로 감사 정책을 수정할 수 있습니다. 고부가가치 컴퓨터와 도메인 컨트롤러에서 이 이벤트를 모니터링 해야 합니다.
	621	4717	시스템 액세스 권한이 계정에 부여됨	사용자에게 시스템에 대한 액세스 권한이 부여된 경우에 발생합니다. 액세스 권한이 대화형으로 표시되는 경우 사용자 이름 및 수정된 계정 필드를 확인해야 합니다.
	622	4718	시스템에서 시스템 액세스 권한이 제거됨	이 이벤트는 공격자가 이벤트 621과 관련된 증거를 제거하려고 했거나 다른 계정에 대해 서비스 거부를 시도하고 있음을 나타낼 수 있습니다.
	643	4739	도메인 보안 정책 변경	암호정책이나기타도메인보안정책설정을수정하려는시도가있을경우발생합니다.사용자이름을확인하고권한부여레코드와연결하십시오.

[표 3] 주요 이벤트 로그

[그림 1] 주요 이벤트로그

지금까지 이벤트로그에 대해서 살펴 보았으며, 다음 포스팅에서는 프리패치에 대해서 살펴 보겠습니다.

Windows Artifact[6] - EventLog[1]

www.gflow.co.kr — Mon, 9 Jul 2018 14:17:37 +0900

이번 포스팅에서는 이벤트로그에 대해 알아 보겠으며, 구조, 주요 이벤트 로그에 대해 포스팅을 나눠 알아 보겠습니다.

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

1.이벤트로그

이벤트로그는 윈도우 시스템을 사용하면서 남는 로그입니다. 이벤트로그의 큰 특성은 아래와 같습니다.

-운영체제에서 발생되는 변화를 기록

-응용프로그램, 보안, Setup, 시스템 등 으로 구성

-이벤트 로그 저장경로 : C:/Windows/System32/winevt/Logs (윈도우 7 이후)

-저장되는 로그의 대표적인 정보로는 사용자 추가/삭제, 로그인 성공/실패, 원격접속 성공/실패, 윈도우 부팅/종료, 애플리케이션 설치 등 기록

1)이벤트로그 데이터

윈도우 이벤트 로그는 vista 전후로 부분적인 차이점이 존재합니다. vista 이전에는 EVT라는 확장자로 사용되었으며, vista부터는 EVTX 확장자로 파일을 생성합니다. EVT 파일은 생성 시간, 작성 시간을 기록하며 EVTX는 생성시간만 기록합니다. EVT 확장자의 시간은 유닉스 32비트 헥스 타임(Unix 32bit Hex Time)/리틀엔디안(Little-endian)으로 기록되며 EVTX 확장자의 시간은 윈도우 64비트 타임/리틀엔디안(Little-endian)으로 기록됩니다.

추출되는 데이터의 차이점은 아래 표와 같습니다.

구분	속성	설명
EVT	Record Number	기록된 이벤트의 번호
	Time Generated	이벤트가 작성된 시간
	Event ID	특별한 이벤트 유형을 식별하는 값. 예를 들어 6005는 이벤트로그 서비스가 시작될 때 발생되는 이벤트ID.
	Event Type	이벤트의 심각도를 분류하여 나타낸다. 정보(Information), 경고(Warning), (오류)Error, (심각)Critical, 성공감사(Success Audit), 실패 감사(Failure Audit) 로 구분.
	Event Category	이벤트 카테고리
	Event Scource	이벤트를 기록한 소프트웨어 (이벤트가 일어난 프로세스)
	Computer	컴퓨터 이름
	Strings	설명에 사용된 문자열

[표 1] EVT 데이터

구분	속성	설명
EVTX	Source	이벤트를 기록한 소프트웨어 (이벤트가 일어난 프로세스)
	Event ID	특별한 이벤트 유형을 식별하는 값. 예를 들어 6005는 이벤트로그 서비스가 시작될 때 발생되는 이벤트ID.
	Level	이벤트의 심각도를 분류하여 나타낸다. 정보(Information), 경고(Warning), (오류)Error, (심각)Critical, 성공감사(Success Audit), 실패 감사(Failure Audit) 로 구분.
	User	이벤트 발생에 대한 사용자의 이름
	Operational Code	응용 프로그램에서 이벤트가 발생했을 때 활동이나 시점을 식별하는 숫자 값을 포함.
	Log	이벤트가 기록된 로그의 이름.
	Task Category	이벤트 게시자의 하위 구성요소 또는 활동을 표현하는데 사용.
	Keywords	이벤트를 검색하거나 필터링 하는데 사용할 수 있는 범주 또는 태그의 집합. ex) "네트워크", "보안", "리소스를 찾을 수 없습니다."
	Computer	이벤트가 발생한 컴퓨터의 이름.
	Date and Time	이벤트가 기록된 날짜 및 시간.
	Process ID	이벤트를 생성하는 과정에 대한 식별번호.
	Thread ID	이벤트 생성 쓰레드의 식별번호.

[표 2] EVTX 데이터

EVT파일은 윈도우즈 2000, 윈도우즈 XP, 윈도우즈 2003시스템에서 사용되는 이벤트 로그를 저장하는 파일의 형식 입니다. 일반적으로 System, Application, Security 이벤트 로그가 기록되며 시스템의 용도에 따라 추가적인 이벤트 로그가 존재할 수 있습니다.

[그림 1] EVT 저장경로

EVT파일위치는 레지스트리에서 확인할 수 있습니다.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog\ 레지스트리 경로 하위에 있는 System, Application, Security에서 File 값을 통해 각각 확인 할 수 있으며 일반적으로 “%SystemRoot%\System32\Config\” 하위에 위치합니다.

이벤트 로그의 종류는 아래와 같습니다.

구분	설명
시스템(System)	드라이버 로딩 등 시스템 구성 요소가 기록한 이벤트가 기록됩니다.
응용프로그램(Application)	응용프로그램이 기록하는 로그로 프로그램 개발자가 결정합니다.
보안(Security)	로그온 시도 및 성공, 파일 생성, 삭제 등의 이벤트를 기록합니다.

[표 3] EVT 로그 종류

이벤트 로그에 저장되는 이벤트 종류는 아래와 같습니다.

구분	설명
오류(Error)	오류 이벤트 로그는 데이터나 기능 손실 서비스 시작 실패와 같은 중요한 문제에 대해 기록 합니다.
실패 감사(Failure Audit)	감사대상에 대한 접근 시도가 실패했을 경우 기록됩니다. 예를 들어 시스템에 대한 로그인실패가 발생했을 경우 기록됩니다.
성공 감사(Success Audit)	실패 감사와는 반대로 감사대상에 대한 접근 시도가 성공했을 경우 기록됩니다.
정보(Information)	어플리케이션, 드라이버, 서비스의 성공적인 이벤트에 대하여 기록합니다. 예: 네트워크 드라이버가 성공적으로 로드 되었을 때 기록됩니다.
경고(Warning)	디스크 사용량이 많을 때와 같이 어플리케에서 데이터나 기능 손실 없이 회복할 수 있는 심각하지 않지만 추후 문제가 발생할 수 있는 문제에 대해 기록합니다.

[표 4] 이벤트 종류

EVTX파일은 윈도우즈 비스타 이후 시스템에서 사용되는 이벤트 로그를 저장하는 파일의 형식 입니다. 일반적으로 System, Application, Security 이벤트 로그와 같은 전역 로그 이외에 인터넷 익스플로러, 윈도우 파워셸, 하드웨어 이벤트, 윈도우 구성 요소 이벤트 등 100여 개의 이벤트 로그 파일을 확인할 수 있습니다.

[그림 2] EVTX 저장경로

EVTX파일위치는 레지스트리에서 확인할 수 있습니다.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog\ 레지스트리 경로 하위에 있는 System, Application, Security에서 File 값을 통해 각각 확인 할 수 있으며 일반적으로

“%SystemRoot%\System32\winevt\Logs 하위에 위치합니다.

구분	설명
시스템(System)	드라이버 로딩 등 시스템 구성 요소가 기록한 이벤트가 기록됩니다.
응용프로그램(Application)	윈도우 번들 소프트웨어를 비롯해서 사용자의 어플리케이션의 이벤트를 저장합니다.
보안(Security)	이 로그는 보안 관련된 이벤트 로그만을 기록합니다. 보안 관련된 프로그램의 동작을 모니터링하면서 그 외에도 윈도우 로그온, 네트워크 등 다양한 보안 로드들이 기록됩니다.
설치(Setup)	어플리케이션 설치 시 발생하는 이벤트를 기록합니다. 프로그램이 잘 설치되었는지 그리고 호환성문제가 일어나지 않는지 이 기록을 보면 알 수 있습니다.

[표 5] EVTX 로그 종류

이벤트 로그에 저장되는 이벤트 종류는 아래와 같습니다.

구분	설명
오류(Error)	오류 이벤트 로그는 데이터나 기능 손실 서비스 시작 실패와 같은 중요한 문제에 대해 기록 합니다.
실패 감사(Failure Audit)	감사대상에 대한 접근 시도가 실패했을 경우 기록됩니다. 예를 들어 시스템에 대한 로그인실패가 발생했을 경우 기록됩니다.
성공 감사(Success Audit)	실패 감사와는 반대로 감사대상에 대한 접근 시도가 성공했을 경우 기록됩니다.
정보(Information)	어플리케이션, 드라이버, 서비스의 성공적인 이벤트에 대하여 기록합니다. 예: 네트워크 드라이버가 성공적으로 로드 되었을 때 기록됩니다.
경고(Warning)	디스크 사용량이 많을 때와 같이 어플리케이션에서 데이터나 기능 손실 없이 회복할 수 있는 심각하지 않지만 추후 문제가 발생할 수 있는 문제에 대해 기록합니다.

[표 6] 이벤트 종류

1) EVT 구조

이벤트 로그에 저장되는 내용은 중요한 키워드만 포함되고 있으며 이벤트 뷰어와 같은 분석 툴에 표시될 때는 미리 지정된 템플릿을 활용하여 표시합니다.

[그림 3] EVT 구조

EVT파일은 이벤트로그의 시작을 의미하는 Header Record를 시작으로 각각의 Event Record가 연속되어 있는 형태이며 마지막 Event Record가 생성되면 해당 레코드 다음에 이벤트로그의 마지막을 의미하는 Cursor Record가 생성됩니다.

[그림 4] EVT 구조

① Header Record

헤더 레코드는 총 48bytes(0x30)으로 구성되어 있으며 해당 로그 파일의 사이즈, 가장 오래된 레코드 즉 첫 이벤트번호 그리고 현재 레코드, 즉 다음 이벤트 번호 등이 포함되어 있습니다.

아래는 실제 이벤트로그의 Header Record의 예입니다.

[그림 5] Header Record 구조

Header Record를 분석하면 아래와 같습니다.

②Event Record

Event Record에는 레코드의 사이즈, 레코드 넘버, 시간, 카테고리 등 각각의 이벤트에 대한 정보가 포함되어 있으며 시작과 마지막에 레코드의 사이즈가 표시됩니다. 로그분석 시 실제 이벤트가 저장되는 가장 핵심적인 부분입니다.

아래는 이벤트로그의 Event Record의 예입니다.

[그림 6] Event Record

Event Record를 분석하면 아래와 같습니다.

③Cursor Record

Cursor Record는 이벤트로그의 마지막을 표시하는 레코드로서 이벤트로그의 가장 처음과 마지막에 대한 정보가 포함되어 있습니다. One, Two, Three, Four값을 시그니처로 구분할 수 있으며 자세한 포함 내용은 아래 표와 같습니다.

아래는 이벤트로그의 Cursor Record의 예입니다.

[그림 7] Cursor Record

Cursor Record를 분석하면 아래와 같습니다.

2) EVTX 구조

EVTX는 EVT 파일의 진화된 형태로, 더 많은 이벤트 ID(Event ID) 필드를 포함하고 있습니다. EVTX 파일은 다수의 청크(Chunk)가 이어져 있는 형태로 구성되어 있습니다. 이 청크 내부에는 이벤트 레코드 기록이 존재하며 이러한 로그 기록들을 추출하여 피해시스템 분석에 활용할 수 있습니다.

이벤트 로그(EVTX)의 전체적인 구조는 다음과 같습니다.

[그림 8] EVTX 구조

①File header

EVTX 파일 헤더에는 각각의 오프셋에 시그니처, 청크(Chunk) 개수, 체크섬 등의 정보가 포함되어 있습니다. 각 오프셋에 대한 정보는 다음과 같습니다.

오프셋	사이즈	값	설명
0x00	8	ElfFile0x00	시그니처
0x08	8		첫 번째 청크(chunk) 넘버
0x10	8		마지막 청크(chunk) 넘버
0x18	8		다음 레코드 식별자
0x20	4	128	헤더 사이즈
0x24	2	1	Minor version
0x26	2	3	Major version
0x28	2	4096	헤더 블록 사이즈
0x2a	2		청크(chunk) 개수
0x2c	76		빈 값
0x78	4		파일 플래그
0x7c	4		체크섬(Checksum)

[표 7] File Header 오프셋 정보

EVTX는 ElfFile 이라는 시그니처로 시작됩니다. 청크 사이즈는 청크 하나의 크기이며, 기본적으로 1000h의 크기를 가지게 됩니다. 청크 카운트(Chunk Count)는 EVTX 파일 안에 몇 개의 청크가 들어있는지 나타내며 본 예시 이벤트 파일은 94개의 청크를 가지고 있습니다. 또한 Checksum CRC를 통해 데이터 변조에 대한 검증이 가능합니다.

[그림 9] File Header 구조

File Header 구조를 분석 하면 아래와 같습니다.

[그림 10] File Header 구조 분석

②Chunk header

각각의 청크 안에는 자기 자신에 대한 정보가 기록되어 있습니다. 해당 기록은 청크 내에 기록된 레코드의 시작 번호와 마지막 번호 등을 담고 있기 때문에 해당 청크가 몇 개의 레코드를 기록하고 있는지 알 수 있다. 본 예시의 청크는 124개의 레코드를 기록하고 있음을 확인할 수 있습니다. 각각의 청크 안에 체크섬이 있기 때문에 데이터 변조에 대한 검증이 가능합니다.

각 오프셋에 대한 정보는 다음과 같습니다.

오프셋	사이즈	설명
0x00	8	시그니처
0x08	8	첫 번째 이벤트 레코드 넘버
0x10	8	마지막 이벤트 레코드 넘버
0x18	8	첫 번째 이벤트 레코드 식별자
0x20	8	마지막 이벤트 레코드 식별자
0x28	4	헤더 사이즈
0x2c	4	마지막 이벤트 레코드 데이터 오프셋
0x30	4	여유 공간 오프셋
0x34	4	이벤트 레코드 체크섬
0x38	64	빈 값
0x78	4	알려지지 않음
0x7c	4	체크섬 (처음 120바이트와 청크의 128바이터 512바이트 사이의 데이터에 대한 오프셋)

[표 8] Chunk Header 오프셋 정보

[그림 11] Chunk Header 구조

Chunk Header 구조를 분석하면 아래와 같습니다.

③Event record

각각의 레코드에는 실제 로그 데이터가 들어있습니다. 실제로 레코드 내부의 바이너리 XML 영역을 분석하여 분석에 필요한 데이터를 추출하게 됩니다.

이벤트 레코드의 오프셋에 대한 정보는 다음과 같습니다.

[그림 12] Event record 오프셋 정보

[그림 13] Event record 분석

지금까지 이벤트 로그와 관련하여 저장경로, 각각의 구조에 대해 살펴 보았으며 다음 포스팅에서 이어서 이벤트로그 분석방법에 대해 알아 보겠습니다.

Windows Artifact[5] - Thumbnail/IconCache

www.gflow.co.kr — Thu, 12 Apr 2018 09:55:03 +0900

이번 포스팅에서는 썸네일과 아이콘 캐시에 대해서 알아보도록 하겠습니다.

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

썸네일과 아이콘 캐시는 윈도우 포렌식에 있어서 많은 정보를 제공해줍니다. 윈도우의 기본 기능인 미리보기 기능으로 해당 데이터를 파일에 저장하여 속도 향상에 도움을 줍니다. 미리보기 파일은 뜻하지 않게 증거분석에 많은 정보를 제공하게 됩니다. 사용자가 열어본 파일, 영상 등은 모두 파일의 썸네일 또는 아이콘 캐시에 저장 되기 때문입니다. 특히나 아이콘캐시의 경우 안티포렌식도구 사용 여부를 판별할 수 있으며, 외부 저장장치나 광학 장치의 사용흔적을 찾을 수 있습니다. 또한 프로그램을 삭제 하여도 아이콘 정보는 계속 유지됩니다.

1. 썸네일

▶윈도우 폴더 미리보기 기능에 사용

▶초기 방문시 썸네일을 저장해두고 재 방문 시 저장된 데이터를 보여줌 > 속도 향상

▶한번 저장된 썸네일은 원본이 지워져도 썸네일 파일은 잔존

▶Windows 7 이후 Thumbcache ##.db 로 관리

▶썸네일 지원 파일

-JPEG,BMP,GIF,TIF,DOCX,PPTX,PDF,HTM 등

썸네일이 저장되는 경로는 아래와 같습니다.

[그림 1] 썸네일 저장 경로

해당 폴더에 저장되는 Thumcache 정보는 다음과 같습니다.

▶Thumbcache idx.db : 썸네일의 인덱스 정보

▶Thumbcache sr.db : 알수 없음

▶Thumbcache 32.db : 32x32 픽셀보다 작은 썸네일이 저장

▶Thumbcache 96.db : 32x32 ~ 96x96 픽셀이 저장

▶Thumbcache 256.db : 96x96 ~ 256x256 픽셀 사이의 썸네일이 저장

▶Thumbcache 1024.db：256x256 ~ 1024x2014 픽셀이 저장

썸네일을 분석하기 위해 Thumbs.db Viewer 도구를 사용하였습니다.

[그림 2] 썸네일 분석

2. 아이콘 캐시

▶외부저장장치/광학드라이브 사용흔적 확인

▶안티 포렌식도구 사용흔적(아이콘)

▶악성코드흔적(아이콘 보유 시/애드웨어)

▶프로그램 사용흔적(프로그램을 삭제 하여도 Icon정보는 남음)

아이콘 캐시가 저장되는 경로는 아래와 같습니다.

[그림 3] 아이콘 캐시 저장 경로

아이콘 캐시를 분석하기 위해 IconCache Viewer 도구를 사용하였습니다.

[그림 4] 아이콘 캐시 분석

현재 아이콘 캐시분석 도구중에 무료로 배포되는 도구는 아이콘 모양까지는 나오지 않습니다. 하지만, 썸네일 분석에 사용한 도구

를 이용할 경우 아이콘 모양까지 모두 출력됩니다. 이는 상용버전과 무료 버전의 차이 이지만 무료버전일지라도 아이콘이 저장되

었던경로와 프로그램명이 나오기 때문에 분석에는 어려움이 없습니다.

지금까지 썸네일과 아이콘 캐시에 대해서 알아보았으며, 다음 포스팅에서는 이벤트 로그에 대해서 알아 보겠습니다.

Android App Hooking with Frida(2)

www.gflow.co.kr — Fri, 6 Apr 2018 17:58:42 +0900

이번 포스팅에서는지난시간에 이어서 Frida를 사용한 android app hooking에 대하여 다루도록 하겠습니다.

(도구 설치와 같은 기초 지식은 다루지 않습니다.)

문제파일은 아래 경로를 통하여 다운받을 수 있습니다.

https://github.com/OWASP/owasp-mstg/tree/master/Crackmes

분석환경

OS: Windows10

Tools: Frida, Frida-server, adb, Python3.6, Genymotion

문제파일(UnCrackable-Level2.apk)을 다운로드하여 설치합니다.

[그림 1 apk설치]

앱 설치 후 실행 시 루팅 탐지가 동작하며 ok버튼을 클릭하면 앱이 강제로 종료됩니다.

[그림 2 루팅탐지]

루팅탐지는 Level1 문제풀이때 설명하였으니 넘어가도록 하겠습니다.

문제파일의 MainActivity 살펴보면 Secret String입력 값에 따른 성공 및 실패 로직을 확인할 수 있습니다.

[그림 3 verify 함수 분석]

실제 CodeCheck 클래스를 살펴보면 bar함수에 Secret String이 전달되어 유효성을 체크하는 것을 확인할 수 있습니다.

[그림 4 CodeCheck bar 분석]

실제 해당 함수는 libfoo.so 라이브러리에서 찾을 수 있습니다.

[그림 5 libfoo.so 라이브러리 load 확인]

그럼 실제 해당 라이브러리 파일을 디스어셈블러(ida)를 사용하여 분석해보도록 하겠습니다.

genymotion의 경우 Intel x86으로 동작하게됩니다. 따라서 라이브러리 파일 분석 시 x86폴더 아래에 존재하는 libfoo.so 파일을 분석하도록 하겠습니다.

[그림 6 libfoo.so 분석]

함수를 분석하다보면 eax, 17h 를 비교하여 strncmp함수를 호출하는 영역으로 분기하는 구간을 확인할 수 있습니다.

17h는 십진수로 23이고 문자열의 길이가 23이면 strncmp함수를 호출하는 영역으로 넘어가도록 동작합니다.

우리는 여기서 Secret String의 길이가 23이라는 것을 파악할 수 있습니다.

[그림 7 b함수 분석]

strncmp함수는 문자열을 비교하여 그 결과를 반환하는 함수입니다.

Secret String을 입력받아 비교하여 결과를 반환하는 동작을 수행합니다.

그럼 우리는 strncmp함수의 인수를 출력하여 Secret String을 확인할 수 있을것입니다.

그럼 strncmp 함수를 후킹하여 실제 Secret String을 출력하는 코드를 작성하도록 하겠습니다.

Module.enumerateImportsSync() 를 이용하여 libfoo.so 라이브러리에 존재하는 함수 중 strncmp함수의 주소값을 얻어내고 hooking을 수행하여 Secret String을 얻어냅니다.

uncrackable2.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
import frida, sys
 
def on_message(message, data):
    if message['type'] == 'send':
        print("[*] {0}".format(message['payload']))
    else:
        print(message)
 
 
PACKAGE_NAME = "sg.vantagepoint.uncrackable2"
 
jscode= """
    Java.perform(function() {
        console.log("[*] Hooking calls to System.exit");
        exitClass = Java.use("java.lang.System");
        exitClass.exit.implementation = function() {
            console.log("[*] System.exit called");
        }
        var strncmp = undefined;
        func = Module.enumerateImportsSync("libfoo.so");
        for(i = 0; i < func.length; i++) {
        if(func[i].name == "strncmp") {
                strncmp = func[i].address;
                break;
            }
        }
        Interceptor.attach(strncmp, {
            onEnter: function (args) {
               if(args[2].toInt32() == 23 && Memory.readUtf8String(args[0],23) == "01234567890123456789012") {
                    console.log("[*] Secret string at " + args[1] + ": " + Memory.readUtf8String(args[1],23));
                }
             },
        });
        console.log("[*] Intercepting strncmp");
    });
"""
 
try:
    device = frida.get_usb_device(timeout=10)
    pid = device.spawn([PACKAGE_NAME])  
    process = device.attach(pid)
    device.resume(pid)
    script = process.create_script(jscode)
    script.on('message',on_message)
    print('[*] Running Hook')
    script.load()
    sys.stdin.read()
except Exception as e:
    print(e)
 
 
Colored by Color Scripter
cs

[그림 8 hooking code]

hooking 스크립트를 실행시킵니다.

[그림 9 hooking]

앱을 실행시킨 후 "01234567890123456789012"를 입력한 후 VERIFY를 클릭합니다.

[그림 10 VERIFY]

hooking이 성공하여 "thanks for all the fish" 라는 Secret String이 출력된 것을 확인할 수 있습니다.

[그림 11 Secret String 확인]

그럼 실제 해당 Secret String이 맞는지 확인해볼까요?

[그림 12 Secret String]

지금까지 Frida를 사용한 Android App Hooking에 대하여 알아봤습니다.

다음 포스팅에서는 세번째 Crackme 문제를 가지고 포스팅을 이어가도록 하겠습니다.

참고 : https://www.codemetrix.net/hacking-android-apps-with-frida-3/

Windows Artifact[3] - LNK

www.gflow.co.kr — Thu, 5 Apr 2018 09:46:57 +0900

(본 포스팅에서는 기본적인 도구 사용법에서는 다루지 않습니다)

이번 포스팅에서는 LNK파일 분석에 대해서 알보겠습니다.

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

1. LNK 파일

Windows Shortcut Files (MS-ShellLink) 는 윈도우 시스템에서 사용하는 파일에 대한 링크 파일입니다. 특정 실행파일을 간편하게 실행하기 위해 사용자 지정 위치에 링크되며, LNK 확장자를 가집니다.

LNK 파일은 사용자가 직접 생성하는 것 이외에도, Windows OS 설치 시 기본적으로 특정 경로에 바탕화면의 “내 컴퓨터”, “휴지통”부터 “최근 문서” 등과 같은 파일이 생성됩니다. 또한 윈도우 설치시 LNK파일 생성은 기본옵션으로 활성화 되어 있기 때문에 사용자가 파일이나 폳더를 액세스 할 경우 LNK파일이 생성됩니다.

LNK파일은 포렌식 분석관점에서 매우 중요한 아티팩트(증거)가 됩니다. 사용자가 최근 엑세스한 파일이나 접근한 폳더정보를 알 수 있으며, 외부로 유출된 자료조사 시 유용하게 활용할 수 있습니다.

2. LNK파일 저장경로

LNK파일이 저장되는 경로는 다음과 같습니다.

■C:\Users\Default\AppData\Roaming\Microsoft\Windows\Start Menu

-기본 시작메뉴

■C:\Users\<username>\Public

-관리자 라이브러리

■C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu

-사용자 시작메뉴

■C:\Users\<username>\Public

-사용자 라이브러리

■C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Recent

-최근문서

■C:\Users\<username>\Desktop

-사용자별 바탕화면

■C:\Users\<username>\AppData\Roaming\Microsoft\Windows\SendTo

-SendTo 메뉴 링크

■C:\Users\<username>\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch

-사용자 빠른실행

3. LNK파일 구조 분석

LNK 파일에서 파일 타임스탬프, 원본 파일 경로, 실행 옵션 등의 확인이 가능하며, 원본 실행파일에 대한 정보를 다음 5가지 부분의 구조를 가지고 있습니다.

구분	설명	비고
SHELL_LINK_HEADER	식별 정보, 타임스탬프, 선택 가능한 구조의 존재 유무 표시 플래그
LINKTARGET_IDLIST	원본에 대한 정보
LINKINFO	원본 위치를 찾을 때 필요한 정보
STRING_DATA	사용자 인터페이스나 경로 식별(Path identification) 정보
EXTRA_DATA	기타 정보

[표 1] LNK 포맷

1) SHELL_LINK_HEADER

SHELL_LINK_HEADER는 총 76 바이트이며, 헤더에는 식별 정보, 타임스탬프 등이 포함됩니다. 헤더의 구조는 다음과 같습니다.

[그림 1] SHELL_LINK_HEADER 분석

각 필드에 대한 내용은 아래 [표 2]와 같습니다.

필드명	설명	비고
HeaderSize	헤더의 크기	Default : 0x4C
LinkCLSID	클래스 식별자	Default : 00021401-0000-0000-C000-000000000046
LinkFlags	쉘 링크에 대한 정보와 어떤 구조체들이 추가로 포함되는지 알려줌
FileAttributes	파일 속성 정보로 원본에 대한 정보를 가짐
CreationTime	원본의 생성 시간	64비트 윈도우 시간
AccessTime	원본의 접근 시간	64비트 윈도우 시간
WriteTime	원본의 수정 시간	64비트 윈도우 시간
FileSize	원본의 파일 크기	원본 파일 크기 > 0xFFFFFFFF 인 경우 원본 크기가 좌측 32비트
IconIndex	아이콘 인덱스. 주어진 아이콘 위치 안에서의 아이콘 인덱스를 가리킴
ShowCommand	Shell Link에 의해 실행되는 애플리케이션의 윈도우 상태를 나타냄 0x1 : SW_NORMAL 0x2 : SW_SHOWMINIMIZED 0x3 : SW_SHOWMAXIMIZED
HotKey	바로가기에 의해 지정된 애플리케이션을 바로 실행하기 위한 키보드 조합
Reserved1	예약 영역	0 으로 채워짐
Reserved2
Reserved3

[표 2] SHELL_LINK_HEADER 필드 내용

2) LINKTARGET_IDLIST 분석

LINKTARGET_IDLIST는 바로가기의 필수 항목이며, 총 사이즈는 2바이트(IDList의 크기) + 가변(IDList) 입니다. 이 중 IDList는 다시 두 부분으로 나뉘는데, 첫째 부분은 2바이트 고정길이를 갖는 ItemIDSize 이며, 그 뒤로는 가변길이의 Data가 붙게 됩니다. IDList의 Data는 일정한 구조가 없으며 데이터의 맨 끝 위치에 2바이트의 예약영역이 존재합니다. 이 예약영역은 0으로 채워져 있으며, 데이터의 종료를 나타냅니다.

[그림 3] LINKTARGET_IDLIST

필드에 대한 내용은 아래와 같습니다.

필드명	설명	비고
IDListSize	IDList 의 크기
IDList (variable)	아이템들의 ID 리스트

[표 2] LINKTARGET_IDLIST 필드 내용

3) LinkInfo 분석

LinkInfo는 바로가기의 필수 항목이며, 원본 파일이 정해진 위치에 없는 경우 그것을 찾기 위한 필수 정보들을 가지고 있습니다. 그 필수 정보에는 원본이 저장되어 있던 볼륨의 정보 혹은 Mapped 드라이브 문자, 원본까지의 UNC 경로 등이 포함됩니다.

[그림 4] LinkInfo

각 필드에 대한 내용은 아래와 같습니다.

필드명	설명	비고
LinkInfoSize	LinkInfo 구조체의 크기
LinkInfoHeaderSize	LinkInfo Header 섹션의 크기
LinkInfoFlag	LinkInfo Flags. 전체 32비트 중 왼쪽 2비트만을 사용하며, 나머지는 0으로 채워짐
VolumeIDOffset	VolumeID 필드까지의 Offset
LocalBasePathOffset	LocalBasePath 필드까지의 Offset
CommonNetwork- RelativeLinkOffset	CommonNetworkRelativeLink 필드까지의 Offset
CommonPathSuffixOffset	CommonPathSuffix 필드까지의 Offset
LocalBasePathOffsetUnicode (optional)	LocalBasePath 필드까지의 Unicode Offset
CommonPathSuffixOffsetUnicode(optional)	CommonPathSuffix 필드까지의 Unicode Offset
VolumeID (variable)	바로가기가 생성 될 당시에 원본이 있던 볼륨의 데이터	원본이 제 위치에 없는 경우 찾는데 사용
LocalBasePath	Link 파일 또는 Link 대상 파일의 기본 경로 CommonPathSuffix 와 결합하여 전체 경로가 됨
CommonNetworkRelativeLink	Link Target 이 저장 된 네트워크 위치에 대한 정보
CommonPathSuffix	Link 파일 또는 Link 대상 파일의 파일 경로 LocalBasePath 와 결합하여 전체 경로가 됨
LocalBasePathUnicode	LocalBasehPath 의 Unicode 타입	LinkInfoHeader-Size 필드가 0x00000024 보다 클 경우 Enable
CommonPathSuffixUnicode	CommonPathSuffix 의 Unicode 타입	LinkInfoHeader-Size 필드가 0x00000024 보다 클 경우 Enable
VolumeIDSize	VolumeID 크기. 이 값은 반드시 0x10보다 커야 함
DriveType	드라이브 형태
DriveSerialNumber	드라이브의 시리얼 번호
VolumeLabelOffset	아스키 또는 유니코드 형식의 VolumeLabel 까지의 Offset
Data	VolumeLabel

[표 3]LinkInfo 필드 내용

드라이브 형태로는 아래와 같습니다.

문자열	설명	비고
DRIVE_UNKNOWN 0x00000000	알려지지 않은 타입
DRIVE_NO_ROOT_DIR 0X00000001	루트 경로를 사용할 수 없는 경우
DRIVE_REMOVABLE 0X00000002	이동형 저장장치 플로피 디스크, USB, 플래시 카드 리더 등
DRIVE_FIXED 0X00000003	고정형 저장장치
DRIVE_REMOTE 0X00000004	네트워크 드라이브
DRIVE_CDROM 0X00000005	CD-ROM
DRIVE_RAMDISK 0X00000006	RAM Disk

[표 4]DriveType

3. LNK파일 분석

LNK파일 분석은 LinkParser를 이용하여 분석 할 수 있습니다. [그림 5]는 LinkParser를 실행한 화면이며, [그림 6]은 분석 결과입니다.

[그림 5] LinkParser 도구 실행화면

[그림 6] Link파일 분석 내용

지금까지 LNK파일에 대해서 알아 보았으며, 다음 포스팅에서는 휴지통에 대해서 알아보겠습니다.

Windows Artifact[2] - MFT,Logfile

www.gflow.co.kr — Fri, 30 Mar 2018 13:39:14 +0900

이번 포스팅에서는 $MFT와 $Logfile을 분석하는 방법에 대해서 알아보겠습니다.

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

1.$MFT, $Logfile 추출하기

$MFT와 $Logfile은 FTK Imager를 통해 최상위 디렉토리에서 추출 가능합니다.

아래 [그림 1]번과 같이 [root]에서 $MFT와 $Logfile을 확인 할 수 있습니다. 해당 파일을 클릭하고 마우스 우클릭을 통해 추출 가능합니다.

[그림 1] 최상위 디렉토리 확인

마우스 우클릭을 하면 [그림 2]와 같이 [Export Files]메뉴를 확인할 수 있습니다.

[그림 2]파일 추출 메뉴 확인

오류없이 추출이 되면 [그림 3]과 같은 확엔 메시지창을 확인 할 수 있습니다.

[그림 3] $MFT, $Logfile 추출 성공

[그림 4] 추출된 $MFT, $Logfile

2. $MFT 분석

[그림 5] $MFT 디코딩

$MFT파일은 이전 포스팅에서 다룬 $MFT영역의 구조로 인코딩되어있기 때문에 디코딩 작업이 필요합니다. 그렇기 때문에 [그림 5]와 같이 $MFT를 분석해주는 도구를 써야합니다. 본 포스팅에서 사용된 도구는 analyzeMFT도구이며, 구글 검색을 통해 쉽게 다운가능합니다. 사용법은 [그림 5]에서 보는 것처럼 옵션으로 분석할 파일을 -f옵션으로 지정해주고 -o옵션으로 디코딩된 파일을 저장합니다.

파일의 디코딩이 끝나면 아래 [그림 6]과 같이 파일에 대한 경로와 파일 활성화여부, 시간정보 등을 알 수 있습니다.

[그림 6]$MFT 내용 확인

3. $Logfile 분석

$Logfile에는 윈도우를 사용하면서 남는 트랙젝션 로그를 기록 합니다. 즉 파일 삭제와 생성과 같은 로그를 기록 하므로 디지털포렌식을 수행함에 있어 꼭 분석해야하는 내용입니다.

[그림 7]과 같이 NTFS Log Tracker를 통해 $Logfile을 분석 할 수 있습니다. 도구를 실행후 분석할 파일을 지정해주고 파싱 버튼을 누릅니다.

[그림 7] NTFS Log Tracker를 이용한 $Logfile분석 하기

분석이 끝나면 [그림 8]과 같이 하단에 결과가 나오며, 해당결과를 중간의 [CSV Export]메뉴를 통해서 파일로 저장할 수 있습니다.

[그림 8]$Logfile 파일 분석 완료

저장된 파일을 열람하면 아래 [그림 9]와 같이 트랜젝션로그를 확인 할 수 있습니다. 파일 삭제 및 생성과 관련된 경로와 시간정보를 볼 수 있습니다.

[그림 9] $Logfile 내용 확인

$Logfile이 가지는 정보는 $MFT가 가지는 정보보다 더 유용하다고 볼 수 있습니다. 그 이유는 파일생성과 관련된 정보와 삭제된 정보를 담고 있기 때문에 사용자가 또는 악성코드가 생성하는 파일에 대해서 추적이 가능하며, 임의로 삭제한 파일에 대해서도 확인 할 수 있습니다.

지금까지 $MFT와 $Logfile분석에 대해서 알아보았으며 다음 포스팅에서는 링크파일 분석에 대해서 알아 보겠습니다.

Windows Artifact[1] - $MFT(4)

www.gflow.co.kr — Fri, 16 Mar 2018 09:55:50 +0900

이번 포스팅에서는 $MFT의 속성중 하나인 DATA속성에 대해서 알아보겠습니다.

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

3. $DATA($80)

$DATA 속성은 파일의 데이터를 담고 있습니다. 속성 헤더(속성타입~초기화된 크기) 이후에 바로 해당 파일의 데이터가 저장되는 구조로 되어있습니다.

[그림 1] $DATA($80)

[그림 2] $DATA($80)

$DATA속성을 분석하기전에 알아두어야 할 개념이 있는데 그것은 바로 레지던지 속성과 논 레지던트 속성입니다. 레지던트 속성은 이 $DATA속성에 파일내용을 같이 저장되는 경우이며, 논 레지던트의 경우 파일의 사이즈가 커 속성정보에 같이 파일 내용을 저장 못할 경우 새로 클러스터를 할당받아 저장하는 것을 말합니다. 즉 기본적으로 속성정보는 1024byte로 구성되어 있지만, 시스템 상 약 500byte정도가 이미 사용중에 있습니다. 따라서 700byte정도의 파일 사이즈가 넘어가면 논 레지던트 속성으로 파일 속성이 부여됩니다. 그렇기 때문에 논 레지던트 속성의 파일은 마지막 8byte에 실제 데이터가 저장된 주소를 저장하고 있습니다.

이번 예제에서는 논 레지던트 속성의 파일이므로 실제 데이터가 있는 위치로 가기 위해서는 다시한번 주소를 계산 해주어야 합니다.

[그림 1]에서 보는 바와 같이 마지막 8byte의 값을 확인하면 43 00 D1 01 D7 C0 D3 00 이 저장된 것을 확인 할 수 있습니다.

이 8byte의 첫 바이트는 클러스터사이즈와 파일의주소를 나타내는 크기를 나타냅니다.

43을 반으로 나누어 4|3 형태로 만든 후 앞의 4는 데이터가 저장된 주소의 크기를 나타내며, 뒤의 3은 파일을 저장하기 위해 새로 할당된 클러스터 크기를 나타냅니다. 즉 해석을 하면 4byte만큼의 주소값과 3byte만큼의 클러스터 크기를 할당했다고 볼 수 있습니다.

형태에 맞춰 다시 분석을 하면 00 D1 01 만큼의 클러스터 크기와 D7 C0 D3 00의 실제 데이터 주소를 알 수 있습니다.

$DATA속성에서 파일 사이즈를 구하면 $DATA속성에서 할당된 클러스터 크기와 비교했을때 할당되는 클러스터 배수를 알 수 있습니다.

마지막으로 실제 데이터가 저장된 주소로 가기 위해서는 클러스터 배수만큼 주소에 곱해주고 VBR 시작주소를 더해주면 됩니다. (데이터는 리틀엔디안 방식으로 저장되어 있기 때문에 빅엔디안 방식으로 변환해줍니다.)

>>(00 D3 C0 D7 * 8) + VBR시작주소

주의할점은 주소값을 더할때 모두 10진수로 변환하여 더해주어야 합니다.

[표 1] $DATA($80) 분석

지금까지 $DATA($80)속성에 대해서 알아보았으며 다음 포스팅에는 $MFT와 $LogFile분석에 대해서 알아 보겠습니다.