1. 개요

 악성코드에 대해 공부를 할 때는 몰랐지만, 직접 여러 악성코드를 분석해보니 네트워크와 연결을 진행하는 악성코드가 정말 많다는 것을 알게 되었습니다. 그렇기에 네트워크와 관련해서 정말 지식이 부족하다고 느껴지기에 계속 미루는 것보단 한번 직접 네트워크에 대해 간간히 공부해보자는 생각에서부터 이렇게 시작하게 되었습니다.

 이번 문서에서는 네트워크에 대한 저의 첫 문서인 만큼 너무 깊이는 들어가지고 않고 향후에 악성코드를 분석하는데 있어 저번과 같은 지장이 있지 않을 정도로 학습을 하려고 합니다. 따라서 이번에는 간단하게 WireShark에 대하여 기초적인 학습을 진행하였습니다. 

1.1 WireShark란?

보안 공부를 시작한지 얼마 안된 사람들도WireShark나 Nmap에 대해서는 자주 들을 수가 있을 것입니다. WireShark는 세계에서 가장 널리 쓰이는네트워크 프로토콜 분석기로 아래와 같은 장점이 있습니다.

그림 1. WireShark

• 오픈 소스라 무료로 사용이 가능
• Packet Capture를 위한 pcap 네트워크 라이브러리 제공
• Tcpdump와 유사하나 GUI를 통해 편리한 인터페이스 제공
• 다양한 필터링 기능 제공

1.2 네트워크 개념

아래의 그림은 OSI 7 Layer에서 각 레이어별 기능과 통신 프로토콜에 대해 간단히 정리되어 있는 것이다.

그림 2. 각 레이어별 기능과 프로토콜

아래의 그림은 TCP를 이요한 3-Way Handshaking으로 이후에 나오는 내용이기에 참고할 겸 첨부하였다.

그림 3. 3-Way HandShake

2.패킷 캡처

 우선 실행 후 화면은 아래의 그림-3와 같다. Start라는 버튼 아래 현재 환경에서 갖는 네트워크 장치에 대해 목록이 있으며, 이 중에 하나를 선택 후 'Start'를 누르면 캡처가 시작된다.

그림 4. WireShark 실행 화면

  이렇게 패킷 캡처를 시작하면 네트워크 장치를 지나는 패킷들이 나열되며 본인의 PC 환경에 따라 상이하지만 대부분 정말 많은 패킷의 교환을 확인할 수가 있다.

2.1 패킷 캡쳐

이제 실제 악성코드가 행위에 사용했던 네트워크 패킷을 한번 확인해보자. 해당 악성코드는 저번 주 분석에 실패를 하였던 Nethost.exe에 초점을 맞추었다.

그림 5. Packet Capture 화면

위에서 Start를 통해 악성코드를 실행하기 전에 캡처한다. 그 후 악성코드가 실행되는 동안의 패킷들이 와이어샤크가 기록을 하며 악성코드의 종료와 함께 캡처를 중지하였고 총 2182개의 패킷이 캡처되었으며, 매우 많은 양임을 알 수가 있다. 따라서 아래와 같은 필터링 기능을 통해 범위를 줄여보자.

2.2 실습 – GET /chrome_extension.exe

아래와 같은 필터 옵션을 적용하므로 이전보다 가독성이 좋아지는 것을 확인할 수가 있다. 해당 패킷을 보면 그림-3에서와 같이 3 way handshake를 통해 연결이 진행되는 것을 확인할 수가 있다.

그림 6. TCP 연결

위의 연결이 해제된 후 재연결이 되면 HTTP로 해당 아이피에 /chrome_extension.exe를 요청하는 것을 확인할 수가 있다.

그림 7. TCP 연결 & extension.exe요청

 이렇게 요청을 한 후 아래의 그림과 같이 1514의 길이만큼 지속적으로 패킷을 받는 것을 확인할 수가 있다. 여기서의 패킷은 디버거를 통해 확인해본 결과 extension.exe에 기록될 명령어들의 내용이다. 아래의 그림과 같이 확인할 수가 있다.

그림 8. GET - Extension.exe

2.3 실습 – GET /chrome_start_page.exe

 Nethost.exe는 이러한 동작을 한번 더 반복하는데 이번에는 extension.exe가 아니라 start_page.exe로 데이터를 요청하는 것을 확인할 수가 있다. 아래의 그림과 같다.

그림 9. GET – Start_Page.exe

 이와 같이 IP주소 193.238.153.91과의 통신은 각 파일에 기록될 데이터들을 주고 받고 종료가 된다. 따라서 다른 IP와 연결되는 패킷도 확인을 해보자.

2.4 실습 – 이 외 패킷

 위의 작업이 끝난 후 다른 패킷들을 살펴 본 결과 아래의 패킷을 확인할 수 있다. HTTP로 185.20.186.44에 패킷을 보내는 것으로 마지막에 Fail이라는 단어를 같이 보내는 것으로 보아 악성코드의 어떠한 기능이 실패했다는 것을 추측해볼 수가 있다.

그림 10. Fail을 보내는 패킷

 하지만 이것만 가지고는 불분명했지만 뒤에 캡처된 패킷의 경우 종료를 알리는 것을 확인할 수가 있었고, 이외의 기능이 없이 이와 관련된 연결이 모두 종료되는 것을 확인할 수가 있었다.

그림 11. Fail이후의 패킷

  3. 결론

 지난 주에 nethost.exe를 분석하며 해당 악성코드가 웹 브라우저의 정보를 가지고 오는 것임을 추후에 확인할 수가 있었는데, 이러한 기능을 하지 않고 종료되는 것을 확인할 수가 있었다.

 이에 대해 몇 가지 결론을 생각해본다면 해당 서버에 연결을 시도하고 RST와 ACK 패킷이 돌아오는 것으로 보아, 해당 서버가 현재는 막혔을 것이라 예상을 해볼 수가 있다.

 이러한 네트워크 분석을 병행하므로 확실히 해당 악성코드에 대한 이해도가 높아지는 것을 체감할 수가 있었고, 이론만 공부하다가 악성코드를 직접 분석해보며 항상 느끼는 것이지만 무엇이 부족한지 매번 알게 된다는 점이다. 따라서 이후에 네트워크에 대하여 한계를 느끼면 다시 해당 문서를 작성하고자 합니다.

참고

필터링 옵션과 관련하여 참고

https://wiki.wireshark.org/CaptureFilters

https://wiki.wireshark.org/DisplayFilters

전체적인 내용

    http://asec.ahnlab.com/156

    http://openness.tistory.com/entry/Wireshark-%EC%82%AC%EC%9A%A9%EB%B2%95

  개요

