KR101053470B1 - 유해 트래픽 제어 및 해킹을 차단하는 장치 및 방법 - Google Patents

Abstract

네트워크 통신을 시도한 쓰레드의 스택 메모리를 역추적하여 실제 통신에 관여한 모듈만 선별적으로 악성 모듈 검사를 수행하는 유해 트래픽 제어 및 해킹을 차단하는 장치 및 방법이 개시된다.

이를 위하여, 유해 트래픽 제어 및 해킹을 차단하는 장치는 응용 프로그램이 운영체제로 요청한 통신 요청을 모니터링하는 통신 요청 모니터링부, 상기 통신 요청 모니터링부에서 수신한 통신 요청의 발신 쓰레드를 판독하는 쓰레드 판독부, 상기 쓰레드 판독부에서 판독된 쓰레드의 스택 메모리를 역추적하여 상기 통신 요청과 관련된 모듈을 선별적으로 검사하는 스택 역추적을 통한 모듈 검사부, 상기 스택 역추적을 통한 모듈 검사부의 검사 결과에 따라 통신 요청을 허용하거나 차단하는 통신 요청 처리부를 포함한다.

이에 의하여, DLL 인젝션이나 변조된 DLL에 의한 해킹을 차단할 수 있으며, 실제로 통신에 관여한 모듈만 선별적으로 악성 모듈 검사를 함으로써 프로세스 공간 내의 모든 모듈을 검사함으로써 발생되는 불필요한 부하를 방지할 수 있다.

방화벽, 트래픽, 악성코드, 스택, 스택프레임, 쓰레드, IRP, 커널모드, 드라이버

Description

유해 트래픽 제어 및 해킹을 차단하는 장치 및 방법{System and method for protecting against malicious traffic and from hacking}

본 발명은 컴퓨터 상에서 운용되는 네트워크 방화벽에 관한 것으로서, 보다 상세하게는 네트워크 통신 요청을 시도한 쓰레드의 스택 메모리를 역추적하는 방법을 이용하여 실제 네트워크 통신에 관여한 모듈(EXE, DLL 등)에 대해 선별적으로 악성 해킹 툴 여부를 검사, 차단하는 장치 및 방법에 관한 것이다.

초고속 인터넷이 널리 보급되면서 현재 대부분의 개인용 컴퓨터는 항상 인터넷에 연결되어 있는 환경을 갖추게 되었으며, 이러한 인터넷을 경유한 악의적인 해커의 직접적인 공격이나 악성코드를 통한 해킹 및 개인 정보 유출을 막기 위해 다양한 보안 대책의 필요성이 대두되었다. 악성코드란 사용자 몰래 유해한 트래픽(DDOS 공격 목적 혹은 스팸 메일 발송 목적 등)을 발생시키고 개인 정보를 유출하여 해킹을 시도하는 등 컴퓨터 사용자의 이익과 의사에 반하여 악의적인 작동을 하는 프로그램을 통칭한다.

현재 이러한 위협을 차단하기 위해 가장 널리 사용되는 보안 대책으로는 안티바이러스(백신) 제품이 있다. 그러나 백신은 이미 알려진 악성 코드에 대하여는 방어가 가능하나, 아직 백신 개발업체에 의해 발견되지 않은 해킹 툴에 의한 개인 정보 유출 문제에 대해서는 방어를 할 수 없다는 문제점이 있다.

2009년 2월 11일자 중앙일보에 의하면, 2008년 12월 29일에 개인 PC 상에 설치된 악성 해킹 툴에 의해 공인인증서가 해커의 손에 넘어가 은행 계좌에서 1400만원이 무단인출되는 사고가 발생한 사례가 있으며, 2009년 1월 5일에도 악성 해킹툴에 의해 공인인증서 및 키보드 입력을 가로채는 방법으로 하나은행 인터넷 뱅킹을 통해 2100만원이 무단인출되는 사고가 발생한 바 있다.

또한, 2009년 3월 29일자 뉴욕타임즈에 의하면, 중국의 해커가 전세계 103개국의 정부 및 민간기관의 전산망에 침투, 1295대의 컴퓨터에서 문서를 해킹한 사례가 있으며, 이 사건 역시 “고스트넷”이라고 이름붙여진 악성 해킹툴에 의한 정보 유출로 확인된 바 있다. 특히 이 사건에서는 한국의 대사관 컴퓨터에서도 해킹당한 사실이 발견되었다는 점에서 악성 해킹툴에 의한 피해가 심각한 수준임을 알 수 있다.

이러한 사례에서 보듯이, 해커가 직접 제작한 해킹 툴과 같이 알려지지 않은 해킹툴의 경우에는 기존의 백신 제품만으로 차단하는 것은 한계가 있으며, 이러한 악성 해킹툴에 의한 정보 유출을 막기 위해서는 네트워크 방화벽 제품을 반드시 함께 사용해야 한다.

초기의 방화벽 제품들은 패킷의 출발지 주소, 포트와 목적지 주소, 포트를 기준으로 트래픽을 필터링하는 방식을 사용하였다. 그러나 이러한 방식은 관리자에 의해 허용된 포트번호를 악용하는 해킹툴에 의한 해킹을 막기 어렵고, 임시 포트 번호(ephemeral port number)를 사용하는 인스턴트 메신저나 P2P 응용 프로그램의 경우는 적용이 어렵다는 문제점이 있다.

최근의 보다 진보된 형태의 방화벽 제품에서는 네트워크 통신이 허용된 프로그램(EXE) 목록을 지정하는 방식을 이용한다. 이 방식에서는 사용자가 네트워크 통신을 허용할 프로그램 목록을 수동으로 입력하거나, 특정 프로그램이 통신을 시도하려고 할 때 허용 여부를 사용자에게 질의함으로써 허용 프로그램 목록에 새로운 프로그램을 추가시키는 방법을 사용한다. 이러한 방식을 이용하면 임시 포트 번호를 이용하는 인스턴트 메신저나 P2P 프로그램도 유연하게 설정이 가능하다. 현재 윈도우 운영체제에 포함되어 있는 방화벽이 이러한 모델을 사용하고 있는 예이다.

그러나, 이러한 EXE 파일 목록에 기반한 방식에서는 프로세스를 대표하는 EXE 파일을 기준으로 허용 설정을 하기 때문에, DLL 인젝션 기술을 이용하여 악의적인 DLL을 정상적인 프로세스 공간 내로 침투시키는 경우나, EXE 파일이 묵시적 혹은 명시적으로 로딩하는 DLL 파일이 바이러스 등에 의해 변조되었거나 악의적인 목적으로 만들어진 악성 모듈인 경우, 이를 구별하여 차단하지 못한다는 문제점이 있다.

