Practical Malware Analysis

(#14 Network_Signature)

01. 개요

1. 교재 Practical Malware Analysis 14장의 악성코드 기반 네트워크 시그니처에 대하여 학습한다.

2. 악성코드의 네트워크 대책에 대하여 학습한다.

3. 스노트를 활용한 악성코드 기반 네트워크 시그니처를 생성하고 실습한다.

02. 본론

1. 악성코드 기반 네트워크 시그니처

• 효과적인 네트워크 대책을 개발하는 방법을 알아본다.

  대책은 위협에 대응하거나 악의적인 행위를 탐지하고 예방하기 위해 취해지는 행위이다.

  효과적인 대책을 마련하려면 악성코드가 네트워크를 사용하는 방법과 활용하는 방법을 반드시 이해해야 한다.

   

  1-1. 네트워크 대책

• 네트워크 활동(IP주소, TCP/UDP포트, 도메인 이름, 트래픽 콘텐츠)의 기본 속성은 방어를 위한 네트워킹과

  보안 장비에서 사용한다. 방화벽과 라우터는 IP주소와 포트를 이용해 네트워크에 대한 접근을 제한하는데

  사용할 수 있다. DNS 서버는 알려진 악의적인 도메인을 싱크홀(Sinkhole)로 알려진 내부 호스트로 경로 변환을

  하게 설정할 수 있다.

  침입탐지 시스템(IDS), 침입방지 시스템(IPS), 그리고 이메일과 웹 프록시 같은 다른 보안 장비는 콘텐츠

  기반의 대책을 적용할 수 있다. 콘텐츠 기반 방어 시스템은 트래픽의 심층검사(Deeper inspection)가 가능하며,

  IDS에서 사용하는 네트워크 시그니처와 스팸을 탐지하기 위해 메일 프록시에서 사용하는 알고리즘을 포함한다.

  IP주소와 도메인 이름 같은 기본 네트워크 표시자 들은 대부분의 방어 시스템에서 지원되므로, 악성코드

  분석가가 주시하는 첫 번째 아이템이 된다.

• 실제 환경에서 악성코드 관찰

  샌드박스 환경에서 악성코드를 실행하거나 강제로 악성코드를 열어 디스어셈블된 코드 분석을 하는 것이 분석의 첫 번째 단계가 되는 것보다는 악성코드에 대해 사전에 갖고 있는 데이터를 먼저 리뷰하는 것이 바람직하다. 경우에 따라 분석가는 악성코드 샘플이나 의심스러운 실행 파일을 어떠한 정보도 없이 받기도 하지만, 대부분의 경우 추가적인 데이터를 받는다. 네트워크 중점을 둔 악성코드 분석을 시작하는 가장 좋은 방법은 악성코드가 이미 생성한 로그, 경고, 캡처된 패킷 등을 탐색하는 것이다.

+ 샌드박스 환경이 아닌 실제 네트워크에서 생성된 정보는 다음과 같은 주요 이점을 가진다.

• 라이브 환경에서 캡처된 정보는 악의적인 애플리케이션의 실제 행위에 대한 가장 정확한 모습을 제공한다.

  악성코드는 샌드박스 환경을 탐지하게 프로그래밍될 수 있다.

• 활성화된 악성코드에 존재하는 정보는 분석을 가속화하는 훌륭한 통찰력을 제공할 수 있다.

  실제 트래픽은 엔드 포인트 양측(클라이언트와 서버)에 존재하는 악성코드 관련 정보를 제공하는데 반해,

  샌드박스 환경에서 일반적으로 분석가는 엔드 포인트 중 하나에서 존재하는 정보에만 접근 할 수 있다.

  악성코드로부터 전달받은 콘텐츠 분석(파싱 루틴)은 일반적으로 악성코드가 생성하는 콘텐츠의 분석보다 더 어렵다. 그러므로 양방향 샘플 트래픽은 분석가가 착수한 악성코드의 파싱 루틴 분석에 성과를 맺을 수

  있도록 도움을 준다.

• 또한 소극적으로 정보를 리뷰했을 때 공격자에게 분석 활동이 노출될 수 있는 위험이 없다.

  해당 이슈는 아래에서 설명하는 'OPSEC = 작전 보안' 절에서 상세히 설명한다.

   

• 악의적인 행위의 표시자

  분석할 악성코드 실행 파일을 전달받아 샌드박스 환경에서 실행한 후 네트워크 이벤트를 주목하고 있다고 가정하자. 악성코드가 'www.badsite.com' 에 대한 DNS 요청을 한 후 DNS 레코드에 있는 반환된 IP 주소의

  80 포트로 HTTP GET 요청을 한다는 사실을 발견했다. 30초 후에 DNS 질의 없이 외부에 있는 특정 IP 주소로

  신호 발신을 시도한다. 이 시점에서 악의적인 행위의 세가지 잠재적 표시자(indicator)를 가진다.

<표 1-1 악의적인 행위의 샘플 네트워크 표시자>

이 표시자에 대한 추가적은 연구 할 수 있다. 인터넷 검색을 통해 악성코드가 생성된 지 어느 정도 시간이 흘렀

으며, 언제 첫 번째로 발견됐는지, 어떻게 유포됐는지, 누가 작성했는지, 공격자의 목적이 무엇인지를 찾을 수도

있다. 표적 공격의 존재성이나 새로운 작전을 의미할 수 있기 때문에 정보 부족 또한 이 점에선 유익할 수 있다.

하지만 좋아하는 검색 엔진을 무작정 사용하기 전에 온라인 연구활동과 관련된 잠재적 위험을 이해하는 것 이

중요하다.

• OPSEC = 작전보안

  인터넷을 이용한 악성코드 연구를 할 때 작전보안(OPSEC, Operations Security)의 개념을 이해하는 것이

  중요하다. OPSEC은 정부기관이나 군 에서 사용하는 단어로, 적이 민감 정보를 획득하지 못하는 하는 과정을

  의미한다. 악성코드를 조사하는 과정에서 일어나는 특정 행동은 악성코드 제작자에게 우리가 악성코드를 인지했음을 알려줄 수 있다. 예를 들어 이메일을 통해 회사 네트워크로 전달된 악성코드를 집에서 분석하고

  있는 중이라면 공격자는 DNS 요청이 회사의 IP 주소 영역의 바깥에 있는 IP 주소에서 이뤄졌음을 알 수 있다.

   

  + 다음과 같이 공격자가 조사 활동을 인지할 수 있는 잠재적 방법이 많이 있다.

  • 특정 개인에게 링크가 포함된 스피어 피싱 이메일을 보낸 후 예상했던 지역 외부의 IP 주소에서 해당 링크에 접속을 시도하는지 살펴본다.
  • 블로그 코멘트(인터넷 접근이 가능하고 자유롭게 수정이 가능한 사이트 등)에 인코딩된 링크를 생성하는 익스플로잇을 설계한다. (효과적으로 개별 정보를 생성하면서 공개적으로 전염 감사 추적이 가능함.)
  • 악성코드에 사용하지 않는 도메인을 삽입하고 도메인을 해석하는 시도를 지켜본다.

     

  1-2. 온라인에서 공격자를 안전하게 조사

  가장 안전한 방법은 공격자를 조사할 때 인터넷을 전혀 사용하지 않는 것이지만, 사실 이것은 비현실 적이다.

  인터넷 검색엔진에 있는 검색을 사용하는 경우라면 다음과 같인 두 가지 주의사항이 포함된다.

  • 도메인 쿼리 엔진에서 인지하지 못한 도메인 이름이 포함된다면 크롤러의 활동을 유할 할 수 있다.
  • 캐싱된 결과라고 하더라도 검색 엔진의 결과를 클릭하면 해당 사이트와 연관된 두 번째 링크나 이후 링크를 여전히 활성화할 수 있다.

     

• 인터넷을 사용한다면 공자의 잠재적인 감시망을 피하기 위해 우회적인 방법을 사용해야 한다.

  우회 방법은 다양하다. Tor, 오픈 프록시, 웹 기반 익명화와 같이 익명성 제공을 위해 설계된 서비스나

  메커니즘을 사용하는 것이다. 이런 종류의 서비스는 자신의 개인정보를 숨기는 데 도움을 줄 수 있지만,

  은닉을 시도하는 것을 드러내는 단서를 제공해 공격자의 의심을 자극할 수 있다.

  또 다른 방법은 연구를 위한 전용 가상 머신을 사용하는 것이다.

  + 다음과 같은 여러 방법을 통해 전용 머신의 정확한 위치를 숨길 수 있다.

  • 핸드폰(Cellular) 연결을 사용하는 방법
  • Secure Shell(SSH)이나 가상 사설 네트워크(VPN)을 이용해 원격 인프라에 연결을 터널링하는 방법
  • 아마존 일래스틱 컴퓨트 클라우드(Amazon EC2)같은 클라우드 서비스에서 실행되는 임시 머신 원격사용.

   

• IP 주소와 도메인 정보 얻기

  인터넷 환경을 구성하는 두 가지 기본 요소는 IP 주소와 도메인 네임이다.

  DNS는 'www.yahoo.com' 같은 도메인 네임을 IP주소로 변환한다. (역으로 IP주소를 도메인으로도 변환)

  당연히 악성코드 역시 일반적인 트래픽처럼 보이게 하고, 악의적인 활동을 호스팅할 때 유연성과 견고성을

  유지하기 위해 DNS를 사용한다. 도메인 네임이 등록되면, 도메인 네임서버, 관련 일자, 연락 정보 같이 등록자에 대한 등록 정보를 도메인 등록기관에 저장한다. 인터넷 주소는 대륙별 인터넷 등록기관(RIRs)이라고

  불리는 등록기관을 소유하고 있다. 등록기관은 IP 주소 블록, 블록의 조직 할당, 여러 유형의 연락처 정보를 저장한다. DNS 정보는 도메인 네임과 IP주소 사이의 매핑을 나타낸다. 게다가 블랙리스트(IP 주소 또한 도메인 네임에 적용 가능)와 지리적 정보(IP 주소에만 적용)를 포함한 메타 데이터를 사용할 수 있다.

   

   

  해당 정보는 다수의 무료 웹사이트가 존재하며 웹사이트를 통한 질의를 하면 다음과 같은 정보를 얻을 수 있다. 도메인 검색 사이트를 통한 질의는 다음과 같은 이점을 제공한다.

  • 다수의 후속 검색이 자동으로 이뤄진다.
  • 한 단계의 익명성을 제공한다.
  • IP주소에 대한 블랙리스트와 지역적 정보를 포함해 이력에 대한 정보나 다른 정보의 원천에 대한 질의에 기반을 둔 추가 정보를 신속하게 제공한다.

   

  다음 그림은 표적 공격에 사용된 백도어의 C&C 서버로 사용된 도메인 에 대한 두개의 whois 요청 예다.

  두개의 백도어 파일이 요청하는 C&C 서버의 도메인네임은 다르지만, 두 도메인의 등록(registration)에 나열된 이름은 동일하다.

  

  <그림 1-1 두 개의 다른 도메인에 대한 whois요청 결과의 예>

   

1-3. 콘텐츠 기반 네트워크 대책

IP 주소와 도메인 네임과 같은 기본 표시자(base indicator)는 특정 버전의 악성코드에 대한 방어를 하는 데 가치가 있을 수 있지만, 그 가치는 오래 지속되지 않을 수 있다. 공격자들이 다른 주소나 도메인으로 이동해 빠르게 변화하기 때문이다. 반연 콘텐츠를 기반으로 한 표시자는 좀 더 기본적인 특성을 이용해 악성코드를 식별하기 때문에 더 가치가 있으며, 일반적으로 오래 지속된다.

시그니처 기반 IDS는 가장 오래됐고 악의적인 활동을 탐지하기 위해 가장 일반적으로 배치되는 시스템이다.

IDS의 탐지는 악의적인 활동이 네트워크 트래픽에서 어떻게 보이는지에 대한 지식에 의존한다.

탐지에는 악의적인 트래픽을 정확히 탐지(ture positive)와, 악의적인 것처럼 보이지만 실제적으로는 정상적인 오탐(false positive), 악의적이지만 탐지하지 못하는 미탐(false negative)이 있다.

가장 이상적인 탐지는 정탐이 높고, 오탐과 미탐이 적을수록 좋지만, 일반적으로 시그니처

정책을 타이트하게 생성하여 정탐률 을 높이게 되면, 오탐은 적을 수 있으나 미탐이 높아지게 되고.

반대로 타이트하지 않은 방향으로 시그니처 생성하면 미탐이 낮아 지겠지만 오탐이 높아지게 된다.

이처럼 트레이드오프[trade off]가 존재하며, 최대한 두 개의 정책 목표의 밸런스를 맞추려 노력 해야 한다.

• 스노트를 이용한 침입 탐지 예

  가장 대중적인 IDS중 하나는 스노트(Snort)이다. 스노트는 룰이 적용되기 전에 반드시 참이어야 하는 일련의 요소들을 함께 연결한 시그니처나 룰을 생성하는 데 사용된다. 기본 룰 옵션은 콘텐츠를 식별하는 옵션(룰 옵션이라 불림)과, 콘텐츠와 연관이 없는 요소들을 식별하는 옵션(non payload 룰 옵션이라 불림)으로 나뉘어 있다. 넌 페이로드 룰 옵션의 예는 특정 플래그, TCP 또는 IP 헤더의 특정 값, 패킷 페이로드의 크기를 포함한다. 예를 들어 룰 옵션 flow:estableished,to_client는 서버에서 출발해 클라이언트로 향하는 TCP 세션의 한 부분이다. 다른 예는 dsize:200으로, 200바이트의 페이로드를 가진 패킷을 탐지한다.

   

• 특정 악성코드를 가정하여 기본적은 스노트 룰을 만들어 보면 다음과 같다.

  이 악성코드는 HTTP GET 요청을 만들 때 요청을 위해 사용되는 애플리케이션과 커뮤니케이션을 하기 위해 User-Agent 헤더 필드를 삽입한다. 일반적인 브라우저의 User-Agent는 문자열 Mozilla(역사적 규악에 의해)로 시작하고 Windows7에서 크롬을 사용할 경우 Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36 과 같이 표현된다. 이 User-Agent는 브라우저와 운영체제의 버전 정보를 제공한다.

  이 악성코드에서 사용한 User-Agent 는 Wefa7e로, 독특하며 악성코드가 생성하는 트래픽을 식별하는 데 유용하게 사용할 수 있다.

  alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"TROJAN Malicious User-Agent";

  content:"|0d 0a|User-Agent\: Wefa72"; classtype:trojan-activitry; sid:2000001; rev:1;)

   

  스노트 룰은 두 부분(룰 헤더와 룰 옵션)으로 구성된다.

  룰 헤더는 룰 액션(일반적으로 alert), 프로토콜, 출발지와 목적지의 IP 주소, 그리고 출발지와 목적지의 포트를 포함한다. 규약에 따라 스노트 룰은 환경별 최적화를 할 수 있는 변수를 사용한다.

  $HOME_NET과 $EXTERNAL_NET 변수는 내부와 외부늬 네트워크 IP 주소 범위를 지정하는 데 사용됐으며, $HTTP_PORTS는 HTTP 트래픽으로 해석돼야 하는 포트를 정의한다. 이번 경우 헤더에 있는 -> 가 단방향으로만 가는 트래픽에 적용되게 룰이 정의됐기 때문에 HTTP 포트를 목적지로 하는 아웃바운드 트래픽에 매치된다.

   

  룰 옵션 섹션은 룰의 발동 여부를 경정하는 요소를 포함한다. 점검 요소들은 일반적으로 순서대로 평가되고, 모든 요소가 참이어야 룰이 발동된다. 다음 표는 앞의 룰에 사용된 키워드를 설명한다.

