CreateMutex
까보면 다나와~
33ddos (1)

3.3 DDOS

 
간만에 포스팅을 해본다. 3월 3일 최초 발견되어 이슈가 되었던 DDOS 악성코드를 분석해보았다.

흐름도


악성코드가 동작하는 큰 흐름은 위의 그림과 같다. 공격시간을 체크하고 도메인을 확인한 후 해당 도메인으로 공격시간에 맞추어 DDOS를 감행하는 로직이다. 7.7 DDOS와 대동소이하다고 할 수 있겠다.

특징위주로 분석을 해보자면 다음과 같다. 참고용으로 봐주면 좋겠다.



1) tlntwye.dat 파일의 로드

그림 1. tlntwye.dat의 바이너리


앞서 언급한 바와 같이 tlntwye.dat 파일은 특정 시간(이하 공격시간)이 바이너리 형태로 저장되어 있다. 이는 FPU 레지스터(실수 표현을 위해 사용되는 레지스터)에 사용되는 값으로, GetSystemTime API로 얻어진 현재 시간(국제표준시)을 SystemTimeToVariantTime API의 인자로 넣어 얻어진 값과 비교된다.

그림 2. 공격시간(tlntwye.dat의 바이너리)과 현재시간의 비교


현재시간의 년도를 2011로 고정하고 공격시간 보다 작으면 대기, 크거나 같으면 tlntwye.dat 파일을 삭제 한다. 공격시간이 담긴 파일은 이후 사용되지 않기 때문에 삭제하여 추적을 회피하려 했음을 알 수 있다.

그림 3. 공격시간까지 1분 단위 재비교


 



2) tljoqgv.dat 파일의 로드

공격시간이 되면 도메인 정보를 포함한 tljoqgv.dat 파일을 메모리에 로드한다. 하지만 내부 스트링을 확인하면 난독화가 되어 있어 내용을 확인 할 수 없고 일정 루틴을 따라 복호화를 진행 해야만 한다.

그림 4. dat 파일 복호화 전/후


실제 복호화가 시작되는 부분은 dat + 8 offset 부터이고 16byte씩 size 만큼 복호화 하도록 되어 있다.

그림 5. 16byte 씩 size만큼 복호화

 



3) IP 주소 및 개수 저장

dat가 복호화되면 도메인 list 정보를 바탕으로 DNS Query를 날려 IP 주소 및 필요한 정보를 메모리에 저장한다.

그림 6. IP 정보 저장 코드


위의 그림은 복호화된 메모리 영역에 미리 저장된 Offset 마다 필요한 정보를 저장하는 부분을 나타낸 것이다.
gethostbyname 함수를 이용하여 얻어짂 IP 개수와 값들을 저장한다.

그림 7. 일정 Offset에 IP 정보 저장


도메인이 있는 메모리 주소 + 161 offset에 반환된 IP 값들을 저장
도메인이 있는 메모리 주소 + 289 offset에 반환된 IP들의 총 개수를 저장

최초 도메인이 있는 메모리 주소의 + 302 offset 부분에 다음 도메인이 고정적으로 존재하고 그사이 특정 Offset에 공격에 필요한 정보를 저장한다.




4) 공격 Thread 생성

대부분의 DDOS 악성코드가 그렇듯 이번 악성코드도 다수의 스레드를 생성하여 대량의 패킷을 발송하도록 제작되었다. 생성되는 구조를 살펴보면 아래 그림과 같이 특정 조건대로 만들어 진다.

그림 8. Thread 생성 로직


* 도메인 확인 -> 지정된 값만큼 스레드 생성 -> 다음 도메인 확인 -> 지정된 값만큼 스레드 생성 -> (반복)

코드대로 풀어서 설명하자면, 최초 도메인이 있는 주소를 확인하고 + 298 offset 만큼 떨어짂 지점의 값을 확인한다. 해당 값은 스레드를 생성하는 값이 저장되어 있으며, 그 만큼 CreateThread 함수를 호출한다. 해당 값만큼 CreateThread를 완료하면 다음 + 302 offset 주소(다음 도메인이 있는 주소)를 따라 다시 + 298 offset 만큼 떨어짂 지점의 값 확인 후 CreateThread를 반복하게 된다.

