[안랩] 파일 기반의 탐지기법

[기획 특집]알려지지 않은 악성코드 탐지 기법

2006년은 컴퓨터 바이러스가 제작 된지 20주년을 기념하는 한 해였다.
이 20년이라는 긴 세월 속에서 컴퓨터 바이러스는 파일 감염을 목적으로 하는 바이러스(Virus)로부터 네트워크를 통한 급속한 확산을 시도하는 웜(Worm) 그리고 데이터 유출을 위한 트로이목마(Trojan Horse)에 이르기까지 다양한 모습으로 발전하였다. 이러한 악성 코드의 위협은 해가 갈수록 증가 추세를 이루고 있으며 기술적인 면에서도 더욱더 위험성을 더해 가고 있어 컴퓨터 사용자들을 불안하게 만들고 있는 것이 사실이다. 그러나 이렇게 증가하는 악성 코드의 위협 에 맞서는 안티 바이러스(Anti-Virus) 업체 역시 새로운 악성 코드의 위협들로부터 컴퓨터 시스템을 보호하기 위해 다양한 대응 방안들을 활발하게 연구하고 있다.
이러한 다양한 대응 방안들의 기본 전제가 바로 “급속하게 확산되는 알려지지 않은 새로운 악성 코드에 어떻게 대응할 것인가?”라는 점이다. 이 명제는 결국 새로운 악성 코드를 어떻게 효과적으로 탐지할 것인가의 문제로 볼 수 있다. 이러한 문제를 해결하기 위해 안티 바이러스(Anti-Virus) 업체의 알려지지 않은 악성 코드 위협에 대응하기 위한 다양한 안티 바이러스(Anti-Virus) 탐지 기법들과 그 탐지 기법들의 특징들에 대해서 알아 보도록 하자.

[1] 악성코드의 증가와 조기 대응의 필요성
[2] 파일기반의 탐지 기법
[3] 에뮬레이터와 샌드박스
[4] MIME 필터링 탐지 기법
[5] 행위 기반 탐지 기법

2. 파일기반의 탐지 기법(File Base Detection Tech)

현재까지 알려진 안티 바이러스(Anti-Virus) 소프트웨어 대부분이 파일 기반(File Base)의 진단법을 사용하고 있다. 이는 대부분의 악성 코드가 특정 운영체제에서 실행되기 위해서는 해당 운영체제에서 실행이 가능한 특정한 파일 형태로 되어 있다는 점에서 기인한 것이다. 그러므로 악성 코드가 윈도우 시스템(Windows System)에서 실행되기 위해서는 윈도우 시스템에서 실행 가능한 파일 포맷인 PE(Portable Executable) 형식을 가지고 있어야 된다는 것이다.


[그림 3] PE(Portable Executable) 형식의 악성 코드 파일

이러한 PE(Portable Executable) 형식의 악성 코드를 진단하기 위해서는 안티 바이러스(Anti-Virus) 소프트웨어 역시 이러한 파일 형식을 인식하고 악성 코드로 판단을 내릴 수 있는 특정 형식의 시그니처(Signature)를 가지고 있어야 된다. 이러한 진단법이 대부분의 안티 바이러스(Anti-Virus) 소프트웨어가 사용하는 시그니처 기반(Signature Base) 또는 스트링(String – 여기서 말하는 스트링이란 일반적인 문자열이 아닌 파일의 헥사코드(Hex Code)를 의미하는 것이다.) 검사 방식이라고 이야기하는 진단법이다. 이러한 시그니처 기반(Signature Base)의 진단법은 악성 코드로 분류된 파일의 특정 부분 또는 고유한 부분을 검사의 대상으로 삼으므로 오탐(False Positive)과 미탐(False Negative)을 최소화하는 정확한 진단이 가능하다는 것과 파일 검사 시에 파일들의 특징적인 부분들만 비교 함으로 빠른 스캐닝(Scanning)을 장점으로 들 수 있다.

그러나 이러한 시그니처 기반(Signature Base) 진단법은 악성 코드의 파일 자체가 몇 백 바이트(Byte)만 바뀌어도 진단이 되지 않는 미탐(False Negative)이 발생함으로 파일이 조금만 변경된 새로운 변형에 대해서는 대응을 할 수가 없게 된다. 그리고 기존에 알려진 악성 코드에 대해서만 대응을 할 수 있으므로 새로운 형태의 알려지지 않은 악성 코드에 대해서는 대응을 할 수 없다는 단점을 가지고 있다.