DLL 인젝션이란 해킹툴에서 많이 사용되는 기술로, 임의의 DLL 모듈을 임의의 프로세스 공간 내로 침투시켜 악성 DLL 모듈의 제작자가 원하는 기능을 해당 프로세스 내에서 해당 프로세스의 권한으로 실행시키는 기술을 말한다.

또한, EXE 파일 목록에 기반하여 네트워크 통신을 허용하는 모델에서는 해당 프로세스 내에 악의적인 DLL 모듈이 로딩되어 있는가를 확인하려면 해당 프로세스 내에 로딩되어 있는 전체 모듈을 대상으로 조사해야 하기 때문에, 악성 모듈 검사에 과도한 부하가 발생되는 문제점이 있다.

상기한 종래 기술의 문제점을 해결하기 위하여 안출된 본 발명은, 네트워크 통신을 시도한 쓰레드를 판독하고 쓰레드의 스택 메모리를 역추적하는 방법을 이용하여, 실제로 통신에 관여한 모듈들만 통신이 이루어지기 직전에 선별적으로 악성코드 검사를 함으로써, DLL 인젝션이나 변조된 DLL에 의한 해킹을 차단할 수 있으며, 실제로 통신에 관여한 모듈만 선별적으로 악성 모듈 검사를 함으로써 프로세스 공간 내의 모든 모듈을 검사함으로써 발생되는 불필요한 부하를 방지하는 유해 트래픽 제어 및 해킹을 차단하는 장치 및 방법을 제공하기 위함을 목적으로 한다.

상기 목적을 달성하기 위한 본 발명은, 유해 트래픽 제어 및 해킹을 차단하는 장치로서,

응용 프로그램이 운영체제로 요청한 통신 요청을 모니터링하는 통신 요청 모니터링부와;

상기 통신 요청 모니터링부에서 수신한 통신 요청의 발신 쓰레드를 판독하는 쓰레드 판독부와;

상기 쓰레드 판독부에서 판독된 쓰레드의 스택 메모리를 역추적하여 상기 통신 요청과 관련된 모듈을 선별적으로 검사하는 스택 역추적을 통한 모듈 검사부와;

상기 스택 역추적을 통한 모듈 검사부의 검사 결과에 따라 통신 요청을 허용하거나 차단하는 통신 요청 처리부;를 포함하고,

상기 스택 역추적을 통한 모듈 검사부는, 상기 쓰레드 판독부에서 판독된 쓰레드의 컨텍스트를 추출하는 쓰레드 컨텍스트 추출부와; 상기 쓰레드 판독부에서 판독된 쓰레드의 스택 메모리를 상기 쓰레드 컨텍스트 추출부에서 추출된 베이스 포인터 레지스터의 값을 이용하여 역추적하는 스택 역추적부와; 상기 쓰레드 컨텍스트 추출부와 상기 스택 역추적부에서 추출한 명령어 포인터의 주소에 해당하는 모듈을 추출하는 모듈 추출부와; 상기 모듈 추출부에서 추출된 모듈을 대상으로 악성 모듈 검사를 할 것인지를 판단하여, 악성 모듈 검사를 할 필요가 있다고 판단되면 악성 모듈 검사부를 이용하여 악성 모듈 검사를 하고, 악성 모듈 검사를 할 필요가 없다고 판단되면 악성 모듈 검사를 생략하도록 하는 모듈 필터링부와; 상기 모듈 필터링부에서 악성 모듈 검사를 할 필요가 있다고 판단된 모듈을 대상으로 악성 모듈 검사를 수행하는 악성 모듈 검사부;를 포함하는 것을 특징으로 한다.

또한, 상기 목적을 달성하기 위한 본 발명은, 유해 트래픽 제어 및 해킹을 차단하는 방법으로서,

응용 프로그램이 운영체제로 요청한 통신 요청을 모니터링하는 통신 요청 모니터링 단계;

상기 통신 요청 모니터링 단계에서 수신된 통신 요청에서 통신 요청의 발신 쓰레드를 판독하는 쓰레드 판독 단계;

상기 쓰레드 판독 단계에서 판독된 쓰레드의 스택 메모리를 역추적하는 방법으로 악성 모듈을 검사하는 스택 역추적을 통한 모듈 검사 단계;

상기 스택 역추적을 통한 모듈 검사 단계의 검사 결과에 따라 통신 요청을 허용하거나 차단하는 통신 요청 처리 단계;를 포함하고,

상기 스택 역추적을 통한 모듈 검사 단계는, 상기 쓰레드 판독 단계에서 판독된 쓰레드의 컨텍스트를 추출하여, 쓰레드 컨텍스트 내의 베이스 포인터를 BP 변수에, 명령어 포인터를 IP 변수에 대입하는 쓰레드 컨텍스트 추출 단계; 상기 IP 변수의 값이 가리키는 주소에 로딩되어 있는 모듈을 추출하는 IP 주소의 모듈 추출 단계; 상기 IP 주소의 모듈 추출 단계에서 추출된 모듈을 대상으로 악성 모듈 검사를 할 것인지를 판단하여, 악성 모듈 검사를 할 필요가 있다고 판단되면 하기의 악성 모듈 검사 단계로 진행하고, 악성 모듈 검사를 할 필요가 없다고 판단되면 하기의 악성 모듈 검사 단계를 생략하고 하기의 스택 프레임 추출 단계로 진행하는 모듈 필터링 단계; 상기 모듈 필터링 단계의 판단 결과 악성 모듈 검사를 할 필요가 있다고 판단된 모듈을 대상으로 악성 모듈 검사를 하여 악성 모듈이라면 상기 모듈을 악성 모듈로 판단하는 악성 모듈 검사 단계; 상기 모듈 필터링 단계에서 악성 모듈 검사를 할 필요가 없다고 판단되었거나 상기 악성 모듈 검사 단계에서 악성 모듈이 아닌 것으로 판단되면, 상기 쓰레드의 스택 메모리에서 스택 프레임을 추출하여, 스택 프레임 내의 베이스 포인터를 BP 변수에, 명령어 포인터를 IP 변수에 저장하는 스택 프레임 추출 단계; 상기 스택 프레임 추출 단계의 실행 결과, 더 이상 조사할 스택 프레임이 없다면 악성 모듈이 발견되지 않은 것으로 판단하고, 더 조사할 스택 프레임이 있다면 상기 IP 주소의 모듈 추출 단계로 되돌아가 처리를 계속하는 마지막 스택 프레임 판단 단계;를 포함하는 것을 특징으로 한다.