해당 악성코드 파일(nethost.exe)에 대한 기본적인 파일 정보는 아래의 표-1과 같다. 

이를 통해 해당 악성코드는 러시아어로 작성된 것과 버전에 따라 유포자 및 제작자에 의해 업데이트가 될 수 있다는 것을 확인할 수가 있다.

  정적 분석

정적 분석에서는 PE구조를 확인하고, 이를 통해 패킹의 여부를 확인하며 그 외에 PE구조의 특이사항을 확인할 것이다. 이러한 PE 구조의 특이사항이란 IAT나 문자열 등을 포함하며 이를 통해 프로세스의 대략적인 기능에 대하여 추측해볼 것입니다.

PE구조 분석

PE구조를 확인해본 결과 별도의 패킹이 되지 않은 것을 확인할 수가 있었으며, TLS 영역도 존재하지 않음을 확인할 수가 있다. 아래의 그림은 DIE를 통해 해당 프로그램을 분석한 결과이다..

그림 1. PE구조 분석

그림에서와 같이 해당 악성코드는 C/C++로 작성된 것을 확인할 수가 있다.

문자열 분석

해당 악성코드에는 다양한 문자열들이 존재하는데 네트워킹과 관련된 문자열이 많음을 확인할 수가 있습니다. 몇 가지 선별한 문자열은 아래와 같다. 

이러한 문자열들을 통하여 인터넷 브라우저를 통하여 네트워킹을 진행하며 이외에도 ping 명령어, 그리고 레지스트리 키, FTP 등을 확인할 수가 있다. 따라서 웹브라우저의 연결을 통하여 특정한 사이트와 연결을 하거나, 다른 어떠한 작업을 진행하기 위하여 ping 명령어를 사용하는 것이라 예상해 볼 수가 있다.

Import Address Table 분석

어떤 함수들이 사용되고 있는지 IAT에 나타나있는 항목을 Dependency Walker를 통해 확인해 보았으며, 이 중에서 악성코드의 기능으로 의심되는 몇 가지 항목은 아래의 표와 같습니다. 

이를 통해 보았을 때 WS2_32.dll에서 네트워킹과 관련된 API들이 많이 사용되는 것을 알 수가 있다. 또한 CRYPT32.dll과 ADVAPI32.dll을 통해 암호화와 레지스트리 값 설정을 하는 함수가 존재하며 KERNEL32.dll을 특정한 파일과 기능하는 함수들이 있고 SHELL32.dll을 통해 특정한 명령어를 실행할 것이라 예상할 수가 있다.

동적 분석

동적 분석에서는 정적 분석을 토대로 예상되는 기능들을 직접 안전한 환경에서 실행하므로 일어나는 변화들을 관찰하여 이에 대하여 알아볼 것입니다. 여기선 Process Explorer를 통하여 프로세스의 변화를 관찰하고 TCP Viewer를 통하여 네트워크를 관찰하고 마지막으로 MFT를 분석할 것입니다.

          프로세스 분석

해당 프로세스를 실행시키고 ProcessExplorer을 통하여 아래와 같이 extension.exe가 실행이 추가적으로 실행이 되며, 이후 startpm.exe도 실행이 되는 것을 알 수가 있다.

그림 2. 프로세스 진행과정(1)

이렇게 3개의 프로세스가 실행되고 startpm.exe가 종료되기 전에 하위 프로세스로 CMD를 통하여 Ping 명령어를 사용하는 것을 확인할 수가 있었다.

그림 3. 프로세스 진행과정(2)

이러한 결과를 토대로 이후4장 상세 분석을 함에 참고를 하면 도움이 될 것이다.

네트워크 분석

해당 악성코드가 네트워킹을 하는 과정에 대하여 어느 곳과 연결이 네트워킹을 하는지 알아보기 위하여 TCP Viewer를 통하여 확인해보았다.

그림 4. TCP/UDP 연결 확인

위의 그림에서와 같이 악성코드가 실행된 후 이전에는 없던 System Process(PID:0)이 생기는 확인할 수가 있다. 이렇게 사용되는 프로세스와 원격주소에 대하여 정리한 것은 아래의 표와 같다.

이와 같이 총 9개의 주소 혹은 IP와 네트워킹을 하는 것을 확인할 수가 있으며, 프로세스가 종료된 후에는 이러한 네트워킹도 모두 종료가 되는 것을 확인할 수가 있었다.

MFT 분석

악성코드가 동작한 시간 이후로 MFT에 나타난 변화를 통하여 어떠한 파일이나 디렉터리가 생성되었는지를 확인해 보았으며 아래의 표와 같이 정리할 수가 있습니다. 

위의 표와 같이 SystemDir이라는 디렉터리를 생성 후 Temp나 그 곳에 부차적인 파일들을 생성하여 실행을 진행하고 실행이 완료된 후에는 삭제하는 것을 확인할 수가 있었다.

그 후 IE와 관련된 흔적들을 지우는 것을 확인할 수 있었으며 이를 통해 웹을 통한 행위에 대해 유심히 살펴보아야 함을 알 수가 있다.

상세 분석

상세 분석에서는 해당 악성코드에 대하여 상세한 분석이 진행되며, 필요하다면 부차적인 파일들도 상세 분석을 진행할 것이다.

Nethost.exe분석

우선 MFT에서 분석한 바와 같이 Nethost는 %AppData%\Local\SystemDir을 생성하는 것을 확인할 수가 있었다. 이후에 extension.exe와 startpm.exe는 동시에 생성되는 것이 아니라 같은 방식으로 extension.exe이 먼저 생성되기에 이에 맞추어 startpm.exe의 생성과정은 생략하였다.

그림 5. SystemDir 생성

이렇게 생성된 디렉터리와 %AppData\Local\%Temp 디렉터리를 통하여 악성코드가 어떠한 행위를 하는 것을 알 수가 있었다. 이렇게 기능을 한 후 프로세스가 종료된 후 디렉터리 내에 해당하는 내용들을 삭제하는 것 또한 확인할 수가 있었다.

그림 6. 네트워크 연결

네트워킹을 진행하는 것을 확인할 수가 있으며 send와 recv명령어를 사용하는 것을 확인할 수가 있었으며 동적 분석에서 확인한 바와 같이 여러 IP와 연결하는 것을 확인할 수가 있었다.

그림 7. CreateFile함수 통한 파일 생성

위의 그림과 같이 SystemDir 디렉터리에 extension.exe라는 파일을 생성을 하며, 이후엔 이와 같은 방식으로 startpm.exe를 생성한다. 이렇게 생성된 파일은 아래의 그림과 같이 WriteFile API를 통하여 버퍼가 기록된다.

그림 8. WriteFile 통한 기록