1) 휴리스틱 탐지 기법 (Heuristic Detection Tech)

이러한 시그니처 기반(Signature Base)의 진단법이 가지고 있는 한계를 극복하고자 개발한 탐지 기법 중 하나가 휴리스틱 탐지(Heuristic Detection) 기법이다. 휴리스틱 탐지(Heuristic Detection) 기법은 일반적인 악성 코드가 가지고 있는 특정 폴더에 파일 쓰기와 특정 레지스트리 부분에 키 생성과 같은 명령어(Instruction)들을 스캐닝 엔진(Scanning Engine)에서 시그니처(Signature)화하여 파일을 검사할 때 이를 사용한다. 그래서 검사 대상 파일이 휴리스틱 시그니처(Heuristic Signature - 이 것을 부스터(Booster)라고도 한다.)와 비교를 통하여 일반적으로 알려진 악성 코드와 얼마나 높은 유사도를 가지고 있는지를 판단하여 알려지지 않은 새로운 악성 코드를 탐지하는 기법이다.
이러한 휴리스틱 탐지(Heuristic Detection) 기법은 검사 대상이 되는 파일에 대해서 휴리스틱(Heuristic) 검사 시에 스캐닝 엔진(Scanning Engine)이 어떠한 형태를 취하는가 에 따라서 아래와 같이 크게 2가지 형태로 나누어서 볼 수 있다.

- 동적 휴리스틱 탐지 기법 (Dynamic Heuristic Detection Tech)
동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법은 검사 대상이 되는 파일을 가상화된 영역 또는 운영체제와 분리된 특정 공간에서 파일 실행(File Execution)을 통해 수집한 다양한 정보들을 휴리스틱 시그니처(Heuristic Signature)와 비교를 통하여 검사를 수행하는 기법이다. 즉 검사 대상이 되는 파일이 어떠한 형식으로든 실행이 되어야 하며 이러한 점으로 인해 런 타임 휴리스틱 탐지 (Run-Time Heuristic Detection) 기법이라고도 불리고 있다. 이러한 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법은 이 후에 다룰 에뮬레이터(Emulator)과 샌드박스(Sandbox)에서 조금 더 자세하게 알아 보도록 하자.

- 정적 휴리스틱 탐지 기법 (Static Heuristic Detection Tech)
정적 휴리스틱 탐지(Static Heuristic Detection) 기법은 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법과는 반대로 파일에 대해서 어떠한 형식의 파일 실행(File Execution) 없이 파일 자체를 그대로 스캐닝 엔진(Scanning Engine)에서 읽어 들여 휴리스틱 시그니처(Heuristic Signature)와 비교를 수행하는 탐지 기법이다.


[그림 4] 정적 휴리스틱(Static Heuristic)과 동적 휴리스틱(Dynamic Heuristic)

이 외에도 네거티브 휴리스틱(Negative Heuristic – 이 것을 스토퍼(Stopper)라고도 한다.)탐지 기법도 있다. 이는 이제까지 기술한 휴리스틱 탐지(Heuristic Detection) 기법과는 반대로 악성 코드에서 전형 사용하지 않은 윈도우 팝업 창 생성과 같은 명령어(Instruction)들이 존재 할 경우에는 악성 코드로 판단하지 않는 기법이다. 즉, 휴리스틱 시그니처(Heuristic Signature)와 동일한 명령어들이 존재하지 않는 부정의 경우에만 악성 코드로 판단한다.
이러한 형태들의 휴리스틱 탐지(Heuristic Detection) 기법은 기존에 알려진 악성 코드도 탐지가 가능하며 알려지지 않은 새로운 악성 코드 역시 탐지가 가능하다는 점에서 매력적인 탐지기법이라고 할 수 있다. 그러나 이 탐지 기법은 정상 파일을 악성 코드라고 판단하게 되는 오탐(False Positive)의 발생이 가장 큰 단점으로 작용한다. 특히나 파일을 삭제하고 치료하는 안티 바이러스(Anti-Virus) 소프트웨어의 특성상 오탐(False Positive)율이 높게 된다면 컴퓨터 시스템 자체에 큰 문제를 유발할 수 있게 됨으로 이는 치명적인 문제점이라고 볼 수 있다.

2) 제너릭 탐지 기법 (Generic Detection Tech)