본 발명에서 창안한 유해 트래픽 제어 및 해킹을 차단하는 장치 및 방법에 따르면, 네트워크 통신을 시도한 쓰레드를 판독하고 쓰레드의 스택 메모리를 역추적하는 방법을 이용하여, 실제로 통신에 관여한 모듈들만 통신이 이루어지기 직전에 선별적으로 악성코드 검사를 함으로써, DLL 인젝션이나 변조된 DLL에 의한 해킹을 차단할 수 있으며, 실제로 통신에 관여한 모듈만 선별적으로 악성 모듈 검사를 함으로써 프로세스 공간 내의 모든 모듈을 검사함으로써 발생되는 불필요한 부하를 방지할 수 있다.

따라서, 본 발명을 방화벽 소프트웨어에 접목하면 종래의 방화벽 기술로 차단이 불가능했던 DLL 인젝션의 경우나 바이러스 등에 감염된 악성 모듈의 경우에도 차단이 가능해져, 아직 발견되지 않은 악성 해킹 툴에 의해 발생되는 개인 정보 유출이나 인터넷 뱅킹을 통한 무단 인출 등의 해킹 사고를 막을 수 있다. 또한, 실제 통신에 관여한 모듈만 선별적으로 검사함으로써 방화벽 소프트웨어 작동시 발생되는 부하를 줄일 수 있다.

이하 첨부된 도면을 참조하여 본 발명의 일실시예를 상세히 설명한다.

도 1은 본 발명의 바람직한 실시예에 따른 유해 트래픽 제어 및 해킹을 차단하는 장치를 도시한 블록도이다.

도 1을 참조하면, 유해 트래픽 제어 및 해킹을 차단하는 장치(110)은 응용 프로그램(120)의 네트워크 통신 요청을 모니터링하는 통신 요청 모니터링부(111); 상기 통신 요청 모니터링부에서 수신한 네트워크 통신 요청의 발신 쓰레드를 판독하는 쓰레드 판독부(112); 상기 쓰레드 판독부에서 판독된 쓰레드의 스택 메모리를 역추적하면서 상기 통신 요청에 관여한 모듈들을 검사하는 스택 역추적을 통한 모듈 검사부(113); 상기 모듈 검사 결과에 따라 네트워크 통신 요청을 허용하거나 차단하는 통신 요청 처리부(114)를 포함한다.

상기 유해 트래픽 제어 및 해킹을 차단하는 장치(110)는 컴퓨터 내에서 실행 중인 하나 이상의 응용 프로그램(120)과 네트워크 인터페이스 카드(130) 사이에 위치하여, 외부로 나가는 트래픽과 내부로 들어오는 트래픽을 대상으로 유해 트래픽 제어 및 해킹을 차단한다.

통신 요청 모니터링부(111)는 응용 프로그램(120)이 운영체제로 요청한 네트워크 통신 요청을 모니터링하고 수신한다. 응용 프로그램(120)은 운영체제에서 제공하는 통신 관련 API를 호출하여 네트워크 통신을 수행하며, 이 네트워크 통신에는 데이터 송신, 데이터 수신, 서버 포트 개설, 상대 호스트로의 연결 등이 포함된다. 이때 사용되는 통신 관련 API의 예로는 connect(), listen(), recv(), send(), recvfrom(), sendto() 등이 있다.

통신 요청 모니터링부가 구현되는 방법은 크게 커널 모드의 드라이버를 이용하는 방법과 API 후킹을 이용하는 방법이 있다.

커널 모드의 드라이버로 구현할 때에는 운영체제에 의해 제공되는 전송 계층 드라이버의 상단에 필터 드라이버 형태로 구현하는 것이 바람직하다. 전송 계층 드라이버는 윈도우 운영체제에서 OSI 참조 모델의 전송 계층에 해당하는 TCP, UDP 등의 프로토콜을 구현하는 드라이버로, 네트워크 관련 드라이버 스택 중 최상단에 위치하고 있다. 이 전송 계층 드라이버의 상단에 필터 드라이버로 설치를 하면 네트워크 통신을 요청하는 사용자 모드 쓰레드와 같은 컨텍스트에서 실행이 되기 때문에 해당 네트워크 통신을 요청한 쓰레드를 판독하는 데 용이한 면이 있다. 전송 계층 드라이버는 TDI(Transport Driver Interface)라는 운영체제 내부에서 표준화된 인터페이스를 상위 드라이버나 TDI 클라이언트에게 공개한다. 따라서 통신 요청 모니터링부(111)를 구현하는 필터 드라이버는 전송 계층 드라이버가 제공하는 TDI 인터페이스에 따라 연결 요청, 서버 포트 개설 요청, 데이터 송신 요청, 데이터 수신 요청에 대한 모니터링을 수행할 수 있다. TDI 인터페이스와 관련된 세부 명세는 마이크로소프트사에 의해 문서로 공개되어 있다. 전송 계층 드라이버의 상단에 필터 드라이버 형태로 구현하는 방법 외에, NDIS IM(Intermediate) 드라이버로 구현하는 방법도 가능하다.

커널 모드의 드라이버로 통신 요청 모니터링부(111)를 구현하면, 응용 프로그램이 요청한 네트워크 통신 요청은 윈도우 커널의 I/O 매니저에 의해 IRP(I/O Request Packet)의 형태로 드라이버의 디스패치 루틴에 전달된다. 따라서 드라이버로 전달된 IRP 자료구조의 내용을 살펴봄으로써 구체적인 통신의 내용을 모니터링할 수 있다. IRP 구조체의 형태 및 멤버 변수의 의미는 윈도우 드라이버 킷(WDK)의 매뉴얼에 설명되어 있다.

또한, API 후킹을 이용하여 통신 요청 모니터링부(111)를 구현하는 것도 가능하다. API 후킹이란 운영체제가 제공하는 API를 개발자가 만든 임의의 함수로 바꿔치기 하여 응용 프로그램이 운영체제가 제공하는 API를 호출할 때 운영체제의 API를 실제로 호출하기 이전에 관련 내용을 모니터링 및 처리할 수 있는 방법을 말한다. API 후킹은 운영체제가 제공하는 API와 동일한 함수형을 가진 함수를 포함하는 DLL을 응용 프로그램의 프로세스 내에 매핑한 후, KERNEL32.DLL, USER32.DLL, GDI32.DLL 등의 모듈에 포함된 함수를 호출할 때 사용되는 IAT(Import Address Table)의 함수 주소를 교체함으로써 가능하다. 또한, 커널 모드에서 시스템 서비스 디스패치 테이블(SSDT) 내의 함수 주소를 교체하는 방법으로 API 후킹을 구현하는 것도 가능하다.

API 후킹을 이용하여 통신 요청 모니터링부(111)를 구현하는 경우에는 윈도우 API나 네이티브 시스템 서비스(Native System Service)의 함수를 호출할 때 사용되는 파라미터를 그대로 수신하는 것이 가능하므로, 이 함수들의 파라미터를 조사하여 응용 프로그램이 호출한 함수의 세부 내용을 모니터링할 수 있다.