이렇게 recv를 통해 데이터를 받은 후 WriteFile을 통하여 4096Byte 만큼씩 데이터를 기록하는 것을 확인할 수가 있다. 이때의 IP는 193.238.153.90이다.

그림 9. MoveFile을 통한 파일 이동

872KB까지 기록이 된 후 MoveFile 함수를 통하여 기록되던 파일(SystemDir\)이 Temp디렉터리에 exe.tmp로 이동 되는 것을 확인할 수가 있다. 이후 아래의 그림과 같이 CopyFile 함수를 통하여 최초에 실행됐던 nethost.exe가 Temp\extension.exe와 Temp\startpm.exe로 복사가 되는 것을 확인할 수가 있다.

그림 10. CopyFile을 통한 파일 복사

이렇게 된 후 .tmp로 옮겨진 파일을 읽어서, CopyFile을 통한 원본과 같은 파일에 쓰는 것을 아래의 그림과 같이 확인할 수가 있다.

그림 11. 복사된 파일에 기록

위의 루프가 끝난 후 아래 그림 같이 CreateProcess를 통하여 각 파일(extension.exe, startpm.exe)를 실행하는데 여기서 이를 실행할 때 아래의 그림과 같이 인자를 주는 것을 확인할 수가 있었다.

그림 12. CreateProcess API 함수

CreateProcess의 CommandLine에 사용되는 각 프로세스의 인자는 아래의 표-6에 정리한 것을 볼 수가 있다. 여기서 이는 모두 한 줄에 해당하는 항목임을 유의하자. 

이렇게 각 프로세스는 생성된 후 아래의 그림과 같이 DeleteFile API를 사용하여 exe.tmp파일을 제거한다.

그림 13. DeleteFile API 함수

이렇게 작업을 수행한 후 해당 nethost.exe는 종료가 되는 것을 알 수가 있다. 이러한 분석을 통해 보았듯이, nethost.exe는 Dropper인 것을 알 수가 있다.

Analyzing-server.pdf

Server.exe 악성코드 분석

선호 경로

악성코드는 보통 자신의 존재를 은닉하고자 하며, 떄로는 사용자로부터 간단한 방법을 통하여 속이고자 한다. 우선 파일의 이름을 실제 윈도우 파일과 비슷하게 kernei32.dll 로 변경하는 등 다양한 방법을 사용한다. 그 중에서 경로를 통하여 은닉하고자 할 때 주로 쓰이는 경로는 아래와 같다. 한번 살펴 보자.

# 시스템 폴더

시스템 폴더는 윈도우의 주요 시스템 파일이 존재하는 곳으로 은닉을 위해 시스템 파일과 파일명을 유사하게 변경하거나 경로를 바꿔 저장한다. 자주 사용되는 경로는 다음과 같다.

SysWOW64는 64비트 시스템에서만 존재하는 폴더로 32비트와의 호환성을 위해 존재하는 폴더이다. “%SystemRoot%\system32\” 폴더에 64비트 시스템 파일이 위치한다면 “%SystemRoot%\SysWOW64\”에는 32비트 시스템 파일이 위치한다. 따라서, 64비트 시스템에서는 2개의 폴더를 모두 조사할 필요가 있다.

# 사용자 기본 폴더

윈도우 비스타 이후부터 사용자의 홈 폴더는 “%SystemDrive%\Users\” 하위에 존재한다. 해당 폴더 하위를 살펴보면 사용자의 홈 폴더 이외에도 기본 폴더인 “Public(공용)”, “Default”가 존재한다. “Public” 폴더에는 각 사용자가 공통으로 가지는 파일(공용 사진, 비디오 등)이 저장되어 있고, “Default” 폴더에는 새로운 사용자 생성 시 초기 구성을 위한 파일이 저장되어 있다. 이런 폴더는 일반적으로 직접 들어가지 않기 때문에 공격자가 자주 은닉의 대상으로 삼는다. 또한 “Default”에 악성코드를 위치시키면 새로운 사용자가 생성될 때마다 자동 복사되기도 한다.

# 사용자 데이터 폴더

각 사용자의 응용프로그램 데이터가 저장되는 데이터 폴더는 숨긴 폴더이기 때문에 폴더 속성을 변경해야만 나타난다. 데이터 폴더도 일반적으로는 들어가지 않기 때문에 해당 경로가 악성코드 은닉에 자주 사용된다.

# 휴지통 폴더

윈도우의 휴지통 폴더는 운영체제에 의해 보호되어 있기 때문에 폴더 속성을 변경해야만 나타난다. 휴지통 폴더 하위에는 각 사용자의 SID 폴더가 나타나도 SID 폴더에 각 사용자가 삭제한 파일이 위치한다. 바탕화면에서 살펴보는 휴지통 내용은 로그인 사용자의 SID 폴더 내용이다. 악성코드는 휴지통 하위 SID 폴더와 동일한 수준으로 자주 은닉한다.

# 시스템 볼륨 정보 폴더

시스템 복원 지점이나 볼륨 섀도 복사본이 저장되는 시스템 볼륨 정보 폴더는 운영체제에 의해 보호되어 있다. 폴더 속성을 변경하면 폴더의 존재는 확인할 수 있지만 폴더 내용은 확인할 수 없다. 폴더 내용을 확인하기 위해서는 폴더의 접근 권한을 변경해주어야 한다. 따라서, 악성코드를 장기간 안전하게 은닉할 수 있고 일부 보안 솔루션은 이런 이유로 해당 폴더 하위를 진단하지 못하기 때문에 악성코드가 종종 사용한다.

# 임시 폴더

임시 폴더는 공격자가 의도하기 보다는 악성코드가 시스템에 자동 유입되거나 드롭퍼가 드롭할 때 임시로 사용하는 경로로 악성코드의 복사본이 자주 존재한다.

# 웹 브라우저 다운로드 경로

웹 브라우저의 기본 다운로드 경로나 액티브 X, 자바 애플릿 경로 등도 웹 브라우저를 이용하는 악성코드가 다운되어 있을 가능성이 많다.

# 알려진 폴더

조직마다 공통된 사양의 표준 PC를 사용하다보니 모든 사용자에게 공통으로 존재하는 폴더가 있다. 특정 조직을 공격할 때 이런 폴더들이 종종 사용되곤 한다.

# 그 밖에 폴더

앞서 언급한 폴더 이외에도 악성코드가 자주 위치하는 경로는 다음과 같다.

Reference

파이썬을 통하여 만든 안티바이러스(백신) 오픈소스이다. 파이썬과 백신에 대하여 공통적으로 관심이 있는 분이라면 한번쯤 사이트에 들어가서 소스를 보는 것도 괜찮을 것 같아서 올립니다.

http://www.kicomav.com/            키콤 사이트