<표 1-2 위 스노트 룰 키워드>

위 룰의 content 조건 내에서 파이프 심볼(|)은 16진수 표기의 시작과 같을 나타내기 위해 사용한다.

두 개의 파이프 심볼 사이에 포함돼 있는 내용은 원시(raw)값이 아닌 16진수(hex)값으로 해석된다. 따라서 |0d 0a|는 HTTP 헤더들 사이의 구분(개행 문자)을 나타낸다. 샘플 시그니처에서 content룰 옵션은 HTTP 헤더 필드 User-Agent: wefa7e와 일치한다. HTTP 헤더가 두개의 문자 0d와 0a로 구분돼 있기 때문이다.

위와 같이 원본 표시자와 시그니처를 갖게 되면 대개 샌드박스 같은 자동화 분석 기반과 함께 네트워크 기반의 표시자 분석은 이 시점에서 완료됐다고 간주한다. 방화벽에서 차단할 IP 주소와 프록시에서 차단할 도메인 네임, 그리고 IDS 로딩할 네트워크 시그니처를 알아냈지만, 여기서 분석을 멈추는 것은 실수이다.

• 더 자세한 스노트를 이용한 탐지 예

  악성코드 분석가는 신속한 조치와 정확성 사이의 균형을 잡기 위해 노력한다. 네트워크 기반 악성코드 분석의 경우 신속한 조치는 샌드박스에서 악성코드를 실행한 후 그 결과가 충분하다고 가정하는 것이다. 정확한 방법은 순차적으로 악성코드의 함수를 완벽하게 분석하는 것이다.

  예제 정책은 이머징 스릿(Emerging Threat) 프로젝트에서 스노트(Snort) 규칙을 작성해 등록한 실제 악성코드 콘텐츠 기반의 룰 이다. 시그니처 생성자는 실제 트래픽에서 User-Agnet에 대해 두개의 값(Wefa72와 Wee6a3)을 확인했다고 언급했다.

   

  alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS

  (msg:"ET TROJAN WindowsEnterpriseSuite FakeAV Dynamic User-Agent";

  flow: established,to_server; content:"|0d 0a|User-Agent\: We"; isdataat:6,relative; content: "|0d 0a|";

  distance:0; pcre:"/User-Agent\: We[a-z0-9]{4}\x0d\x0a/";

  classtype: trojan-activity; reference:url,www.threatexpert.com/report.aspx?md5=d9bcb4e4d650a5ed4402fab8f9ef1387; sid:2010262; rev:1;)

   