쓰레드 판독부(112)는 상기 통신 요청 모니터링부(111)에서 수신한 통신 요청의 발신 쓰레드를 판독한다. 통신 요청의 발신 쓰레드를 판독하는 목적은, 하기의 스택 역추적을 통한 모듈 검사부(113)에서 해당 통신 요청과 관련된 모듈들만 선별적으로 악성 모듈 검사를 하기 위함이다. 판독 결과는 쓰레드 ID로 표현되는 것이 바람직하다.

상기 통신 요청 모니터링부(111)가 커널 모드의 드라이버로 구현되어 있는 경우, 해당 IRP의 발신 쓰레드를 판독하는 방법은 IRP 구조체 내의 Tail.Overlay.Thread(ETHREAD 구조체형) 필드를 직접 조사하거나, NT 커널 5.1 이상부터는 PsGetThreadID() 함수에 Tail.Overlay.Thread 값을 인자로 주어 구할 수 있다. 혹은, 상기 통신 요청 모니터링부(111)를 구현하는 커널 모드의 드라이버를 전송 계층 드라이버의 상단에서 작동되는 필터 드라이버로 구현한 경우에는, 이 드라이버의 디스패치 루틴의 호출이 네트워크 통신을 요청한 사용자 모드의 쓰레드와 같은 컨텍스트에서 실행되기 때문에, PsGetCurrentThreadId()를 호출하여 판독하는 것도 가능하다.

상기 통신 요청 모니터링부(111)가 API 후킹을 이용하여 구현되어 있는 경우, API 후킹 함수는 API를 호출한 쓰레드와 같은 쓰레드 컨텍스트에서 실행되므 로, GetCurrentThreadId() API를 호출함으로써 네트워크 통신 요청을 한 쓰레드를 판독할 수 있다.

스택 역추적을 통한 모듈 검사부(113)는 상기 쓰레드 판독부(112)에서 판독한 쓰레드의 스택 메모리를 역추적하는 방법을 이용하여 해당 통신 요청에 관여한 모듈만 선별적으로 악성 모듈 검사를 한다. 이 상세한 과정은 도 2를 참조하여 후술한다.

통신 요청 처리부(114)는 상기 스택 역추적을 통한 모듈 검사부(113)의 검사 결과에 따라 통신 요청을 허용하거나 차단한다.

상기 통신 요청 모니터링부(111)가 커널 모드의 드라이버로 구현되어 있을 때에는, 통신을 차단하기 위해서는 수신한 통신 요청 IRP를 하위 드라이버로 내려보내지 않고 IoCompleteRequest()를 이용하여 완료 처리를 하면 된다. 이때 완료 코드를 실패로 설정함으로써 응용 프로그램에게 통신이 실패한 것으로 반환한다. 반면, 통신을 허용하려면 상기 IRP를 하위 드라이버로 IoCallDriver()를 호출하여 넘겨주면 된다.

상기 통신 요청 모니터링부(111)가 API 후킹을 이용하여 구현되었을 때에는, 통신을 차단하려면 후킹한 API 함수 내에서 원본 함수를 호출하지 않고 바로 실패를 반환하면 된다. 반면, 통신을 허용하려면 후킹한 API 함수가 받은 파라미터를 그대로 원본 API 함수로 넘겨주면 된다.

통신이 허용되면 해당 통신 요청은 네트워크 인터페이스 카드(130)을 통하여 인터넷(140)과 패킷을 송수신할 수 있게 된다.

도 2는 상기 스택 역추적을 통한 모듈 검사부(113)를 더 자세히 알아보기 위한 블록도이다.

쓰레드 컨텍스트 추출부(201)는 상기 쓰레드 판독부(112)에서 판독된 쓰레드를 대상으로 해당 쓰레드의 컨텍스트를 추출한다. 쓰레드 컨텍스트를 추출하는 이유는 쓰레드 컨텍스트 내에 존재하는 명령어 포인터 레지스터 값과 베이스 포인터 레지스터 값이 하기의 스택 역추적부(202)에서 필요하기 때문이다.

현대의 개인용 컴퓨터 및 서버 컴퓨터의 운영체제는 대부분 멀티 쓰레드 환경을 지원하며, 이러한 멀티 쓰레드 환경에서 하나의 프로세스는 하나 이상의 쓰레드를 포함하는 것이 가능하다. 또한, 시분할 방식의 운영체제 환경에서 다수의 쓰레드는 CPU의 시간(time slice)을 공평하게 나누어 씀으로써 멀티 쓰레드가 동시 병행적으로 실행되도록 한다. 따라서 다수의 쓰레드를 제한된 개수의 CPU에서 교체해가면서 실행하기 위해서는 각 쓰레드마다 CPU의 상태를 저장할 필요가 있으며, 윈도우 운영체제의 경우 커널 쓰레드 오브젝트 내에 CONTEXT라는 자료구조를 이용하여 이를 관리하고 있다. 이 CONTEXT 자료구조에는 CPU의 각종 레지스터의 값이 포함된다.

상기 쓰레드 판독부(112)에서 추출한 쓰레드의 ID를 이용하여 상기 쓰레드의 컨텍스트를 구하기 위해서는 먼저 OpenThread() API에 쓰레드 ID를 인자로 전달하여 쓰레드 핸들을 구한 후, GetThreadContext() API에 쓰레드 핸들과 초기화된 CONTEXT 구조체의 주소를 전달한다. 이때 쓰레드가 블록되어 있는 상태가 아니라면 GetThreadContext() API 실행 중 CPU의 상태가 변화하는 것을 막기 위해 GetThreadContext() API를 호출하기 이전에 SuspendThread() API를 이용하여 쓰레드를 정지 상태로 만드는 것이 바람직하다.

스택 역추적부(202)는 상기 쓰레드 판독부(112)에서 판독된 쓰레드의 스택 메모리를 역추적하여 스택 프레임 내에 저장된 하나 이상의 명령어 포인터를 추출한다. 이 상세한 과정은 예시를 통하여 후술한다.

모듈 추출부(203)는 상기 스택 역추적부(202)에서 추출한 명령어 포인터의 주소에 해당하는 모듈을 추출한다. 먼저 EnumProcessModules() API로 상기 쓰레드 판독부(112)에서 판독된 쓰레드를 포함하는 프로세스 내에 로딩되어 있는 모든 모듈을 순회하면서, 각 모듈마다 GetModuleInformation() API를 이용하여 모듈의 베이스 주소(base address)와 모듈의 크기를 구한 뒤, 상기 모듈의 주소 범위 내에 상기 스택 역추적부(202)에서 추출한 명령어 포인터의 주소가 포함되는가를 비교하여 상기 명령어 포인터의 주소에 해당하는 모듈의 핸들을 구한다. 그리고 상기 모듈의 핸들을 파라미터로 GetModuleFileNameEx() API를 호출하여 이 모듈의 디스크상의 경로를 구한다.