http://www.hanul93.com/            키콤을 만드신 최원혁씨의 블로그

About KicomAV

KicomAV is an open source (GPL v2) antivirus engine designed for detecting malware and disinfecting it. In fact, Since 1995, it has been written in C/C++ and it was integrated into the ViRobot engine of HAURI, 1998. I decided to re-create a new KicomAV. So, this is developed in Python. Anyone can participate in the development easily.

How to use

Requirements

- Python 2.7

Quick start

        - Three quick start options are available:

  - Download the latest release and unzip it

  - Clone the repo: git clone git://github.com/hanul93/kicomav.git

  - Build KicomAV Engine & Plugins modules : build.sh or build.bat

  - You can see Release Directory. Change the Release directory and run k2.py

packers.pdf

http://corkami.googlecode.com/files/packers.pdf

Packers are most commonly used for compression, code obfuscation, and malware anti-reversing. While not always malicious, packers are often a clue to look a little deeper into a particular binary. Ange Albertini did a marvelous job of representing the (known) universe of executable packers in this infographic.

들어가기 전에

멀웨어 코더들은 분석을 방해할 목적으로 안티 가상머신 기법을 사용한다. 이 기법을 이용해 악성코드가 가상머신 내에 실행 여부를 탐지할 수 있으며, 가상 머신을 탐지하면 악성코드는 원래와 다르게 실행하거나 전혀 실행하지 않는다. 여기서는 일반적으로 VMware를 대상으로 하는 안티 가상머신기법에 대하여 알아볼 것이다.

VMware Artifacts

VMware환경은 시스템에 많은 흔적을 남기며, 특히 VMware Tools를 설치했을 경우 그렇다.악성코드는 파일 시스템이나 레지스트리, 프로세스 목록에 존재하는 흔적을 VMware를 탐지하는데 사용한다.

아래의 그림은 VMware를 설치해놓고 사용을 했던 나의 PC의 프로세스 목록이다. 확실히 많은 프로세스가 실행 중임을 알 수 있고, 이들 중 하나를 선택하여 악성코드는 프로세스 목록에서 VMwae와 관련된 문자열을 검색하는 방식으로 탐지가 가능하다.

프로세스 목록 뿐만 아니라 시스템에 설치한 서비스를 찾기 위해 레지스트리를 검색하거나 다음 명령어를 사용하여 서비스 목록에 위치한 VMware와 관련된 항목들을 나열할 수가 있고 이를 통하여 악성코드는 가상 머신의 여부를 확인할 수가 있다.

또한 가상머신은 다양한 방법으로 네트워크에 연결할 수 있는데, 이 모든 방시은 가상머신이 고유의 가상 네트워크 인터페이스 카드(NIC)를 가진다. VMware가 NIC를 가상화하려면 가상머신의 MAC 주소를 만들어야하며, 설정에 따라 네트워크 어댑터를 이용해 VMware 사용 여부도 확인할 수 있다.

MAC 주소의 처음 3 바이트는 일반적으로 업체를 명시하는데, VMware는 00:0C:29로 시작하는 MAC 주소를 할당한다(*하지만 내 PC에서 확인해본 결과 00-50-56으로 시작하였다. 일반적으로 버전마다 변한다.).

Bypassing VMware Artifact Searching

Vmware 흔적을 검색하는 악성코드 무력화는 일반적으로 간단히 검사확인과 패치 두 단계를 거친다. 예를 들어 아래의 그림을 보자. 악성코드가 프로세스 목록을 가져 온 뒤 Vmware와 관련이 있는 문자열 "VMwareTray.exe"를 가져온 후 strncmp 함수를 호출하여 악성코드가 가상 머신의 여부를 판단할 수가 있다.

이 탐지를 피하기 위해서는 4010A5에 있는 점프를 실행하지 않게 디버깅 도중에 바이너리를 패치하거나 해당 문자열을 수정하여 걸리지 않도록하는 등 회피 방법이 존재하고 있다.

Checking for Memory Artifacts

VMware는 가상화 프로세스의 결과로 메모리에 많은 흔적을 남긴다. 일부는 중요한 프로세서 구조인데, 가상머신에서 이를 이동하거나 변경해서 인지할 수 있는 흔적을 남기기 때문이다. 일반적으로 메모리 흔적을 탐지할 때 사용되는 기술은 물리적 메모리에서 문자열 VMware을 탐지하는 방식으로 발견한 흔적에서 수백개의 문자열을 탐지해 낼 수 있다.

Vulnerable Instructions

가상머신 모니터 프로그램은 가상머신의 실행을 모니터링한다. 이는 가상 플랫폼과 함께 게스트 운영체제를 나타낼 수 있게 호스트 운영체제 이ㅜ에서 동작한다. 이 역시 악성코드가 가상화를 탐지할 수 있는 일부 보안 취약점을 갖고 있다.

일부 x86 명령어는 하드웨어 기반 정보에 접근하지만 인터럽트를 생성하지 않는다. 그런 명령어에는 sidt, sgdt, sldt, cupid 등이 있다. 이 명령어를 적절히 가상화시키려면 VMware는 모든 명령어에서 바이너리 해석하는 과정이 필요한데, 이는 결과적으로 엄청난 성능 저하를 가져온다. 이러한 성능 저하를 막기 위해 VMware는 특정 명령어의 경우 제대로 가상화하지 않고 실행한다.

Using the Red Pill Anti-VM Technique

레드 필은 sidt 명령어를 실행해서 IDTR 레지스터 값을 얻는 안티 VM 기법이다. 가상 모니터는 게스트의 IDTR을 재배치해서 호스트의 IDTR과 충돌을 피해야한다. 가상머신 모니터는 가상머신이 sidt 명령어를 실행하는 시점을 알지 못하므로 가상머신의 IDTR을 반환한다. 레드 필은 이 불일치함을 테스트해서 VMware의 사용 여부를 탐지한다.

악성코드는 sidt 명령어를 이용해 EAX가 가리키는 메모리 위치로 IDTR 내용을 저장한다. IDTR은 6바이트이고 다섯번째 바이트 오프셋이 베이스 메모리 주소 시작점을 갖고 있다. 다섯 번째 바이트를 VVMware 시그니처인 0xFF와 비교한다.

이러한 레드 필은 단일 프로세서를 사용하는 장비에서만 성공한다. 그러므로 멀티프로세서 장비에서 실행하거나 sidt 명령어를 삭제하면 우회가 가능하다.

Using the No Pill Technique

VMware 탐지에 사용하는 sgdt와 sldt 명령어 기법은 주로 No Pill로 알려져있다. 레드필과는 다르게 LDT 구조체를 운영체제가 아닌 프로세서에 할당한다는 사실에 의존한다. 호스트 머신에서 LDT 위치는 0이고, 가상머신에서는 0이 아니다. sldt 방식은 가속 기능을 비활성화해서 VMware에서 사용하지 못하게 할 수 있다. 이를 위해 VM > Settings > Processors를 선택하고 Disable Acceleration 체크박스에 체크한다.