앞서 설명한 휴리스틱 탐지(Heuristic Detection) 기법 외에도 알려지지 않은 악성 코드를 탐지하기 위한 기법 중에는 제너릭 탐지(Generic Detection) 기법이라는 것이 있다. 이 탐지 기법은 유사한 형태의 악성 코드 집합을 탐지하기 위해 해당 집합을 이루는 악성 코드 파일들의 공통된 코드 영역(Code Section)을 진단하도록 한다. 그러므로 소스 코드(Source Code)상에서 사용자 코드(User Code)의 변화가 없거나 약간의 수정만 가하여 컴파일(Compile)만 새롭게 하여 생성한 새로운 악성 코드 변형들에 대해 탐지가 가능함으로 유사한 형태의 악성 코드 변형들이 지속적으로 제작되더라도 시그니처(Signature) 업데이트 없이 탐지가 가능하다는 장점이 있다.

이러한 제너릭 탐지(Generic Detection) 기법에서는 일반적으로 파일에 대한 OPcode(Operation Code) 명령어 비교 방식이 많이 사용되고 있다. 이 OPcode(Operation Code) 명령어 비교 방식에는 크게 와일드카드 비교(Wildcard Matching – Don’t Care 비교라고도 한다)와 미스매칭(Mismatching) 방식으로 나누어진다. 먼저 와일드카드 비교(Wildcard Matching)는 유사한 형태의 악성 코드 변형들의 특정 코드 영역(Code Section)에서 사용되는 OPcode(Operation Code) 명령들이 조금씩만 다르고 동일할 경우 해당 다른 OPcode(Operation Code) 명령어 부분에 와일드카드를 적용하여 다른 OPcode(Operation Code) 명령어가 사용되어도 이를 무시하겠다는 것이다.


[그림 5] 메모장(Notepad.exe) 프로그램의 OPcode(Operation Code) 명령어들

[그림 5]를 예로 들어 메모장 프로그램을 원본 악성 코드라고 가정을 한다면 이 원본 악성 코드의 일부 OPcode(Operation Code) 명령어들은 [그림 5]의 붉은색 박스 영역의 순서대로 진행된다. 이렇게 PUSH, PUSH, PUSH, PUSH 순서로 진행되는 OPcode(Operation Code) 명령어들이 다른 악성 코드 변형들에서는 PUSH, PUSH, PUSH, MOV가 사용된다면 마지막 MOV 부분을 와일드카드(Wildcard)로 적용하여 마지막 4번째 OPcode(Operation Code) 명령은 어떠한 것이 사용되더라도 이에 구애 받지 않겠다는 것이다. 이렇게 적용하게 되면 원본 악성 코드와 변형 악성 코드의 전체 OPcode(Operation Code) 명령어 진행 순서는 유사한데 일부가 조금 틀리더라도 모두 진단하게 되는 효과를 구현할 수가 있다. 그러나 미스매칭(Mismatching) 방식은 와일드카드 비교(Wildcard Matching)와는 반대로 MMX(Multi Media eXtension) 명령어 또는 FPU(Floating Point Unit) 명령어와 같이 악성 코드에서 잘 사용되지 않는 명령어들이 [그림 5]의 해당 붉은색 박스영역과 같이 특정 부분에 사용 될 경우, 해당 파일을 악성 코드 변형으로 판단하지 않겠다는 것이다. 이런 미스매칭(Mismatching) 방식은 앞서 설명한 네거티브 휴리스틱(Negative Heuristic) 탐지 기법과 기본적인 개념은 동일하다고 볼 수 있다.

그러나 이러한 제너릭 탐지(Generic Detection) 기법은 악성 코드의 공통된 코드 영역을 진단함으로 새로운 악성 코드 변형들이 제작되더라도 탐지가 가능하다는 장점이 있지만 새로운 악성 코드 변형들이 완전히 새로운 OPcode(Operation Code) 명령어 순서로 진행된다던가 아니면 안티 디버깅(Anti-Debugging)과 암호화(Encryption) 등과 같이 실행 파일 보호 기법을 통해 OPcode(Operation Code) 명령어의 진행 순서를 뒤섞어 놓게 된다면 스캐닝 엔진(Scanning Engine)에서는 이를 탐지하지 못하게 되는 문제가 발생할 수가 있다.

이상으로 파일을 기반으로 알려지지 않은 악성 코드 탐지 기법들에 대해서 알아 보았다. 다음으로는 파일 실행을 통해서 탐지하는 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법 설명 시에 잠시 언급한 에뮬레이터(Emulator)와 샌드박스(Sandbox)에 대해서 알아보도록 하자.[Ahn]

[저자] 안철수연구소 ASEC 장영준 주임연구원