악성 모듈 검사부(205)는 상기 모듈 추출부(203)에서 추출한 모듈을 대상으로 악성 모듈 검사를 한다. 악성 모듈 검사부(205)는 모듈 DB(206)를 이용하여 악성 모듈 검사를 하는 것이 바람직하다. 모듈 DB(206)는 모듈(EXE, DLL 등)들에 대한 정보를 저장하고 있는 데이터베이스로, 각 모듈의 고유한 코드값과 이 모듈의 악성 여부 등을 저장하고 있다. 바람직하게는 각 모듈을 구분하는 고유한 코드값은, 모듈의 일부 혹은 전부에 일방향 해쉬 함수를 적용하여 산출된 해쉬값을 이용 하거나, 모듈의 고유한 시그니쳐를 추출하여 저장하는 방식을 이용한다. 모듈 DB(206)의 모듈 데이터는 사용자에 의해 추가될 수도 있고, 중앙 서버를 이용하여 실시간으로 업데이트될 수도 있다. 악성 모듈을 검사하는 다양한 실시예는 당업자에게 널리 알려진 기술이므로 그 상세한 설명은 생략한다.

또는, 상기 모듈 추출부(203)에서 디스크상의 모듈 경로를 구하지 않고 직접 메모리상에서 모듈이 위치한 주소 범위를 모듈의 베이스 주소와 크기를 이용하여 구한 뒤, 상기 메모리상의 모듈을 직접 악성 모듈 검사부(205)를 이용하여 검사할 수도 있다. 이러한 방식의 장점은 모듈이 메모리상에 로딩된 후에 바이러스 등에 의하여 변조된 경우에도 악성 모듈 탐지가 가능하다는 것이다.

한편, 상기 모듈 추출부(203)에서 추출된 모든 모듈을 대상으로 악성 모듈 검사를 하는 것이 경우에 따라 비효율적일 수 있기 때문에, 추가적인 모듈 필터링부(204)를 이용하여 상기 추출된 모듈을 대상으로 악성 모듈 검사를 할 것인지를 판단할 수 있다. 예를 들어 상기 스택 역추적부(202)를 통해 추출된 모듈의 목록 중 같은 모듈이 여러 번 존재할 수도 있는데, 이러한 경우 같은 모듈에 대해 중복된 검사를 할 필요는 없기 때문에 모듈 필터링부(204)를 이용하여 불필요한 검사는 생략하는 것이 바람직하다. 또는 상기 모듈 추출부(203)에서 추출된 모듈이 여러 정황상 악성 모듈이 아님을 확신할 수 있는 모듈인 경우에도 악성 모듈 검사를 생략함으로써 불필요한 부하를 감소시킬 수 있다.

이하 도면 5부터 도면 8을 참조하여, 상기 스택 역추적부(202)의 상세한 내용을 예시를 통하여 설명한다.

도 5는 응용 프로그램(120)의 프로세스 내부 구조(500)를 예시한 블록도이다. 예시된 프로세스 블록도에서는 2개의 쓰레드(507, 508)가 있다. 쓰레드 1(507)은 프로세스를 대표하는 EXE 실행 모듈(501)로부터 시작된 쓰레드로, 정상 모듈(502), WS2_32.DLL(504), NTDLL.DLL(505)를 차례로 경유하여 커널 모드로 네트워크 통신 요청을 하고 있다. 쓰레드 2(508)은 정상적인 프로세스 내로 침투한 악성 모듈(503)로부터 시작된 쓰레드로, WS2_32.DLL(504), NTDLL.DLL(505)를 차례로 경유하여 커널 모드로 네트워크 통신 요청을 하고 있다. WS2_32.DLL은 윈속(WinSock; Windows Socket)을 구현하는 DLL 모듈이며, NTDLL.DLL은 커널이 제공하는 네이티브 시스템 서비스로의 진입점(entry point)을 제공하는 DLL 모듈이다. 본 도면에서는 KERNEL32.DLL, USER32.DLL, GDI32.DLL과 같은 프로그램 실행에 필요한 기타 DLL 모듈은 별도로 도시하지 않았으나, 이것은 예시 목적을 위해 간략화한 것이다.

도 6은 도 5에서 예시한 프로세스의 가상 메모리 주소 공간을 나타낸 블록도이다.

하나의 프로세스가 생성되면 운영체제는 각 프로세스에게 독립적인 주소 공간을 할당하며, 이 주소 공간은 커널 주소 영역과 사용자 주소 영역으로 구분된다. 프로세스의 실행에 관여하는 모든 모듈(EXE, DLL 등)은 이 주소 공간 내에 매핑이 된다. 도 6에서는 NTDLL.DLL(601), WS2_32.DLL(602), 악성 모듈(605), 정상 모듈(606), 실행 모듈(607)이 주소 공간에 적절히 매핑되어 있다.

또한, 하나의 쓰레드가 생성될 때마다 운영체제는 각 쓰레드에게 독립적인 스택 메모리 공간을 할당해준다. 도 5에서 예시한 것과 같이 한 프로세스 내에 2개 의 쓰레드(507, 508)가 있는 경우, 프로세스 주소 공간 내에 2개의 스택 메모리 영역(603, 604)이 각각 생성되게 된다. 쓰레드 1(507)을 위해서는 0x00800000부터 0x00900000까지의 스택 메모리(603)가 할당되어 있으며, 쓰레드 2(508)를 위해서는 0x00700000부터 0x00800000까지의 스택 메모리(604)가 할당되어 있다.

도 7은 쓰레드 2(508)에 할당된 스택 메모리(604)를 상세히 예시하는 블록도이다.

스택 메모리는 CALL 명령(instruction)을 통해 함수(서브루틴)가 호출될 때마다 새로운 스택 프레임이 생성된다. 각 스택 프레임에는 호출되는 함수로 넘겨주는 파라미터, CALL 명령을 실행하는 시점에서의 명령어 포인터 레지스터 값, 이전 스택 프레임의 베이스 포인터 레지스터 값이 저장된 메모리 주소, 함수에서 사용하는 지역 변수가 차례로 스택에 푸쉬(push)된다. 도 7에서는 각 스택 프레임 내의 파라미터와 지역 변수가 각각 4 바이트를 차지하는 것으로 도시하였으나, 이것은 예시 목적을 위한 것이며 실제로 이 크기는 호출되는 함수에 따라 가변적이다.