Querying the I/O Communication Port

현재 사용하는 가장 대중적인 안티VMware 기법은 I/O 통신 포트를 질의하는 방식일 것이다. Vmware는 가상 I/O 포트를 이용해 가상머신과 호스트 운영체제 사이에서 두 시스템 간의 복사와 붙여넣기 같은 기능을 지원한다. 포트를 질의하고 VMware 사용을 식별하는 매직넘버와 비교할 수 있다.

VMware는 명령어 사용을 모니터링하고 통신 채널 포트 0x5668(VX)로 목적지 I/O를 캡처한다. 따라서 두번째 오퍼랜드는 VMware를 확인할 목적으로 VX를 로드할 필요가 있으며, EAX 레지스터는 매직 넘버인 0x564D5868(VMXh)을 로드한다.

우선 악성코드는 매직 넘버인 0x564D5868을 1의 EAX 레지스터로 로드한다. 그 후 ECX는 0xA 값을 로드해서 VMware 버전 유형을 알아낸다. 2에서는 해당 값을 통해 VMware I/O 통신 포트를 지정하는 in 명령어에 사용한다. 실행시 in 명령어는 가상머신이 트랩해서 실행을 에뮬레이션한다. 3에서 코드가 가상 머신 동작 여부를 확인한다.

이 기법을 우회하는 가장 간단한 방법은 in 명령어를 NOP 처리하거나 조건부 점프를 패치해서 비교 결과와 상관없이 점프하는 방식이다.

Using the str Instruction

str 명령어는 실행중인 TSS(Task State Segment)를 가리킨다. 악성코드 제작자는 str 명령어가 가상머신과 실제 시스템이 다른 값을 반환한다는 사실을 이용해 이 명령어로 가상머신 존재여부를 탐지한다.

Anti-VM x86 Instructions

지금까지 안티 VM 기법에 이용하는 악성코드의 가장 일반적인 명령어를 살펴봤다. 이 명령어에는 다음과 같은 것들이 있다.

-sidt    -sgdt    -sldt    -smsw    -str    -in    -cpuid

악성코드는 전형적으로 VMware 탐지를 수행하지 않는 경우 이 명령어를 실행하지 않으며, 탐지 우회는 역시 이 명령어 호출을 피하는 바이너리로 패치만 하면 되므로 간단하다. 이 명령어는 기본적으로 사용자 모드에서 실행할 경우 무의미하므로 이 명령어가 보이면 안티 VMware 코드의 일부일 가능성이 있음을 알 수 있다.

요약

- 프로세스 목록    - 서비스와 레지스트리    - MAC 주소

- sidt, sgdt, sldt, cpuid    - in 통신포트 VMxh, VX, 0x5668, 0x564D5868    - str 명령어

Windows Debugger Detection

악성코드는 자신이 디버거에 의해 동작되고 있다는 것을 알아내기 위한 방법으로 윈도우 API를 사용하는 방법과 디버깅하는 동안에 발견되는 특징을 찾기 위해 메모리 구조를 수동으로 검사하거나 디버거가 남기는 잔여물을 찾기 위해 시스템을 검색하는 등 다양한 기법을 사용한다. 디버거 탐지는 악성코드가 수행하는 안티디버깅 방법중 가장 일반적이다.

Using the Windows API

윈도우 API 함수 사용은 가장 명백한 안티 디버깅 기법이다. 윈도우 API는 프로그램 자신이 디버깅 중인지 확인할 수 있는 몇개의 함수를 제공한다. 이러한 함수 중 일부는 디버거 탐지를 위한 목적이지만, 다른 함수는 이와 다른 목적임에도 디버거를 탐지하는데 사용할 수 있다.

전형적으로 안티디버깅 API 함수 호출을 막기 위한 가장 쉬운방법은 실행중에 안티디버깅 API 함수들을 호출하지 않게 악성코드를 수동으로 조작하거나 올바른 경로를 취했는지 보장하기 위해 호출되는 플래그를 사전에 수정하는 방식이다. 다음과 같은 윈도우 API 함수들은 안티디버깅으로 사용할 수 있다.

· IsDebuggerPresent

디버거를 탐지하는 가장 간다한 API 함수는 IsDebuggerPresent다. 이 함수는 PEB 구조에서 IsDebugged 필드를 찾아 디버거 환경에서 동작 중이 아니라면 0을 반환하고, 디버거 환경에서 동작하고 있다면 0이 아닌 값을 반환한다.

*PEB는 FS 레지스터를 통해 접근이 가능하며 TEB의 0x30 이 PEB를 기리킨다. 따라서 FS:[0x30] 이라 되어있으면 PEB를 가리키고있다는 것이다.

· CheckRemoteDebuggerPresent

이 함수는 위의 함수와 거의 동일하며 이 함수 또한 PEB 구조에 있는 IsDebugged 필드를 확인하지만, 자기 자신이나 로컬 컴퓨터의 다른 프로세스에 대해서만 검사할 수 있다. 이 함수는 파라미터로 프로세스 핸들을 받아 프로세스가 디버거 환경에서 구동 여부를 확인한다. 단순히 CheckRemoteDebuggerPresent는 프로세스에 핸들을 저날해 프로세스를 확인하는데 사용한다.

· tQueryInformationProcess

이 함수는 주어진 프로세스에 관한 정보를 검색할 수 있는 Ntdll.dll 내의 네이티브 API 함수이다. 첫번째 파라미터는 프로세스 핸들이고, 두번째는 검색하고자 하는 프로세스 정보의 타입을 함수에 알려주는데 사용한다. 두번째 파라미터가 ProcessDebugPort(0x7)의 값이라면 첫번째 파라미터에 해당하는 프로세스가 지금 디버깅 중인지를 알려준다. 프로세스가 디버깅 중이 아니라면 0을 반환할 것이고, 그렇지 않다면 디버거 포트 번호를 반환할 것이다.

· OutputDebugString

이 함수는 디버거에 출력할 문자열을 전달하는데 사용되는데 이를 디버거의 존재를 탐지하기 위해 사용할 수 있다. 아래의 코드를 보면 SetLastError를 이용해 현재 에러코드를 임의의 값을 설정한다. OutputDebugString을 호출할때 디버거에 붙어있지 않아 실패할 경우 이 함수는 에러코드를 설정하므로 GetLastError 함수는 더 이상 임의의 값을 갖지 않는다. 하지만 디버거환경에서 OutputDebugString 함수를 호출하면 OuputDebugString 함수는 성공하고 GetLastError 함수 값은 변하지 않는다.