모든 도메인에 대하여 스레드 생성을 완료하면 Sleep 함수로 5분 만큼 대기 후 다시 도메인 파일(tljoqgv.dat)을 읽어오는 루틴으로 돌아갂다. 이는 도메인 파일이 변경될 수 있음을 알 수 있다.

다음은 바이너리에서의 값이 표시된 모습과 도메인 별 지정된 값을 정리한 것이다.

그림 9. +298 offset에 지정된 값


 * 지정된 스레드 개수(화살표는 2차, 없는 것은 도메인 삭제)




5) 공격 Thread 패킷 발송

스레드가 한 개의 IP에 발송하는 패킷은 UDP*1, ICMP*1, HTTP*5로 총 7개이다. IP가 20개 이면 20*7이다.

그림 10. Thread가 발송하는 패킷


생성되는 로직을 좀 더 자세히 살펴 보면 다음과 같다.

그림 11. UDP, ICMP 패킷 발송 코드


+289 offset에 저장된 IP 개수를 확인하여 해당 IP 별로 순차적으로 UDP, ICMP, HTTP 패킷을 보내도록 되어있다.
UDP와 ICMP 패킷 발송 젂에 +296, +297 값을 확인하는데, 각각의 값은 실행여부를 확인하는 플레그 값이고
모든 같은 offset의 위치에서 01로 셋팅되어, 결과적으로 항상 작동 되도록 되어 있다.

* 참고로 UDP, ICMP, HTTP 프로토콜을 만드는 API는 socket()으로, 해당 API의 파라미터 값에 따라 설정된다.

그림 12. HTTP 공격과 반복


HTTP 패킷은 좀 더 복잡한 구조로 만들어진다. 공격자는 다음과 같이 미리 스트링을 준비하고 %s로 인자를 받아서 공격 패킷을 조합한다.

GET %s HTTP/1.1..
Accept: %s..
Accept-Language: ko..
User-Agent: %s..
Accept-Encoding: gzip, deflate..%s
Proxy-Connection: Keep-Alive..
Host: ww*.%s.....*/*.
Cache-Control: no-store, must-revalidate.


첫 번째 %s는 고정적으로 “/”이다.
두 번째와 세 번째 %s는 아래 그림과 같이 몇 가지 case를 만들어 랜덤하게 들어갂다.
네 번째는 값이 없고, 다섯 번째는 도메인 스트링이다.

다음은 랜덤하게 들어가는 두 번째와 세 번째 값들에 대해 알아본 것이다.

그림 13. “User-Agent”와 “Accept”를 구성하는 로직


각각의 case string을 확인해 보면 다음과 같다.

 

User-Agent string

Mozilla/5.0 (X11; U; Linux i686; ko-KR; rv:1.9.0.4) Gecko/2008111217 Fedora/3.0.4-1.fc10 Firefox/3.0.4.

Mozilla/5.0 (Windows; U; Windows NT 5.1; ko; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8.

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1).

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0).

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0).

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.2).

 

Accept string

*/*.

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8.

image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*.

image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, */*.

image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*.

 

그림 14. 조합된 패킷



6) Thread 종료

7.7 DDOS의 경우 종료 시간까지 명시되어 있지만 이번 3.3 DDOS의 경우 종료를 하지 않고 앞서 확인한 바와 같이 5분 마다 지정된 만큼 스레드를 만들어 공격을 더욱 가중시킨다.

종합해서 정리하면,

① 도메인 dat 파일 확인
② 스레드를 도메인 별로 지정된 만큼 생성
③ 도메인으로 IP 검색
④ IP별로 UDP, ICMP, HTTP(Get flood & CC Attack) 패킷 발송
⑤ 5분 마다 다시 도메인 dat 파일 확인
⑥ DDOS 스레드 생성 및 공격

이후 다른 파일에 의한 disk 파괴

'악성코드 상세분석 > DDOS' 카테고리의 다른 글

3.3 DDOS  (0) 2011.03.22
  Comments,   0  Trackbacks
댓글 쓰기