운영체제는 새로 생성되는 쓰레드에게 독립적인 스택 메모리를 할당해 줄때, 스택의 바닥을 NULL 값으로 설정하여, 스택의 언더플로우(underflow)를 방지할 수 있도록 해준다. 도 7의 스택 바닥(710)의 0x007FFFFC(711)는 원래 함수가 호출될 때의 명령어 포인터 레지스터의 값이 저장되는 위치이지만, 이 곳은 스택의 바닥이기 때문에 운영체제가 NULL로 값을 세팅해주었다. 또한 0x007FFFF8(712) 위치는 원래 이전 스택 프레임의 베이스 포인터 레지스터의 값이 저장된 메모리 주소가 저장되는 곳이지만 스택의 바닥에서는 이전 스택 프레임이 존재하지 않기 때문에, 운영 체제는 이 곳에도 NULL로 값을 세팅해준다.

도 7의 스택이 처음 생성되었을 때에는 스택 바닥(710)만 존재하는 상태였다가, 악성 모듈(503)이 실행되는 도중 WS2_32.DLL(504)로의 함수 호출이 발생되면 스택 프레임 1(720)이 생성된다. 스택 프레임 1(720)의 0x007FFFF0 번지(722)에는 WS2_32.DLL로의 함수 호출을 하기 직전의 명령어 포인터 레지스터의 값이 저장되어 있으며, 이 값은 0x00600100로 악성 모듈(503)의 주소 범위(605) 내에 포함된다는 것을 알 수 있다. 또한, 0x007FFFEC 번지(723)에는 이전 스택 프레임에서 베이스 포인터 레지스터의 값이 저장되어 있는 메모리 번지가 저장되어 있으며, 이 값은 0x007FFFF8로 스택의 바닥을 가리키고 있음을 알 수 있다.

한편, 쓰레드 2(508)가 WS2_32.DLL(504) 내의 코드를 실행하는 도중, 다시 NTDLL.DLL(505)으로의 함수 호출이 발생되면, 스택 프레임 2(730)이 생성된다. 스택 프레임 2(730)의 0x007FFFE0 번지(732)에는 NTDLL.DLL로의 함수 호출이 발생되기 직전의 명령어 포인터 레지스터의 값이 저장되어 있으며, 이 값은 0x71C00100으로 WS2_32.DLL(504)의 주소 범위(602) 내에 있다는 것을 알 수 있다. 또한, 0x007FFFDC 번지(733)에는 이전 스택 프레임에서 베이스 포인터 레지스터의 값이 저장되어 있는 메모리 번지 값이 저장되어 있으며, 이 값은 0x007FFFEC로 이전 스택 프레임인 스택 프레임 1(720)의 베이스 포인터 레지스터의 값이 저장되어 있는 메모리 주소(723)를 가리키고 있음을 알 수 있다.

도 8은 상기 쓰레드 2(508)가 커널로 통신 요청을 하였을 때의 커널 쓰레드 오브젝트를 예시한 블록도이다.

도 8을 참조하면, CONTEXT 자료구조(810) 내의 EIP(811)는 현재 명령어 포인터 레지스터의 값으로 바로 다음에 실행할 명령어의 주소를 저장하고 있으며, EBP(812)는 스택 탑(top)에 위치한 스택 프레임 내에서 이전 스택 프레임의 베이스 포인터 레지스터 값을 저장하고 있는 메모리 번지 값을 저장하고 있다.

도 8의 예에서 보면 EIP 값은 0x7D600100이고, 이 주소는 NTDLL.DLL(505)의 주소 범위(601)내에 해당한다. 즉, 쓰레드의 컨텍스트에서 구한 EIP 값을 이용하여 이 쓰레드는 현재 NTDLL.DLL 모듈 내의 코드를 실행하고 있음을 알 수 있다. 또한, 도 8의 예에서 보면 EBP 값은 0x007FFFDC이며, 이 값은 현재 스택 탑에 위치한 스택 프레임 2(730) 내에 이전 EBP 값을 저장한 메모리 번지(733)를 가리키고 있음을 알 수 있다.

이상과 같은 내용을 바탕으로 스택 역추적부(202)가 쓰레드 판독부(112)에서 판독한 쓰레드를 대상으로 스택을 역추적하면서 통신 요청에 관여한 모듈을 역추적하는 과정을 예시를 통해 설명한다. 하기의 예는 32비트 인텔 호환 CPU 기준이며, 이 CPU에서 명령어 포인터 레지스터는 EIP이며, 베이스 포인터 레지스터는 EBP이다.

먼저 도 8에 예시한 커널 쓰레드 오브젝트(800)의 CONTEXT 자료구조(810)을 쓰레드 컨텍스트 추출부(201)을 이용하여 추출한다.

다음, 상기 쓰레드 컨텍스트 내의 EIP(811) 값을 이용하여, 현지 실행중인 모듈을 모듈 추출부(203)를 이용하여 추출한다. 도 8의 예에서 EIP의 값이 0x7D600100이므로, 이 주소에 해당하는 해당하는 모듈은 NTDLL.DLL(601)임을 알 수 있다.

다음, 상기 CONTEXT 자료구조(810) 내의 EBP(812) 값을 이용하여 스택 탑에 위치한 스택 프레임 2(730)을 구한다. 상기 CONTEXT 자료구조(810) 내의 EBP(812)의 값이 0x007FFFDC이므로, 이 주소는 스택 프레임 2(730)내에서 이전 스택 프레임의 EBP 값이 저장된 메모리 주소(733)임을 알 수 있다. 스텍 프레임 2(730) 내의 EBP 위치로부터 상대적인 위치를 계산하면, 스택 프레임 2(730) 내의 EIP 값을 구할 수 있다. 스택 프레임 2(730)에서 EIP 값은 EBP 주소 + 4바이트의 위치에 존재하며, 그 주소는 0x007FFFE0(732)이다. 이 EIP 값를 이용하여, 스택 프레임 2(730)가 생성될 때 실행하고 있었던 주소가 0x71C00100임을 알 수 있으며, 모듈 추출부(203)을 이용하여 이 주소에 해당하는 모듈이 WS2_32.DLL(602)임을 알 수 있다.

다음, 스택 프레임 2(730)에서 구한 EBP 값(733)이 NULL이 아니므로 이전 스택 프레임이 존재함을 알 수 있으며, EBP 값을 주소로 하여 이전 스택 프레임을 구할 수 있다. 스택 프레임 2(730)에서 구한 EBP의 값이 0x007FFFEC이므로, 이 주소는 스택 프레임 1(720) 내에서 이전 스택 프레임의 EBP 값이 저장된 메모리 주소(723)임을 알 수 있다. 스택 프레임 1(720) 내의 EBP 위치로부터 상대적인 위치를 계산하면, 스택 프레임 1(720) 내의 EIP 값을 구할 수 있다. 스택 프레임 1(720)에서 EIP(722)의 값은 0x00600100이다. 이 EIP 값을 이용하여, 스택 프레임 1(720)이 생성될 때 실행하고 있었던 주소가 0x00600100임을 알 수 있으며, 모듈 추출부(203)를 이용하여 이 주소에 해당하는 모듈이 악성 모듈(605)임을 알 수 있다.