Manually Checking Structures

윈도우 API 사용이 디버거의 존재를 탐지하는 가장 명확한 방법이지만, 악성코드 제작자는 가장 일반적으로 구조체를 수동으로 검사하는 방식을 사용한다. 수동 검사를 수행함에 있어 PEB 구조체 안에 있는 일부 플래그에서 디버거의 존재에 관한 정보를 제공한다. 이에 대하여 알아보자.

· BeingDebugged 플래그 검사

아래의 그림과 같이 운영체제는 실행 중인 각 프로세스에 대해 윈도우 PEB 구조체를 관리한다. 프로세스와 관련한 모든 사용자 모드 파라미터를 갖고 있다. 이 파라미터는 환경 변수 값, 로드된 모듈 목록, 메모리 주소, 그리고 디버거 상태같은 프로세스의 환경 데이터를 포함한다.

프로세스 실행 중에 PEB 위치는 FS:[0x30]에서 참조할 수 있다. 악성코드는 안티디버깅을 수행하기 위해 특정 프로세스의 디버깅 여부를 알려주는 BeingDebugged 플래그 값을 확인하는 위치를 사용한다. 아래의 그림은 해당 검사를 수행하는 두가지 예이다.

좌측의 코드는 PEB 위치를 EAX 로 이동시키고 이 오프셋에 2를 더하여 EBX로 이동시키는데 바로 이 위치가 BeingDebugged 플래그 위치의 PEB 오프셋에 해당한다. 그 후 EBX가 0인지를 확인하는 것으로 EBX가 0이면, 즉 디버거가 동작하고 있지 않다면 디버거가 발견되지 않았음을 알고 NoDebuggerDetected로 이동한다. 우측의 코드는 push와 pop 명령어를 조합해 PEB 위치를 EDX로 이동한 후 EDX에서 오프셋 2에 있는 BeingDebugged 플래그를 1과 직접 비교한다. 

이 확인 과정은 다양한 형태를 취할 수 있지만, 궁극적으로 조건부 점프가 코드 경로를 결정한다. 이 문제를 해결하려면 다음과 같은 처리 방법 중 하나를 선택할 수 있다.

- 점프 명령어가 실행하기 직전에 ZF를 직접 수정해 점프를 취하거나 취하지 않게 강제한다.

- BeingDebugged 플래그를 직접 0으로 변경한다.

· ProcessHeap 플래그 검사

로더는 ProcessHeap으로 알려진 Reverse4 배열 내에 문서화하지 않은 위치를 할당된 프로세스의 첫번째 힙의 위치로 설정한다. ProcessHeap은 PEB 구조체의 0x18에 위치한다. 첫번째 힙은 디버거 내에서 힙의 생성 여부를 커널에게 알려주는 필드가 있는 헤더를 포함한다.

* 윈도우 버전에 따라 다른 오프셋에 위치할 수 있으며 값 또한 다르게 설정되어 있다.

이 기법을 극복하는 가장 좋은 방법은 ProcessHeap 플래그를 수동으로 변경하거나 사용하는 디버거의 플러그인을 사용하는 것이다.

· NTGlobalFlag 검사

프로세스를 디버거에서 시작할 때 약간 다르게 동작하므로 메모리 힙을 다르게 메모리 힙을 다르게 생성한다. 힙 구조체 생성을 결정할 때 사용하는 시스템 정보는 PEB의 0x68 오프셋에 있는 문서화하지 않은 위치에 저장된다. 이 위치의 값이 0x70 이라면 프로세스가 디버거에서 동작중이라는 사실을 알 수 있다.

0x70의 값은 디버거가 힙을 생성할 때 다음과 같은 플래그를 조합한다. 프로세스를 디버거 내에서 실행하면 프로세스는 이 플래그를 설정한다. 아래의 그림은 이 값을 확인하는 어셈블리 코드이다.

이 기법을 우회하는 가장 쉬운 방법은 수동으로 해당 플래그를 변경하거나 사용중인 디버거의 플러그인을 사용하는 방식이다.

Checking for System Residue

악성코드를 분석할 때 디버깅 도구를 사용하는데, 일반적으로 시스템에 흔적을 남긴다. 악성코드는 자신이 분석 중인지 여부를 확인하기 위해 디버거를 참조하는 레지스트리를 검색하는 방식으로 그 흔적을 찾을 수 있다. 아래 레지스트리 경로는 디버거가 사용하는 일반적인 위치다.

이 레지스트리 키는 애플리케이션에 에러가 발생할 때 활성화할 디버거를 지정한다. 기본적으로 Dr.Watson을 설정하지만 OllyDbg같은 디버거로 변경했다면 악성코드는 분석 중이라고 판단한다. 아래는 내 PC의 지정되어 있는 디버거가 vsjitdebugger.exe로 지정되어있는 것을 확인할 수가 있다.

악성코드를 분석하는 동안 악성코드는 일반적인 디버거 프로그램 실행 파일과 같은 시스템 파일과 폴더를 검색할 수도 있다. 또는 악성코드는 동작 중인 메모리에서 현재 프로세스 목록을 보거나 더 일반적으로 아래와 같이 FindWindow 함수를 통해 디버거 검색을 수행하는 등 흔적을 탐지한다.

Identifying Debugger Behavior

악성코드 분석가가 리버싱을 하기 위해 디버거는 BP를 설정하거나 프로세스를 단계별로 실행할 수 있다. 하지만 디버거에서 이런 작업을 수행할 때 프로세스 내의 코드를 수정한다. 일부 안티 디버깅 기법은 악성코드가 INT 스캐닝, 체크섬 검사, 시간 검사 같은 형태의 디버거 동작을 탐지하는데 사용한다.

INT Scanning

INT 3은 디버거가 사용하는 소프트웨어 인터럽트로 동작하는 프로그램 명령어를 INT 3로 임시 변경해 디버거 예외 핸들러를 호출하는데, 이는 BP를 설정하는 기본 메커니즘이다. INT 3의 OPCODE는 0xCC이다. 다시 말해 디버거를 이용해 브레이크 포인트를 설정할 때마다 디버거는 0xCC를 삽입함으로써 브레이크 포인트를 삽입해서 코드를 변경한다.

특정 INT 3 명령어뿐만 아니라 INT immediate는 3을 포함해 임의의 인터럽트를 설정할 수 있다. 1바이트인 INT 3과는 다르게 이는 0xCD 0xValue 와 같이 2바이트로 사용한다. 일반적인 안티 디버깅기법은 아래와 같이 0xCC 옵코드를 검색해서 자신의 코드를 INT 3으로 변경했는지 프로세스를 스캔하는 방식이다.