<표 1-3 위 스노트 룰 키워드>

룰이 다소 길긴 하지만, 룰의 핵심은 단순하게 We의 뒤를 잇는 네 자리의 영문자와 숫자 조합 문자(We[a-z0-9]{4}로 이뤄진 User-Agent 문자열이다.

스노트에서 사용한 펄 호환 정규 표현식(pcre) 표기범에서 다음과 같은 문자들이 사용됐다.

<그림 1-2 정규식 도형화: http://regexper.com/#We%5Ba-z0-9%5D%7B4%7D>

- 대괄호([ ])는 사용 가능한 문자들의 집합을 나타낸다.

- 중괄호 ({ })는 문자의 개수를 나타낸다.

- 바이트를 위한 16진수 표기법은 \xHH 형태로 나타낸다.

앞서 언급했듯이 룰 헤더는 IP주소, 포트, 프로토콜 같은 기본 정보를 제공한다.

스노트는 TCP 세션을 추적하기 때문에 TCP 협상(handshake)을 바탄으로 한 클라이언트나 서버 트래픽에 특정된 룰을 작성할 수 있다. 이번 룰에서 flow 키워드는 연결된 TCP 세션 중 클라이언트 측에서 생선된 트래픽에 대해서만 탐지되도록 한다. 어느 정도 사용된 후에 이룰은 대중적인 Webmin 소프트웨어의 사용으로 발생하는 오탐을 제거하기 위해 약간 수정되었다. 다음은 수정된 최신 룰이다.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS

(msg:"ET TROJAN WindowsEnterpriseSuite FakeAV Dynamic User-Agent";

flow: established,to_server; content:"|0d 0a|User-Agent\: We"; isdataat:6,relative; content: "|0d 0a|";

distance:0; content:!"User-Agent|3a| Webmin|0d 0a|";

pcre:"/User-Agent\: We[a-z0-9]{4}\x0d\x0a/"; classtype: trojan-activity;

reference:url,www.threatexpert.com/report.aspx?md5=d9bcb4e4d650a5ed4402fab8f9ef1387;

reference:url,doc.emergingthreats.net/2010262;

reference:url,www.emergingtheats.net/cgi-bin/cvsweb.cgi/sigs/VIRUS/TROJAN_WindowsEnterpriseFakeAV;

sid:2010262; rev:4;)

content 표현(content:!"User-Agent|3a| Webmin|0d 0a|")에서 사용된 느낌표(!)는 논리적으로 반대되는 선택(즉, not)을 나타낸다. 따라서 해당 룰은 표현된 content 가 나타나지 않는 경우에만 발동된다.

하지만, not content 사용시 해당 content가 유니크하지 않을 경우 IDS 장비에 무리를 줄 수 있다.

위 예제는 시그니처의 개발 프로세스의 일반적인 몇 가지 특성을 보여준다.

• 첫째, 시그니처 대부분은 트래픽을 생성한 악성코드에 대한 분석보다는 네트워크 트래픽 분석을 바탕으로 생성된다.
• 둘째, 오탐(false positive)이 발생하지 않게 시그니처에 특화된 패턴의 고유성을 테스트 한다.

실제 트래픽을 대상을 시그니처를 생성한 후 오탐이 발생하는지를 확인함으로써 테스트를 수행한다.

이번의 경우 원본 시그니처는 실제 트래픽을 대상으로 적용됏으며, User-Agent Webmin을 포함한 정상 트래픽에 대해 오탐을 발생하였다. 그 결과 시그니처는 정상 트래픽에 대해 예외 처리를 하게 재정의 됐다.

앞서 언급한 바와 같이 악성코드가 활동 중일 때 캡처된 트래픽은 연구실 환경에서 재현하기 어려운 상세한 정보를 제공한다. 다른 한편으로는 실제 환경에서 사용 가능한 샘플을 수가 작을 수 있다. 풍부한 샘플을 갖고 있음을 확인할 수 있는 한가지 방법은 악성코드에 대한 동적 분석을 반복하는 것이다. 샘플 악성코드를 여러 번 실행한 후 다음과 같은 User-Agent 문자열 목록이 생성 됐다고 가정하자.

위 결과와 같이 User-Agent에 특정 문자열을 확인한 결과, 악성코드가 생성하는 트래픽의 램덤 요소를 파악할

수 있었다. 위 리스트는 4개의 문자가 영문자와 숫자 집합이고, 문자들이 무작위로 분산돼 있음을 나타낸다.

하지만 기존 룰의 PCRE를 보면 User-Agnet\: We[a-z0-9]{4}\x0d\x0a/로 정의 했지만, 문자열의 랜덤요소는

a-z보다 a-f로 문자가 한정되어 있음을 알 수 있다. 따라서 이 문자의 랜덤요소의 바이너리 값이 16진수

표현법으로 직접적으로 변환될때 자주 사용한다고 판단할 수 있다. 이런 식으로 좀더 깊이 트래픽을 관찰하여

룰을 더 정교하고 정확하게 재 수립하는 것을 실무에서는 "룰 고도화" 또는 "정책 고도화" 라고도 한다.

• 추가적인 학습을 위해 악성코드를 여러 번 실행해 다음과 같은 User-Agent 문자열을 얻었다고 가정해 본다.

위 User-Agent 문자열이 나왔다고 가정하면, 기존 시그니처가 일부 결과를 잡을 수 있겠지만,

We에 더해 Wf와 W1을 생성하는 트래픽에 대해 분명히 이상적인 상태는 아니다. 또한 샘플을 통해 User-Agent가 일반적으로 6개의 문자로 구성되지만, 7개의 문자가 될 수 있음을 할 수 있다.

악성코드가 나열된 결과를 만들기 위해 정확히 어떤 작업을 하는지 모르기는 하지만, 이제 우리는 좀더 나은 추측을 할 수 있다. 악성코드는 시스템 정보를 외부 전송의 입력 값으로 이용할 수 있다는 사실을 기억하자.

최소한 두 개의 시스템에서 샘플 트래픽을 생성하는 것이 발신신호(beacon)의 어떤 부분이 고정되는지에 대해 잘못 가정하지 않게 도움을 준다. 고정되는 내용은 특정 시스템에 대해 고정적이지만, 호스트별로는 달라진다.

예를 들어 단일 시스템에서 악성코드를 여러 번 실행한 후 다음과 같은 결과를 얻었다고 가정해보자.

교차 점검을 할 수 있는 라이브 트래픽을 갖고 있지 않다는 가정하에 앞의 단일 User-Agent를 탐지하는 룰을 작성하는 실수를 할 수 있다. 하지만 악성코드를 실행한 다른 호스트에서는 다음과 같은 결과를 얻을 수 있었다.

시그니처를 제작할 때 대상 콘텐츠의 반화되는 요소를 파학해 그것이 실수로 시그니처에 포함되지 않게 하는 것이 중요하다.

시도를 할 때마다 달라지는 콘텐츠는 일반적으로 데이터의 근원이 무작위 속성을 갖고 있음을 나타낸다. 임의의 호스트에서는 고정적이나 다른 호스트에서 달라지는 콘텐츠는 해당 콘텐츠가 호스트의 속성으로부터 유래했음을 나타낸다. 운이 좋은 경우 호스트 속성에서 유래되는 콘텐츠가 네트워크 시그니처에 정의할수 있을 만큼 충분히 예측 가능할 수도 있다.

1-4. 동적 분석 기법과 정적 분석 기법의 조합

지금까지 시그니처 생성 방법을 알리기 위해 존재하는 데이터나 동적 분석의 결과를 사용했었다.

이런 방법은 편리하고 정보를 빠르게 생성할 수 있지만, 때때로 좀 더 정확하고 좀더 지속적인 시그니처 이끌어

낼 수 있는 악성코드의 깊은 특성을 파악하는 데 실패할 수도 있다.

+ 일반적으로 상세 분석(deeper analysis)은 다음과 같은 두 가지 목적을 가진다.

- 기능의 전체 범위(coverage)

첫 단계는 동적 분석을 이용해 코드의 이해 범위를 넓히는 것이다.

악성코드가 수신 받고자 하는 입력이 무엇인지를 파악하기 위해 일반적으로 새로운 입력을 제공함으로써 코드가 사용되지 않는 경로(path)를 계속적으로 실행하게 한다.

일반적으로 INetSim(http://lamalama.tistory.com/5) 이나 자체 제작한 스크립트 같은 도구를 이용해 이런 작업을 수행한다. 이 프로세스는 실제 악성코드 트래픽이나 정적 분석을 통해 도움을 받을 수 있다.

- 입력과 출력을 포함해 기능을 이해하기

정적 분석은 콘텐츠가 어디서, 그리고 어떻게 생성되는지를 알아보는 것은 물론 악성코드의 행위를 예상하고자 할 때도 사용된다. 그 후 동적 분석을 통해 정적 분석에서 예상한 기대 행위가 발생하는지를 확인할 수 있다.

• 탐지 우회

  탐지 우회는 백도어를 조작하는 사람들의 근본 목적 중 하나다. 탐지되면 시스템에 대한 접근 권한을 잃을 뿐 아니라 향후 감염시킨 모든 시스템에 대한 접근 세션이 차단될 우려가 있다. 악성코드는 여러 기법들을 이용해 눈에 띄지 않는 곳에 숨어드는 형태로 탐지를 우회하기 위해 진화를 계속하고 있다.

   

• 공격자는 기존의 프로토콜로 가장한다

  공격자가 눈에 띄지 않게 숨어드는 한 가지 방법은 가장 대중적은 통신 프로토콜을 사용하는 것으로, 공격자의 악의적인 행위가 정상적은 통신속에 묻혀버리기 때문이다.

  한때 인터넷 릴레이 챗(IRC)가 1990년대에 인기 있었을 때 공격자는 IRC 프로토콜을 매우 많이 사용했다.

  하지만 정상적인 IRC 트래픽이 줄어듦에 따라 방어자들은 IRC 트래픽을 주의 깊게 살펴보기 시작했고, 공격자들은 은닉이 쉽지 않자 오늘날 가장 많이 사용하는 HTTP, HTTPS, DNS로 프로토콜을 주로 사용하기 시작했다. 이렇게 대규모의 트래픽을 모니터링 하는 것이 매우 어렵기 때문에 이들 프로토콜은 자세하게 살펴보기 어렵다. 또한 다량의 정상 트래픽을 실수로 차단할 경우 발생하는 잠재적 위험성(가용성)으로 인해 함부로 차단하기 어려운 점을 악용한다.

   

  위처럼 근래 공격자는 정상적은 트래픽과 유사한 방법으로 대중적인 프로토콜을 사용해 숨어드는데, 공격자는 신호 발신을 위해 HTTP를 자주 사용한다. 신호(beacon)가 기본적으로 추가 명령을 위한 요청이며, 통신의 속성과 의도를 숨기기 위해 HTTPS 암호화를 사용한다. 또한 DNS는 정보의 빠르고 짧은 교환을 제공하는 의도지만, 정보를 인코디한 후 프로토콜의 원래 의도와는 다른 목적으로 DNS 필드에 삽입해 DNS를 통해

  긴 스트림의 정보를 숨기기도 한다. 공격자는 전달하고자 하는 데이터를 DNS 이름으로 만들 수 있다. 사용자의 패스워드 전달을 시도하는 악성코드는 도메인 'www.thepasswordisflapjack.maliciousdomain.com'에 대한 DNS 요청을 수행할 수 있다.

  공격자는 또한 HTTP 표준을 악용하여, 요청 메소드의 User-Agent 같은 필드에 호스트 정보를 삽입시켜 전송하거나 할 수도 있다. 이는 방어자가 요청된 URL만 검사할 경우나, 또는 HTTP 세션 본문에서 콘텐츠를 검색할 경우 의심스러운 트래픽을 발견하지 못하게 하기 위함이다.

  이처럼 악성코드 제작자들은 악성코드가 더욱 정상처럼 보이게 하기 위해 자신들의 기술을 발전시켜 왔다.

   

• 기존 인프라를 사용하는 공격자

  공격자는 악성코드를 숨기기 위해 기존의 정상적인 자원을 이용한다.

  서버의 유일한 목적이 악성코드 요청을 서비스하는 것이라면 정상적인 목적으로 사용되는 서버보다

  더 쉽게 탐지할 수 있다. 따라서 공격자는 정상적인 서버를 해킹하여 악성코드와 통신하기 위한 명령어를 삽입하는 경우가 있다. 다름은 공격자가 조작한 샘플 페이지의 첫 몇 라인이다.

  

  <그림 1-3 악성코드의 명령어가 삽입된 html 페이지 샘플>

   

  위 붉은 네모박스의 adsrv?bG9uZ3NsZWVw 구문은 악성코드가 체크를 다시 하기 전에 오랜 시간동안 대기(sleep)하도록 하는 삽입된 명령어다(bG9uZ3NsZWVw의 Base64 디코딩 값은 longsleep이다).

  악성코드는 이 명령어를 읽고 악성코드 프로세스를 잠재우기(sleep)위해 sleep명령어를 호출한다. 방어자의 입장에서 실제 웹 페이지를 위한 정상적인 요청과 동일한 요청이지만, 웹 페이지의 일부가 명령어로 해석되는 악성코드 사이의 차이점을 말하기가 극히 어렵다.

   

   

   

   

• 주변 코드의 이해의 필요성

  악성코드는 데이터 전송과 데이터 수신의 네트워크 활동이 있다. 외부로 전송되는 데이터의 분석은 일반적으로 쉽다. 악성코드가 실행될 때마다 분석에 필요한 샘플을 편리하게 생산하기 때문이다. 하지만 수신되는 데이터의 의미를 정확히 파악하려면 네트워크 발신을 생성하는 주변코드의 이해가 필요하다.

   

  예를 들기 위해 악성코드 샘플을 살펴본다.

  다음은 실제 네트워크 에서 악성코드 활동으로 가정된 부분을 트래픽 로그에서 발췌한 것이다.

  이 트래픽 로그에서 악성코드는 다음의 GET 요청을 만드는 것을 확인했다.

다음은 실제 네트워크가 아닌, 샌드박스에서 테스트한 결과이다.

인터넷 익스플로러를 이용해 웹 페이지를 브라우징한 결과,

실제 테스트 시스템의 표준 User-Agent가 다음과 같음을 확인했다.

위에서 주어진 User-Agent 문자열을 통해 이 악성코드의 User-Agent 문자열이 하드 코딩 됐음을 알 수 있다.

하지만 악성코드는 매우 일반적인 User-Agent 문자열을 사용하며, 이는 고정 User-Agent 문자열만으로

시그니처를 생성한 경우 다수의 오탐을 초래할 수 있음을 의미한다. 긍정적은 측면은 고정된 User-Agent 문자열이 효과적인 시그니처를 생성하는 데 다른 요소와 함께 결합할 수 있다는 점이다.

위에서 설명한 바와 같이 다음 단계로 악성코드를 좀 더 여러 번 실행시켜 악성코드에 대한 동적 분석을 실시한다. 이 과정에서 매번 달라지는 URI을 제외하고 GET 요청은 동일했다. 전체 URI 결과는 다음과 같다.

이 문자열의 중간에 일부 공통된 문자열(5848)이 있긴 하지만, 패턴을 쉽게 식별하긴 어렵다.

정적 분석을 통해 요청이 어떻게 생성됐는지를 정확하게 파악할 수 있다.

• 네트워킹 코드 찾기

네트워크 통신을 파악하기 위한 첫 번째 단계는 통신을 수행하기 위해 사용되는 실제적인 시스템 호출을 찾는 것이다.

가장 일반적인 하위 레벨의 함수는 윈도우 소켓(Winsock) API의 한 부분이다. 이 API를 사용하는 악성코드는 일반적으로 WSAStartup, getaddrinfo, socket, connect, send, recv, WSAGetLastError 같은 함수를 사용한다. 악성코드가 윈도우 인터넷(WinINet)을 호출하는 상위 레벨의 API를 사용할 수도 있다.

WinINet API를 사용하는 악성코드는 일반적으로 InternetOpen, InternetConnect, InternetOpenURL,

HTTPOpenRequest, HTTPQueryInfo, HTTPSendRequest, InternetReadFile, InternetWriteFile 같은 함수를 사용한다.

이 상위 레벨 API는 일반 브라우징에 사용되는 동일한 API이기 때문에 악성코드가 좀 더 효율적으로 정상 트래픽에 숨을 수 있게 한다. 네트워크에 사용할 수 있는 다른 상위 레벨 API는 COM(Component Object Model)인터페이스다. URLDownloadToFile 같은 함수를 통해 COM을 간접 사용하는 것은 매우 일반적이지만, COM의 직접 사용은 아직 찾아보기 드물다. COM을 직접적으로 사용하는 악성코드는 일반적으로 ConInitialize, CoCreateInstance, Navigate 같은 함수를 사용한다.

예를 들어 브라우저를 생성하고 사용하기 위한 COM의 직접 사용은 의도한 바와 같이 브라우저가 실제적으로

사용하는 것이기 때문에 악성코드가 정상 트래픽에 숨어들 수 있게 하며, 악성코드의 활동과 네트워크 트래픽

연결이 효율적으로 발견되지 않게 한다. 다음 표는 네트워킹 기능을 구현하기 위해 악성코드가 생성할 수 있는

API 호출의 개요이다.

<표 1-4 악성코드가 생성할 수 있는 API 호출의 개요>

다시 위의 샘플 악성코드로 돌아가서 악성코드의 임포트 함수는 InternetOpen과 HTTPOpenRequest를 포함하며,

이는 악성코드가 WinINet API를 사용함을 의미한다. HTTPOpenRequest의 파라미터를 조사할 때 악성코드에

하드 코딩된 User-Agent문자열을 볼 수 있다. 또한 HTTPOpenRequst는 수용 가능한 파일 유형을 지정하는

파라미터를 가지며, 이 파라미터 또한 하드 코딩된 콘텐츠를 가짐을 알 수 있다.

HTTPOpenRequst의 다른 파라미터는 URI 경로로, URI의 콘텐츠는 GetTickCount, Random, gethostbyname의

호출에서 생성됐음을 알 수 있다.

• 네트워크 콘텐츠 출처

시그니처 생성에서 가장 의미 있는 요소는 악성코드의 하드 코딩된 데이터다.

악성 코드가 전송한 네트워크 트래픽은 근본 출처(original source)의 제한된 집합으로 구성된다.

효과적인 시그니처의 생성은 네트워크 콘텐츠의 개별적인 근원에 대한 파악이 중요하다.

다음은 콘텐츠의 기본 출처의 예이다.

- 랜덤 데이터(예를 들어 의사난수 pseudorandom 값을 생성하는 함수의 호출을 통해 반환 받은 데이터)

- 표준 네트워킹 라이브러리의 데이터 (예를 들어 HTTPSendRequest 호출을 통해 생성한 GET)

- 악성코드에 하드 코딩된 데이터(예를 들어 하드 코딩된 User-Agent 문자열)

- 호스트와 호스트의 설정에 대한 데이터(예를 들어 호스트명, 시스템 시간의 현재 시간, CPU 스피드)

- 원격 서버나 파일 시스템 같은 다른 출처로부터 전달받은 데이터(예를 들어 암호화를 위한 전달되는 넌스otp,

로컬파일, 그리고 키 스트로크 로거로 캡처한 키 스트로크)

악성코드가 네트워크를 사용하기 전까지 데이터에 적용되는 다양한 레벨의 인코딩이 존재할 수 있지만,

이 글에서 강조하고자 기본적인 내용은 악성코드 탐지 시그니처 생성이다.

• 하드 코딩된 데이터와 임시 데이터

  윈속(Winsock) 같은 하위 레벨의 네트워킹 API를 사용하는 악성코드는 COM 인터페이스 같은 상위 레벨의 네트워킹 API를 사용하는 악성코드에 비해 정상 트래픽을 모방하기 위해 수작업으로 생성하는 콘텐츠가 더 많이 필요하다. 수작업이 더 필요한 콘텐츠란 하드 코딩된 데이터를 의미하는 것으로, 시그니처 제작에 사용할 수 있는 실수를 악성코드 제작자가 할 가능성을 증가 시킨다.

  이런 실수는 Mozilla에 대한 철자 실수(Mozila)와 같이 명확하거나, 특정 공백을 빠뜨리는 것과 같이 미묘할 수도 있다.

  샘플 악성코드에서는 하드 코딩된 Accept 헤더 문자열에 실수가 존재한다. 문자열은 정상적인 */* 가 아닌

  * / *와 같이 하드 코딩되어 있다. 이 경우는 시그니처 생성에 주요한 포인트가 되기에는 무리가 있으나,

  충분히 참고하거나 다른 콘텐츠와 함께 사용 할만한 가치가 있다.

  샘플 악성코드에서 생성된 URI가 다음과 같은 형식을 가짐을 떠올려보자.

  /14856205865810997108584848485355525551

   

  URI 생성 함수는 getTickCount, Random, gethostbyname을 호출한 후 문자열을 함께 합칠 때 악성코드는 콜론(:) 문자를 사용한다. 하드 코딩된 Accept 문자열과 하드 코딩된 콜론 문자는 시그니처에 포함시키기에 적합하다. Random을 호출한 결과는 어떤 랜덤 값이 반환이 되더라도 시그니처에 반영돼야 한다. GetTickCount와 gethostbyname 호출의 결과는 그 결과가 얼마나 고정적인지에 기반을 두고 포함 여부를 판단해야 한다.

   

  샘플 악성코드의 콘텐츠 생성 코드를 디버깅하는 동안 해당 함수는 문자열을 생성한 후 인코딩 함수로 전달한다. 전달되기 전에 문자열의 포맷은 다음과 같다.

  <랜덤한 4 바이트>:<호스트명의 첫 3 바이트>:<16진수로 표현된 GetTickCount의 시간>

   

  각 바이트를 얻은 후 ASCII 10진수 형태(예를들어 문자 a는 97이 된다)로 변환하는 단순한 인코딩 함수란 사실을 알 수 있다. 이제 동적 분석을 통해 URI의 의미를 알아내기 힘든 이유가 명확해진다. 무작위 성, 호스트 속성, 시간, 그리고 문자에 따라 길이가 변화하는 인코딩 함수를 사용하기 때문이다. 따라서 이 정보와 정적 분석을 통해 얻을 정보를 바탕으로, URI에 대한 효과적인 정규 표현 식을 쉽게 개발할 수 있다.

   

• 인코딩 단계 파악과 활용

  인코딩 단계를 정확히 파악하지 않는다면, 고정적이거나, 하드 코딩된 콘텐츠라고 하더라도 악성코드가 발신하는 트래픽 콘텐츠의 의미를 정확히 파악하기는 힘들다. 예를 들어 예제 악성코드에서는 GetTickCount 명령 결과과 두 단계의 인코딩을 거치는 것을 확인했다. 첫 단계로 바이너리 DWORD값을 8바이트 16진수 표현으로 변경한 후 각 바이트를 10진수의 ASCII값으로 변환했다. 따라서 10진수의 ASCII 콘텐츠만 가지고는 악성코드가 발신하는 데이터의 의미를 유추하기란 쉽지 않다. 인코딩 단계를 명확히 파악한다면 다음과 같은 정규 표현식으로 시그니처를 생성할 수 있다.

다음 표는 변환 과정을 설명하기 위해

위 예제의 일부를 사용해 파악된 데이터 원본과 최종 정규식 사이의 일치 성을 보여준다.

<표 1-5 발신 데이터 원본과 정규식의 일치성>

각 요소들이 정규 표현식에 어떻게 매칭되는지 설명하면 다음과 같다.

• 3개의 다른 요소를 구분 짓는 2개의 고정된 콜론은 표현에 중요한 역할을 하며, 콜론의 바이트 값은 위 표의 2번째와 4번째 열에서 확인 할 수 있다. 각 콜론은 ASCII 10진수 표현으로 58이다. 콜론은 시그니처 제작에 매우 중요한 원시 고정 데이터다.
• 앞쪽에 있는 랜덤 4바이트는 최종적으로 10진수 0에서 255로 변환될 수 있다.

정규 표현식 ([1-9]|1[0-9]|2[0-5]){0,1}[0-9])는 0에서 259까지의 범위를 나타내며, {4}는 해당 패턴이 4번

존재함을 나타낸다. 대괄호([])는 찾는값을 포함하며, 중괄호({})는 앞 심볼의 개수를 나타내는 나타낸다.

• PCRE에서 파이프 심볼(|)은 논리적 OR을 표현하기 때문에 괄호 안에 있는 조건중 하나는 일치하는 표현식을 위해 사용할 수 있다.
• 또한 이 경우에는 이전 정규 표현식보다 더 복잡하지 않게 하기 위해 살짝 허용 값을 259로 확장했다.

<그림 1-4 정규식 도형화:

http://regexper.com/#((%5B1-9%5D%7C1%5B0-9%5D%7C2%5B0-5%5D)%7B0%2C1%7D%5B0-9%5D)%7B4%7D%0A >

• 처리과정이나 인코딩 과정에 대한 지식은 하드 코딩되거나 고정된 요소를 파악하는 것 이상을 제공한다.
• 인코딩은 악성코드가 전송하는 특정 문자 집합과 필드의 길이를 제한할 수 있기 때문에 시그니처를 생성하는데 유용하게 사용된다.
• 예를 들어 첫 콘텐츠가 랜덤이지만 특정 길이를 알고 있으며, 문자 집합과 최종 인코딩 레이어의 전체 길이에 제한이 있음을 알 수 있다
• 58사이에 있는 중간 값 [0-9]{6,9}는 ASCII 10진수로 변환된 호스트명의 첫 세 문자다. 이 PCRE 표현은 6에서 9개의 10진수 문자열과 일치한다. (0= A=65, a=97처럼 10진법이 시작한다.)

• 호스트명은 한자리 ASCII 값(0-9)을 포함하지 않으며, 프린트할 수 있는 문자도 아니기 때문에 최소 묶음을 3이 아닌 6(10진수 값의 길이가 2인 문자 3개)으로 설정했다.

  이처럼 하드 코딩된 데이터를 포함하는 것만큼이나 시그니처에 임시요소를 포함시키지 않는 것도

중요 하다. 동적 분석에 대한 앞에서 살펴봤듯이 감염된 시스템의 호스트명은 해당 호스트에서는 일관돼

보일 수 있지만, 해당 요소를 사용하는 시그니처는 다른 감염된 호스트에 대해서는 유효하지 않다.

• 정규 표현식 세번째 부분 (4[89]|5[0-7]|9[789]|10[012]){8} 은 GetTickCount 호출을 통해 수집하는 시스템의 가동시간(uptime)을 나타내는 문자의 가능 값을 포괄한다. GetTickCount 명령어의 결과는 DWORD이며, 16진수로 변환된 후 ASCII 10진수로 표현된다. 그러므로 GetTickCount 명령의 값이 268404824(약 3일간의 uptime)라면 16진수 표현으로 0x0fff8858이 된다. 따라서 ASCII 10진수로 표현되는 숫자는 48 ~ 57이며, 소문자(a에서 f까지 제한)는 ASCII 10진수 97에서 102로 표현된다. 이 정규 표현식에서 알 수 있듯이 8은 16진수 문자의 개수와 일치하며, 논리적 OR을 사용하여 필요한 숫자의 범위를 포괄하도록 한다.

<그림 1-5 정규식 도형화:

http://regexper.com/#(4%5B89%5D%7C5%5B0-7%5D%7C9%5B789%5D%7C10%5B012%5D)%7B8%7D>

• 이처럼 악성코드가 발신하는 네트워크 데이터가 처음에는 무작위 하게 나타나 사용할 수 없는 것처럼 보일 수 있지만, 데이터의 일부는 사실적으로 예측이 가능한 경우가 많다.
• 시간은 이런 예 중 하나다. 상위(high-order) 비트는 상대적으로 고정되며, 때에 따라서는 시그니처로 쓸 수 있을 만큼 충분히 안정적인 데이터의 출처가 될 수 있다.
• IDS 장비의 성능(performance)과 정확성(accuracy) 사이에는 트레이드오프(trade-off))가 존재한다.

  이번 예에서 정규 표현식은 IDS의 성능 부하를 고려한 정책 테스트는 아니다.

  성능과 정확성을 향상시키기 위해서는 유일한 고정 콘텐츠 문자열이 콘텐츠 기반 검색을 크게 개선 시킬 수 있지만, 이번 예제의 경우 유일한 고정 콘텐츠인 58이 짧기 때문에 쉽지 않았다.

• 위 예에서는 정확성과 범위에 예를 들기 위해 PCRE를 강조 하였다. 악성코드에서 발생시키는 특정 문자열(User-Agent, Aceept, Referer 등)이나, PCRE를 조금 러프하게 잡고, 제한된 바이트에 대해서만 검색하거나, 검색할 범위를 지정하여 시그니처를 생성 할 수도 있다.

• 공격자 관점의 이해

탐지 시그니처 전략을 설계할 때 공격자의 관점을 이해하려는 노력이 필요하다.

그들의 의도는 정상 트래픽에 섞여 들어 탐지되지 않고 침해 시스템에 대한 주도권을 계속 유지하는 것이다.

여느 다른 소프트웨어 개발자들처럼 현재 상태를 유지하고 변화하는 시스템의 호환성을 유지하기 위해

공격자도 악성코드를 업데이트하기 위해 노력한다. 당연히 방어자의 입장에서도 끊임없는 노력이 필요하다.

해당 악성코드의 다중 시그니처를 생성함으로써 공격자가 코드의 일부분을 수정하여 배포하더라도 여전히 악성코드를 성공적으로 탐지할 수 있다.

다음은 공격자의 약점을 고려해 활용할 수 있는 세가지 규칙이다.

• 양측 엔드포인트(end point)의 일부인 프로토콜 요소(element)에 집중하라.
• 클라이언트의 코드나 서버의 코드를 개별적으로 변경하는 것은 양측을 함께 변경하는 것보다 쉽다.

  클라이언트와 서버 측 모두에서 사용하는 코드가 사용자는 프로토콜 요소를 찾아 이 요소들을 기반으로 시그니처를 만들자. 공격자가 이런 종류의 시그니처를 무력화시키려면 다수의 추가적인 작업을 해야 한다.

핵심 요소로 알려진 프로토콜 요소에 초점을 맞춰라.

종종 프로토콜의 하드코딩 된 일부 컴포넌트가 핵심 요소로 사용될 수 있다. 예를 들어 공격자는 특정

User-Agent 문자열을 인증 키로 사용하여 탐지하는 경우, 공격자가 이런 시그니처를 우회하려면 양측 엔드

포인트의 코드를 변경해야 한다.

알려진 탐지 시그니처는 미탐을 초래할 수 있다.

다른 방어자가 공격자에 대해 충분히 유효한 시그니처를 생성하여 공개했다면, 공격자는 해당 시그니처를

우회하기 위해 악성코드를 수정할 것이다. 따라서 알려진 동일한 시그니처에 의존한다면 공격자가 악성코드를

수정할 경우 우리의 시그니처도 무력하게 만들 수 있다.

따라서 우리는 다른 방어자가 초점을 맞출 가능성이 낮은 악의적인 행위 특징을 파악하게 노력해야 한다.

악성코드를 주의 깊게 관찰해 얻은 지식은 좀더 강력한 시그니처를 개발하는 데 도움을 줄 수 있다.

또한 이 시그니처는 외부에 공개하는 순간 사실상 무력화 되는 것임을 유의하여야 한다.

일반적으로 IDS제품을 구입하더라도 탐지 시그니처는 해당 제품 기업의 기업 비밀로 공개되지 않는다.

03. 정리

1. 학습 정리

본 14장 학습문서에서는 악성코드가 네트워크를 사용해 명령과 통제를 하는 방법을 설명했다.

또한 악성코드가 자신의 활동을 일반 네트워크 트래픽 처럼 가장하기 위해 사용하는 일부 기법도 다뤘다. 악성코드 분석은 시그니처 생성과정에서 통찰력을 제공함으로써 네트워크 방어의 효율성을 개선시킬 수 있다.

기존 트래픽 캡처의 표면적 분석이나 샌드박스 기반의 악성코드 분석에 비해 상세 악성코드 분석에 기반을 둔 네트워크 시그니처가 가진 여러 이점을 설명했다.

악성코드 분석에 기반을 둔 시그니처는 좀 더 정확하며, 오탐을 줄이기 위해 필요한 시도와 에러를 줄일 수 있다. 본 학습에서는 기본적인 악성코드 분석의 최종 목표(악성코드를 탐지할 수 있는 효율적인 대응 방안의 개발)가 무엇인지를 설명하였다.

하지만, 일부 악성코드 제작자는 효과적인 분석을 방해하는 고도화된 대응 방안을 갖고 있다.

우리는 본 학습을 통해 악성코드를 탐지하는 효과적인 네트워크 기반 대응 방안을 학습하였고,

이 학습을 기초로 좀더 고도화되고, 좀더 효율적인 탐지 방안을 연구해야 할 필요가 있다.

이후의 학습에서는 악성코드 제작자가 분석을 방해하기 위해 사용하는 기법과 악성코드를 완벽하게 분해하고

이해하기 위해 어떤 단계를 취해야 하는지에 대해 설명하도록 하겠다.

05. 참고문헌

[1] Practical Malware Analysis Capter#14

[2] REGEXPER: http://regexper.com

[3] nextree: http://www.nextree.co.kr/p4327/

[4] KT한: http://kthan.tistory.com