다음, 스택 프레임 1(720)에서 구한 EBP 값이 NULL이 아니므로 이전 스택 프 레임을 구한다. 스택 프레임 1(720)의 EBP(723) 값은 0x007FFFF8이며, 이 주소는 이전 스택 프레임 내에서 EBP 값이 저장되어 있는 주소를 가리킨다. 그러나 0x007FFFF8 주소의 값을 추출하여 보면 그 값이 NULL인 것을 알 수 있으며, 더 이상 처리할 스택 프레임은 존재하지 않는 것으로 판단할 수 있다.

이상과 같은 과정을 통해, 스택 역추적부(202)는 쓰레드 2(508)가 커널 모드로 통신 요청을 하기 위해 사용된 모듈이 NTDLL.DLL(505), WS2_32.DLL(504), 악성 모듈(503)임을 역으로 추적할 수가 있게 되는 것이다.

상기 스택 역추적부(202)가 특정 프로세스 내의 스택 메모리에 접근할 때에는 OpenProcess() API로 프로세스 핸들을 구한 후, ReadProcessMemory() API로 메모리 값을 읽는 것이 바람직하다.

이하, 본 발명의 바람직한 실시예에 따른 유해 트래픽 제어 및 해킹을 차단하는 방법에 관하여 설명한다.

도 3은 본 발명의 바람직한 실시예에 따라 유해 트래픽 제어 및 해킹을 차단하는 방법을 도시한 흐름도이다.

도 3을 참조하면, 응용 프로그램이 운영체제에게 요청한 통신 요청을 통신 요청 모니터링부(111)을 이용하여 모니터링하고 수신한다(S301).

상기 통신 요청 모니터링 단계에서 수신된 통신 요청의 발신 쓰레드를 쓰레드 판독부(112)를 이용하여 판독한다(S302).

상기 쓰레드 판독 단계에서 판독된 쓰레드의 스택 메모리를 스택 역추적을 통한 모듈 검사부(113)를 이용하여 상기 통신에 관여한 모듈만 선별적으로 악성 모 듈 여부를 검사한다(S303).

상기 악성 모듈 검사 결과 통신 요청에 관여한 모듈 중 악성 모듈이 포함되어 있다면(S304) 상기 통신 요청을 차단하고(S306), 악성 모듈이 포함되지 않았다면(S304) 상기 통신 요청을 허용(S305)한다.

도 4는 상기 스택 역추적을 통한 모듈 검사 단계(S303)를 설명하기 위한 흐름도이다.

도 4를 참조하면, 쓰레드 컨텍스트 추출부(201)을 이용하여 상기 쓰레드 판독 단계(S302)에서 판독한 쓰레드의 컨텍스트를 추출하고, 쓰레드 컨텍스트 내의 베이스 포인터 레지스터 값을 BP 변수에, 명령어 포인터 레지스터 값을 IP 변수에 저장한다(S401).

다음, 상기 IP 변수에 저장되어 있는 주소를 기초로 모듈 추출부(203)를 이용하여 상기 IP 변수에 해당하는 모듈을 추출한다(S402).

상기 추출된 모듈을 대상으로 악성 모듈 검사를 할 필요가 있는가를 판단하여(S403), 검사가 필요하다면 악성 모듈 검사를 한다(S404).

상기 악성 모듈 검사 결과 악성 모듈로 판단되면(S405) 악성 모듈이 발견되었음을 반환하고(S406), 악성 모듈이 아닌 것으로 판단되면(S405) 이전 스택 프레임을 추출하여 스택 프레임 내의 베이스 포인터 레지스터 값을 BP 변수에, 명령어 포인터 레지스터 값을 IP 변수에 저장한다(S407).

상기 스택 프레임 추출 단계(S407)에서 이전 스택 프레임을 추출한 결과 더 이상 조사할 스택 프레임이 없다고 판단되면(S408) 악성 모듈이 발견되지 않았음을 반환하고(S409), 더 조사할 스택 프레임이 있다고 판단되면(S408) 상기 IP 주소의 모듈 추출 단계(S402)로 되돌아가 반복 처리를 한다.

상기 IP 주소의 모듈 추출 단계(S402)에서 추출된 모듈을 대상으로 악성 모듈 검사를 할 것인가를 판단하는 단계(S403)는 생략될 수도 있다. 이 경우 IP 주소의 모듈 추출 단계(S402)에서 추출되는 모든 모듈을 대상으로 악성 모듈 검사를 한다.

이상과 같이 본 발명의 일실시예를 32비트 x86 호환 프로세서 상에서 구동되는 32비트 윈도우 운영체제환경 하에서 설명하였다. 그러나, 본 발명은 이와 같은 특정 플랫폼, 특정 운영체제 환경, 특정한 API의 사용, 특정한 변수 이름의 사용 등에 의해 한정되지 아니하며, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 본 발명의 기술 사상과 아래에 기재된 특허 청구범위의 균등 범위 내에서 다양한 수정 및 변형이 가능함은 당연한 사실이다.

도 1은 본 발명의 바람직한 실시예에 따른 유해 트래픽 제어 및 해킹을 차단하는 장치의 블록도이며,

도 2는 상기 도 1의 스택 역추적을 통한 모듈 검사부의 블록도이며,

도 3은 본 발명의 바람직한 실시예에 따른 유해 트래픽 제어 및 해킹을 차단하는 방법의 흐름도이며,

도 4은 상기 도 3의 스택 역추적을 통한 모듈 검사 단계를 나타내는 흐름도이고,

도 5은 스택 역추적 과정을 설명하기 위한 응용 프로그램의 모듈간 호출 과정을 예시한 블록도이며,

도 6은 실행중인 응용 프로그램에게 할당된 주소 공간(address space)의 레이아웃을 예시한 블록도이며,

도 7은 프로세스 내에서 실행중인 특정 쓰레드의 스택 공간을 구체적으로 예시한 블록도이며,

도 8은 특정 쓰레드를 관리하기 위해 사용되는 커널 쓰레드 오브젝트를 예시한 블록도이다.

< 도면의 주요 참조부호에 대한 설명 >

110: 유해 트래픽 제어 및 해킹을 차단하는 장치

S403: 모듈 필터링 단계

S408: 마지막 스택 프레임 판단 단계

500: 응용 프로그램의 프로세스

800: 커널 쓰레드 오브젝트