호출 명령어로 시작한 코드 다음 pop 명령어가 EIP를 EDI로 저장한다. 그러면 EDI는 다음 코드의 시작으로 조정된다. 그 코드는 0xCC 바이트를 검색한다. 0xCC 바이트를 발견하면 디버거가 존재한다는 사실을 알게된다. 이 기법은 소프트웨어 BP 대신 HardWare BP를 설정해 우회할 수 있다.

Performing Code Checksums

인터럽트 스캔과 동일한 목적으로 악성코드는 코드 섹션의 Checksum을 계산할 수 있다. 이는 0xCC를 검색하는 대신 간단히 순환 중복 검사(CRC)나 악성코드 OPCode MD5 체크섬을 계산한다. 이 기법 또한 하드웨어 BP를 설정해 우회하거나 디버거에서 실행 경로를 수동으로 변경해 우회할 수 있다. 아래의 사진은 ADD를 통하여 명령어들의 OPcode의 합을 계산하여 CMP를 통해 비교 후 분기 하는 것을 확인할 수가 있다.

Timing Checks

프로세스를 디버깅할 때는 그렇지 않을 때보다 훨씬 느려지기 때문에 timeing checks 방식은 악성코드가 디버거를 탐지할 때 사용하는 가장 대중적인 방법 중 하나다. 디버거 탐지에 사용하는 시간 검사에는 다음과 같은 몇가지 방식이 있다.

- 몇가지 동작 수행에 대해 타임스탬프를 기록한 후 다른 타임스탬프를 가져와 두개의 타임스탬프를 비교한다. 지연차가 있다면 디버거가 존재한다고 가정할 수 있다.

- 예외가 발생하기 전후의 타임스탬프를 가져온다. 프로세스가 디버그 중이 아니라면 신속하게 예외를 처리하지만, 디버거가 예외를 처리하는 경우 훨씬 느려질 것이다. 기본적으로 대다수 디버거는 예외 처리에 사람이 개입하게 해서 상당한 지연을 발생시킨다. 많은 디버거는 이를 위해 예외를 무시하거나 그냥 지나치게할 수 있는 기능을 제공하지만 이런 경우에도 꽤 긴 지연이 발생한다.

· rdtsc 명령어 사용

가장 일반적인 시간 검사 방법은 rdtsc 명령어(OPCode:0x0F31)를 사용한다. rdtsc 명령어는 가장 최근에 시스템이 리부팅한 이후 흐른 시간 값을 저장한 64 비트를 반환한다. 악성코드는 간단히 이 명령어를 두 번 실행하고 두 값을 비교한다.

위의 그림을 보면 rdtsc를 호출하여 값을 ecx에 저장하고 다시 한번 호출하여 두 값을 비교하는 것을 볼 수가 있다. 만약 그 값의 차가 크지 않을 경우 디버거에게 탐지되지 않았을 때의 명령어를 수행하게 되며 만약 값의 차가 특정한 정도를 넘으면 다시 한번 rdtsc를 호출하여 이 임의의 주소로 ret하게 되는 것을 확인할 수가 있다.

· QueryPerformanceCounter와 GetTickCount 사용

두개의 윈도우 API 함수는 rdtsc와 같이 시간차를 통해 안티디버깅을 수행한다. QueryPerformanceCounter는 비교에 사용할 시간차를 가져올 때 카운터 질의를 두번 호출 한다. 두 호출 사이의 시간차가 너무 크다면 디버거를 사용중이라고 할 수 있다. GetTickCount 함수는 마지막으로 시스템을 재부팅한 이후 경과 시간을 밀리초 단위의 숫자로 반환한다. 아래는 GetTickCounter의 사용 방식이다.

앞서 언급한 모든 시간차 공격은 디버깅 중이나 함수를 두번 연속 호출한 후 비교하는 형태를 식별해서 정적 분석하는 도중에 발견할 수가 있다. 이 방식은 시간차 확인에 사용한 두 호출 중간에 BP를 설정하거나 단계별로 실행했을 때만 디버거에서 찾아낼 수 있다. 그러므로 시간차 탐지를 회피할 수 있는 가장 쉬운 방법은 이런 확인을 그냥 실행한 후 BP를 설정하고 다시 단계별로 디버깅한다.

Interfering with Debugger Functionality

악성코드는 일반 디버거 동작을 방해하는 TLS Callback, 예외 처리, 인터럽트 삽입 같은 여러가지 기법을 사용할 수가 있다. 이 기법은 디버거 통제하에서 프로그램 실행 무력화를 시도하는 방식으로 진행이 된다.

Using TLS Callback

일반적으로 대다수 디버거는 PE 헤더에서 정의한 프로그램 진입점에서 시작한다. 그러나 TLS(Thread Local Storage) CallBack은 진입점에서 실행하기 전에 코드를 실행할 때 사용할 수 있으므로 디버거 몰래 실행할 수 있다. 결국 디버거 사용에만 의존한다면 디버거 내에서 로드하자마자 TLS callback을 실행하므로 악성코드 기능을 놓칠 수 있다.

TLS는 데이터 객체가 자동 스택 변수가 아닌 윈도우 저장 클래스지만, 코드를 실행하는 각 스레드는 지역변수다. 기본적으로 TLS를 통해 각 스레드가 선언한 변수에 다른 값을 유지할 수 있다. 실행 파일에서 TLS를 구현할 때 일반적으로 아래의 그림과 같이 .tls 섹션에 위치해 있는 것을 확인할 수 있다. 윈도우는 정상적인 프로그램 코드 실행 전에 TLS CallBack 함수를 실행한다.

일반적인 프로그램들은 .tls 섹션을 사용하지 않기 때문에 .tls 섹션을 발견할 경우 가장 먼저 안티디버깅을 의심해야 한다. 위회의 방법으로는 OllyDbg의 경우 디버깅 옵션에서 Event 항목을 보면 Make first pause at: 이 존재하는 것을 확인할 수가 있다. 여기서 우린 System breakpoint로 설정을 해주면 TLS Callback이 실행되지 않고 그 전에 멈추므로 분석이 가능해진다.

Using Exceptions

예외 처리는 디버거를 방해하거나 탐지하는데 사용할 수 있다. 대다수 예외 기반 탐지 방식은 디버거가 예외 상황 발생후의 처리를 위해 디버깅중인 프로세스에게 즉각적으로 전달하지 못한다는 사실에 기반을 둔다. 대부분 디버거의 기본설정은 예외를 처리하기 위해 예외를 프로그램에 전달하지 않게 설정한다. 디버거가 즉각적으로 프로세스에게 예외를 전달하지 않는다면 프로세스 예외 처리 메커니즘이 해당 오류를 탐지할 수 있다. 

