Practical Malware Analysis 14-1
실습 14-1
실습 환경 : Vmware (Windows 7 32 bit)
사용한 툴 : IDA Free, ApateDNS, NC
ApateDNS를 사용하여 127.0.0.1로 서버를 실행한 뒤 nc를 이용해서 80번 포트로 리스닝하게 설정하고 악성코드를 동적으로 실행해 보면 아래와 같이 확인할 수 있다.
인터넷 익스플로러를 이용해 테스트를 해보니 위 비컨에서 확인한 User-Agnet와 일치하는 것을 확인할 수 있다.
이를 통해 User-Agent가 하드 코딩 되어있지 않은 것으로 생각할 수 있다.
이제 IDA Free를 사용하여 분석을 진행하보면
임포트 함수에서 URLDownloadToCacheFileA 함수를 찾을 수 있는데 이 함수가 비컨으로 사용되는 것으로 보이고 COM API를 사용하는 것을 확인할 수 있다.
URLDownloadToCacheFileA 함수가 유일하게 사용된 네트워크 함수로 보이므로 이 함수가 참조하는 0x004011A3 위치의 함수를 분석해보면
http://www.practicalmalwareanlysis.com/%s/%c.png를 sprintf 함수의 호출에 사용하고 그 결과를 URLDownloadToCacheFileA 함수의 파라미터로 사용하는 것을 볼 수 있다.
%s와 %c에 입력 값을 추척해보면
함수 입력 값을 eax로 옮기고 strlen의 파라미터로 줘서 입력 값의 길이를 구한다. 그리고 구한 입력 값의 길이값을 var_218에 저장한 뒤 ecx에 입력 값을 저장하고 길이를 더해 문자열의 끝을 가리킨다. 그 뒤 dl에 문자열의 마지막 문자를 저장하고 dl을 var_214로 옮기고 다시 eax로 옮기고 push하는데 이 값이 %c의 인자이다. 그 후 ecx에 입력 값을 저장하고 push하는데 이 값이 %s의 인자이다.
즉 %c는 입력 값의 마지막 문자이고 %s는 입력 한 값임을 알 수 잇다. 이를통해 위에서 확인했던 비컨의 url 파일명이 a.png인 이유를 알 수 있다.
이제 어떤한 값이 입력되는지 호출 함수를 살펴보면
sub_4010BB라는 이름의 함수를 볼 수 있는데 이 함수가 0x004011A3함수로 전달하는 문자열을 수정하는 것으로 보인다.
sub_4010BB 함수를 살펴보면
strlen과 sub_401000 두 개의 서브루틴을 갖고 있음을 알 수 있는데 sub_401000을 분석해보면
표준 base64 문자열 참조 값을 가지고 있는 것을 확인할 수 있지만 이는 표준 base64 인코딩 함수가 아니다. 왜냐하면 표준 base64 함수는 전형적으로 마지막 4바이트 블록의 문자 패딩에 필요할 경우 두 문자를 패딩할 수 있게 두개의 =를 참조하는데 위에서 살펴보면 패딩 문자로 일반적인 =이 아닌 a를 할당하는 것으로 보인다.
이제 메인 함수로 돌아가 분석을 진행해보면
base64 인코딩 함수 전에 GetCurrentHwProfileA, GetUserName, sprintf함수와 문자열 들을 볼 수 있는데 이를 살펴보면 GetCurrentHwProfileA 함수가 반환한 GUID 여섯 바이트를 MAC주소 형식으로 출력하고 이 값은 %s-%s에서 첫 번째 문자열이 된다. GetUserName 함수를 사용하여 가져온 username은 %s-%s의 두 번째 값이 되니 이를 통해 문자열을 나타내보면 HH:HH:HH:HH:HH:HH-username이 된다.
이제 위에서 확인해 봤던 비컨의 url값을 base64로 디코딩을 해보면
위에서 확인했던 형식의 값임을 확인할 수 있다.
이제 다시 URLDownloadToCacheFileA 함수로 돌아가서 살펴보면
함수가 성공했을 때 URLDownloadToCacheFileA 함수가 반환한 경로명 하나를 인자로 받는 CreateProcessA 함수를 확인할 수 있다. 이를통해 악성코드가 파일을 다운로드하고 파일을 실행한 후 종료하는 것을 알 수 있다.
이제 네트워크 시그니처를 작성해 보면 시그니처 분석 대상이 되는 주요 정적 요소는 하드웨어 프로파일 바이트와 사용자명 사이에 있는 패딩을 제공하는 콜론과 대시다. 근데 악성코드가 네트워크상에서 이 콘텐츠를 전송하기 전에 base64 인코딩을 적용하기 때문에 이를 대상으로 하기는 어렵다. 대상 패턴과 문자열이 변환되는 방식을 나타내보면
| 원본 | 80: | 6e: | 6f: | 6e: | 69: | 63- | use | r.. |
| 인코딩 | QDA6 | NmU6 | NmY6 | NmU6 | NjK6 | NjMt | dXNl | cgaa |
이런 형식으로 되어있는 것을 확인할 수 있는데 원본 문자에서 각 콜론은 세 문자 중에서 세 번째 문자이고 base64로 인코딩 할 때 네 문자의 네 번째 문자에 있는 모든 비트는 세 번째 문자에서 나온다. 그래서 콜론으로 끝나는 문자 네 번째는 항상 6이 되고 대시를 사용한 여섯 번째는 항상 t로 끝난다. 따라서 URI는 네 개의 6 문자열과 t로 구성한 특성 위치와 함께 항상 최소 24문자인 것을 알 수 있다. 그리고 다운로드명은 경로의 마지막과 동일한 하나의 문자라는 것도 위에서 확인하였다.
이는 두 가지 정규 표현식으로 나타낼 수 있는데 첫 번째 정규 표현식으로 나타내보면
/\/[A-Z0-9a-z+\/]{3}6[A-Z0-9a-z+\/]{3}6[A-Z0-9a-z+\/]{3}6[A-Z0-9a-z+\/]{3}6[A-Z0-9a-z+\/]{3}6[A-Z0-9a-z+\/]{3}t([A-Z0-9a-z+\/]{4}){1,}\//
이 되고 두 번째 정규 표현식은 적어도 25개의 문자열의 base64 표현식을 대상으로 한다. 나타내보면
/\/[A-Z0-9a-z+\/]{24,}([A-Z0-9a-z+\/])\/\1.png/
이 되는데 이 표현식에서 \1은 괄호 사이에서 캡처한 첫 번째 요소를 의미하는데, / 이전 문자열에서 마지막 base64 문자다.
이제 두 정규 표현식으로 네트워크 상에서 트래픽을 생성할 때 악성코드를 탐지하는 스노트 시그니처로 변환해보면 첫 번째는 다음과 같다.
| alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”PM14.1.1 Colons and dash”; urilen:>32; content:”GET | 20 | /”; depth:5; pcre:”/GET\x20\/[A-Z0-9a-z+\/]{3}6[A-Z0-9a-z+\/]{3}6[A-Z0-9a-z+\/]{3}6[A-Z0-9a-z+\/]{3}6[A-Z0-9a-z+\/]{3}6[A-Z0-9a-z+\/]{3}t([A-Z0-9a-z+\/]{4}){1,}\//”; sid:20001411; rev:1;) |
이를 살펴보면 urilen 키워드로 URI의 특정 길이를 보장하는데 여기서는 32 문자보다 커야 한다.
두 번째 시그니처를 이용한 스토느 규칙은
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”PM14.1.2 base64 and png”; urilen:>32; uricontent:”.png”; pcre:”/\/[A-Z0-9a-z+\/]{24,}([A-Z0-9a-z+\/])\/\1.png/”; sid:20001412; rev:1;)
이 스노트 규칙은 패킷 처리 성능을 향상시키기 위해 PCRE 정규 표현식 테스트 이전에 정규 표현식 내의 .png 내용을 검색한다. URI 길이 확인도 추가하는데, 알려진 최솟값이다.
위의 시그니처와 스노트 툴 작성은 책을 토대로 공부하면서 작성하였습니다.
[01] 악성코드가 사용하는 네트워킹 라이브러리는 무엇이며, 어떤 이점을 갖고 있는가?
URLDownloadToCacheFile 함수를 사용하는 것으로 보아 COM 인터페이스를 사용하는 것으로 보인다. 악성코드가 COM 인터페이스를 사용할 때 대다수 HTTP 요청 콘텐츠는 윈도우 내부에서 오는 것이므로 네트워크 시그니처를 이용해서 효과적으로 대상을 알 수 없다.
[02] 네트워킹 신호 발신(beacon)을 위해 사용되는 기반(source) 요소는 무엇이며, 어떤 조건이 신호 발신에 변화를 가져오는가?
기반 요소는 호스트의 GUID와 사용자명의 일부다. GUID는 개별 호스트 운영체제에 유일한 값이므로 비컨 메시지에 사용한 6바이트는 상대적으로 유일하다. 사용자 명은 시스템에 로그인한 사용자에 따라 변한다.
[03] 네트워킹 신호 발신에 삽입된 정보가 왜 공격자에게 흥미로운가?
공격자는 다운로더가 동작하는 특정 호스트를 추적하여 특정 사용자를 대상으로 하는 것 같다.
[04] 악성코드가 표준 base64 인코딩을 사용하는가? 그렇지 않다면 어떻게 인코딩을 수행하는가?
base64 인코딩은 패딩에 =를 사용하지만 여기서는 a를 사용하므로 표준이 아니다.
[05] 이 악성코드의 근본적 목적은 무엇인가?
다른 코드를 다운로드하고 실행한다.
[06] 악성코드에서 통신의 어떤 요소가 네트워크 시그니처로 사용돼 효율적인 탐지를 할 수 있는가?
위에서 확인한 도메인 명과 base64 디코딩 했을때 확인할 수 있는 콜론과 대시 그리고 base64 인코딩 된 URI 마지막 문자가 png 파일의 파일명으로 사용되는 것
[07] 어떤 실수가 분석가가 이 악성코드의 시그니처를 만들 수 있게 하는가?
방어자 입장에서는 운영체제가 요소를 결정한다는 사실을 모른다면 URI가 아닌 요소를 대상으로 할 것이다. 위에서 살펴보면 base64 문자열이 a로 끝나는데 이는 파일 명이 a.png로 보이게 한다. 하지만 사용자명의 길이가 3의 배수라면 마지막 문자와 파일명은 인코딩한 사용자명의 마지막 문자에 의존한다. 이런 경우 파일명은 추측할 수 없다.
[08] 어떤 집합의 시그니처가 이 악성코드(그리고 이후 변종)를 탐지할 수 있는가?
시그니처는 위에서 살펴봤으니 위를 참조하면 된다.
이번 장에서 악성코드 기반 네트워크 시그니처에 대하여 공부하였다. 아직 실력이 부족하여 직접 시그니처 작성과 스노트 툴 작성은 책을 참고하여 공부하면서 작성해 봤다.