810: 커널 쓰레드 오브젝트 내의 CONTEXT 자료구조

Claims (12)

1. 삭제
2. 삭제
3. 컴퓨터 시스템에서 유해 트래픽 제어 및 해킹을 차단하는 장치에 있어서,

   응용 프로그램이 운영체제로 요청한 통신 요청을 모니터링하는 통신 요청 모니터링부와;

   상기 통신 요청 모니터링부에서 수신한 통신 요청의 발신 쓰레드를 판독하는 쓰레드 판독부와;

   상기 쓰레드 판독부에서 판독된 쓰레드의 스택 메모리를 역추적하여 상기 통신 요청과 관련된 모듈을 선별적으로 검사하는 스택 역추적을 통한 모듈 검사부와;

   상기 스택 역추적을 통한 모듈 검사부의 검사 결과에 따라 통신 요청을 허용하거나 차단하는 통신 요청 처리부;를 포함하고,

   상기 스택 역추적을 통한 모듈 검사부는,

   상기 쓰레드 판독부에서 판독된 쓰레드의 컨텍스트를 추출하는 쓰레드 컨텍스트 추출부와;

   상기 쓰레드 판독부에서 판독된 쓰레드의 스택 메모리를 상기 쓰레드 컨텍스트 추출부에서 추출된 베이스 포인터 레지스터의 값을 이용하여 역추적하는 스택 역추적부와;

   상기 쓰레드 컨텍스트 추출부와 상기 스택 역추적부에서 추출한 명령어 포인터의 주소에 해당하는 모듈을 추출하는 모듈 추출부와;

   상기 모듈 추출부에서 추출된 모듈을 대상으로 악성 모듈 검사를 할 것인지를 판단하여, 악성 모듈 검사를 할 필요가 있다고 판단되면 악성 모듈 검사부를 이용하여 악성 모듈 검사를 하고, 악성 모듈 검사를 할 필요가 없다고 판단되면 악성 모듈 검사를 생략하도록 하는 모듈 필터링부와;

   상기 모듈 필터링부에서 악성 모듈 검사를 할 필요가 있다고 판단된 모듈을 대상으로 악성 모듈 검사를 수행하는 악성 모듈 검사부;를 포함하는 것을 특징으로 하는 유해 트래픽 제어 및 해킹을 차단하는 장치.
4. 제 3항에 있어서,

   상기 통신 요청 모니터링부는 커널 모드의 드라이버로 만들어지는 것을 특징으로 하는 유해 트래픽 제어 및 해킹을 차단하는 장치.
5. 제 4항에 있어서,

   상기 통신 요청 모니터링부가 모니터링하는 통신 요청은 IRP(I/O Request Packet)의 형태를 가지는 것을 특징으로 하는 유해 트래픽 제어 및 해킹을 차단하는 장치.
6. 제 3항에 있어서,

   상기 통신 요청 모니터링부는 API 후킹을 이용하는 것을 특징으로 하는 유해 트래픽 제어 및 해킹을 차단하는 장치.
7. 삭제
8. 삭제
9. 컴퓨터 시스템에서 유해 트래픽 제어 및 해킹을 차단하는 방법에 있어서,

   응용 프로그램이 운영체제로 요청한 통신 요청을 모니터링하는 통신 요청 모니터링 단계;

   상기 통신 요청 모니터링 단계에서 수신된 통신 요청에서 통신 요청의 발신 쓰레드를 판독하는 쓰레드 판독 단계;

   상기 쓰레드 판독 단계에서 판독된 쓰레드의 스택 메모리를 역추적하여 악성 모듈을 검사하는 스택 역추적을 통한 모듈 검사 단계;

   상기 스택 역추적을 통한 모듈 검사 단계의 검사 결과에 따라 통신 요청을 허용하거나 차단하는 통신 요청 처리 단계;를 포함하고,

   상기 스택 역추적을 통한 모듈 검사 단계는,

   상기 쓰레드 판독 단계에서 판독된 쓰레드의 컨텍스트를 추출하여, 쓰레드 컨텍스트 내의 베이스 포인터를 BP 변수에, 명령어 포인터를 IP 변수에 대입하는 쓰레드 컨텍스트 추출 단계;

   상기 IP 변수의 값이 가리키는 주소에 로딩되어 있는 모듈을 추출하는 IP 주소의 모듈 추출 단계;

   상기 IP 주소의 모듈 추출 단계에서 추출된 모듈을 대상으로 악성 모듈 검사를 할 것인지를 판단하여, 악성 모듈 검사를 할 필요가 있다고 판단되면 하기의 악성 모듈 검사 단계로 진행하고, 악성 모듈 검사를 할 필요가 없다고 판단되면 하기의 악성 모듈 검사 단계를 생략하고 하기의 스택 프레임 추출 단계로 진행하는 모듈 필터링 단계;

   상기 모듈 필터링 단계의 판단 결과 악성 모듈 검사를 할 필요가 있다고 판단된 모듈을 대상으로 악성 모듈 검사를 하여 악성 모듈이라면 상기 모듈을 악성 모듈로 판단하는 악성 모듈 검사 단계;

   상기 모듈 필터링 단계에서 악성 모듈 검사를 할 필요가 없다고 판단되었거나 상기 악성 모듈 검사 단계에서 악성 모듈이 아닌 것으로 판단되면, 상기 쓰레드의 스택 메모리에서 스택 프레임을 추출하여, 스택 프레임 내의 베이스 포인터를 BP 변수에, 명령어 포인터를 IP 변수에 저장하는 스택 프레임 추출 단계;

   상기 스택 프레임 추출 단계의 실행 결과, 더 이상 조사할 스택 프레임이 없다면 악성 모듈이 발견되지 않은 것으로 판단하고, 더 조사할 스택 프레임이 있다면 상기 IP 주소의 모듈 추출 단계로 되돌아가 처리를 계속하는 마지막 스택 프레임 판단 단계;를 포함하는 것을 특징으로 하는 유해 트래픽 제어 및 해킹을 차단하는 방법.
10. 제 9항에 있어서,

    통신 요청 모니터링 단계에서 통신 요청의 수신은 커널 모드 드라이버로 수행되는 것을 특징으로 하는 유해 트래픽 제어 및 해킹을 차단하는 방법.
11. 제 10항에 있어서,

    상기 커널 모드 드라이버에서 수신되는 통신 요청은 IRP(I/O Request Packet)의 형태로 된 것을 특징으로 하는 유해 트래픽 제어 및 해킹을 차단하는 방법.
12. 제 9항에 있어서,

    통신 요청 모니터링 단계에서 통신 요청의 수신은 API 후킹을 이용하는 것을 특징으로 하는 유해 트래픽 제어 및 해킹을 차단하는 방법.

Images