* SEH는 FS : [0x0]에서 참고한다.

Inserting Interrupts

안티디버깅의 전형적인 형태는 예외를 발생시켜 분석가를 귀찮게 하거나 유효한 명령어 중간에 인터럽트를 삽입해서 정상적인 프로그램 실행을 방해한다. 디버거 설정에 따라 다르겠지만, 인터럽트 삽입은 디버거가 자체적인 소프트웨어 BP 설정과 동일한 메커니즘이기 때문에 이를 통해 디버거를 중단시킬 수 있다.

· INT 3 삽입

디버거는 INT 3을 이용해 소프트웨어 BP를 설정하므로 디버거가 해당 OPcode를 BP라 생각하게 유효한 코드 섹션에 0xCC OPcoe를 삽입하는 방식으로 안티디버깅을 구성한다. 2 바이트 옵코드 0xCD03 시퀀스 또한 INT 3 생성에 사용한다. 이는 WinDBG를 방해할 목적으로 악성코드가 자주 사용하는 유효한 방식이다. 디버거 외부에서 0xCD03은 STATUS_BREAKPOINT 예외를 발생시킨다. 그러나 WinDBG 내부에서 일반적으로 BP는 OPcode가 0xCC이므로 BP가 걸리면 그냥 EIP를 정확히 1바이트 증가시킨다. 이는 WinDG로 프로그램을 디버깅 중일때와 정상적으로 실행할 때 서로 다른 명령어 집합을 실행하게 한다.

· INT 2D 삽입

INT 2D 안티 디버깅 기법은 INT 3과 동일한 기능을 하며, INT 0x2D 명령어는 커널 디버거 접근에 사용한다. INT 0x2D는 커널 디버거가 BP를 설정하는 방식이다.

· ICE 삽입

Intel에서 문서화하지 않은 명령어 중 하나로 ICE(In-Circuit Emulator) BP인 icebp(OPcode:0xF1)가 있다. ICE를 이용해 임의의 BP를 설정하는 것이 어렵기 때문에 ICE에서 디버깅이 용이하게 icebp를 설계했다. icebp 명령어를 실행하면 싱글 스텝 예외가 발생한다. 싱글 스텝을 통해 프로그램을 추적하는 경우 디버거는 싱글 스텝이 생성한 일반적인 예외라고 여기고 이전에 설정한 예외처리를 실행하지 않는다. 악성코드는 정상적인 실행 흐름을 위해 예외 핸들러를 이용해서 이를 악용할 수 있는데, 이 경우 문제가 발생할 수 있다. 이런 기법을 우회하려면 icebp 명령어 실행 시 싱글 스텝을 사용하지 않으면 된다.

Debugger Vulnerabilities

모든 소프트웨어와 같이 디버거 자체에도 취약점을 갖고 있으므로 때때로 악성코드 제작자는 디버깅을 방지할 목적으로 이 취약점을 공격한다. OllyDbg가 PE 포맷을 처리하는 방식에서 잘 알려진 일부 취약점을 소개한다.

PE 헤더 취약점

이 기법은 OllyDBG가 실행 파일을 로드할 때 크래시되게 MS의 실행 가능 바이너리의 PE 헤더를 변조하는 방식이다. 이는 Ollydbg가 PE 헤더와 관련된 사항을 지나치게 엄격하게 따르는데 있다. IMAGE_OPTIONAL_HEADER로 알려진 전형적인 구조가 있다. 아래의 그림을 보자.

이 구조체에서 마지막 일부 요소를 주목해보자. NumberOfRvaAndSizes 필드는 바로 뒤따라오는 DataDirectory 배열의 Entry 개수를 나타낸다. DataDirectory 배열은 파일에서 다른 중요한 실행 요소를 찾기 위한 장소를 가리키고 있다. 하지만 위의 그림에선 이 수를 0x99로 설정하므로 존재하는 16개의 수를 넘는다. OllyDBG는 표준을 따르고 있기 떄문에 반드시 NumberOfRcaAndSizes를 사용한다. 결론적으로 0x99와 같이 0x10 보다 많은 값으로 배열의 크기를 설정했다면 OllyDBG는 실행전에 사용자에게 팝업 윈도우를 생성한다.

이 기법을 가장 쉽게 우회하는 방법은 해당 값을 수정하거나 OllyDBG 2.0 을 사용하는 것이다. 위의 취약점은 ollydbg 1.0에 해당하는 것이다.

섹션 헤더에 관련된 또 다른 PE 헤더 문제점은 OllyDbg가 로드하는 동안 'File contains too much data' 라는 에러와 함께 크래시된다. 각 섹션에는 코드, 데이터, 리소스와 기타 파일 정보가 담겨있다. 각 섹션은 IMAGE_SECTION_HEADER 구조체 형식으로 헤더를 갖고 있다. 위 그림이 이 구조체의 일부이다.

VirtualSize와 SizeOfRawData에 주목하자. 윈도우 로더는 메모리 내의 섹션 데이터를 매핑시키기 위해 더 작은 VirtualSize와 SizeOfRawData를 사용한다. SizeOfRawData가 VirtualSize보다 크다면 VirtualSize 데이터를 메모리에 복사하지만 나머지는 무시한다. 여기서 OllyDBG는 SizeOfRawData만을 사용하기 때문에 SizeOfRawData를 0x77777777처럼 큰 값으로 설정하면 OllyDbg가 크래시된다.

이러한 안티디버깅 기법을 우회하는 가장 손쉬운 방법은 수동으로 PE 헤더를 수정하거나 16진수 데이터를 사용해서 SizeOfRawData를 VirtualSize에 가까운 값으로 변경한다.

Conclusion

대중적인 안티디버깅 기법을 보았으며 이러한 기법을 익히고 인지해서 우회하기까지 인내가 필요하다. 대다수 안티디버깅 기법은 프로세스를 천천히 디버깅하는 과정 중에 상식선에서 발견할 수 있다. 대다수 대중적인 안티디버깅 기법은 FS:[0x30]에 접근해 윈도우 API를 호출하거나 시간을 검사하는 기법을 자주 사용한다.

물론 모든 악성코드 분석과 마찬가지로 안티디버깅 기법을 무산시키는 가장 좋은 방법은 계속해서 악성코드를 공부하고 역공학해보는 것이다.

요약

IsDebuggerPresent FS:[30] + 2    CheckRemoteDebuggerPresent FS:[30]+2    tQueryInformationProcess     OutputDebugString    FindWindow

FS:[30]+2    FS:[30]+18    FS:[30]+68

INT3 : 0xCC    0xCD    Checksum    rdtsc    QueryPerformanceCouter    GetTickCount    TLS    SEH : FS:[0]

INT 3    INT 2D    ICE