포스팅 내용

악성코드 분석 리포트

[악성코드 분석 리포트] Spyware.PWS.KRBanker.M

Spyware.PWS.KRBanker.M


최근 사이버 공격 동향을 살펴보면 다양한 종류의 공격이 행해지고 있습니다. 

 

국가간의 사이버 전쟁, 산업시설 공격, 온라인게임 계정 탈취, 금융 정보 탈취, 랜섬웨어 등이 그것인데요. 그 중에서도 금전적인 목적을 위하여 사이버 공격을 시도하는 것은 이미 수년 전부터 행해져 왔었으며, 현재도 매우 활발히 진행 중에 있습니다. 대표적으로 운영체제의 호스트 파일을 변조하여, 공격자가 미리 제작해 둔 가짜 사이트로 유도 후 개인정보를 탈취하는 방식, 파밍(Pharming)이라는 수법을 들 수 있겠습니다.


최근에는 이러한 파밍 기법도 진화하고 있습니다. 기본적인 방법은 운영체제의 DNS캐쉬를 초기화 시키고 호스트 파일을 변조하여 공격자가 미리 제작해 둔 사이트로 사용자를 유도하는 것입니다. 그러나 호스트 파일은 안티 바이러스 소프트웨어에서 그것의 변조 여부를 확인하기 때문에 공격자는 호스트 파일을 변조하지 않고도 파밍 공격을 수행할 수 있는 방법을 찾기 시작했습니다.


해당 악성코드는 스스로 DNS서버의 역할을 수행하도록 설계되었습니다. 지금까지 파밍 공격 방법들이었던 Winsock LSP, 운영체제 호스트파일 조작과는 다른 방법입니다. 따라서 새로운 파밍 공격법에 대해서 이해하고, 이에 대한 대비가 필요할 것입니다.




악성코드 상세 분석

 

※ 악성파일 분석(syotom.exe)


- 자동실행 레지스트리 등록 및 파일 복사


처음에 파일 이름이 syotom.exe인지 확인하는 검사를 진행합니다. 파일 이름이 다를 경우, 윈도우 디렉토리로 syotom.exe라는 이름으로 복사 후 레지스트리 시작 프로그램 경로에 등록하고 실행시킨 뒤 종료됩니다.


[그림 1] 파일 이름이 syotom.exe인지 검사


아래의 레지스트리 경로에 syotom 이라는 이름으로 등록되며, 윈도우가 시작될 때마다 악성코드가 자동으로 실행됩니다.


[그림 2] 시작 프로그램 등록된 악성코드


최종적으로 악성코드가 파일 복사 및 레지스트리 등록을 하는 내용을 정리해 보면 아래와 같습니다.


악성코드가 복사되는 경로 

시작 프로그램 레지스트리 경로 

[윈도우 경로]

\syotom.exe

[경로]

HKEY_LOCAL_MACHINE\Software\Microsft\Windows\CurrentVersion\Run

[값]

syotom = [윈도우 경로]\syotom.exe



- 중복 실행 방지


중복 실행을 막기 위해서 뮤텍스를 사용합니다. 일반적으로 많이 사용하는 방법인 ERROR_ALREADY_EXISTS 값을 체크하는 것이 아닌, WaitForSingleObject의 반환값이 WAIT_TIMEOUT이면 프로그램을 종료하는 것으로 이어집니다. 

 

이것이 가능한 이유는 최초에 실행된 악성코드가 뮤텍스 생성 후에 WaitForSingleObject를 통해서 획득해 버리면 이후부터 실행되는 악성코드는 CreateMutex의 반환값이 이미 처음에 생성해 둔 뮤텍스의 핸들을 받게 되기 때문입니다. 이것은 이미 최초에 획득 된 상태이기 때문에 WaitForSingleObject에서 WAIT_TIMEOUT을 리턴할 수 밖에 없습니다. 따라서 이미 실행 중이라고 간주할 수 있습니다.


[그림 3] 중복실행을 방지하는 부분



- 파밍 작업 : 윈도우 방화벽 우회


자기 자신을 방화벽의 예외 룰에 추가하여, 방화벽을 피해 정상적인 동작이 가능하도록 합니다. 아래는 윈도우 방화벽의 예외 룰에 자기 자신을 추가하기 위해서 작동하는 부분입니다. INetFwServices COM 인터페이스를 사용합니다.


[그림 4] 윈도우 방화벽에 예외 룰을 추가하는 부분


결과적으로 아래와 같이 방화벽 예외 룰이 추가되고, 이로써 악성코드는 아무런 방해 없이 동작할 수 있습니다.


[그림 5] 윈도우 방화벽 예외 룰이 추가된 모습



- 파밍 작업 : 네트워크 어댑터 DNS주소 변경


현재 인터넷 연결 중인 네트워크 어댑터의 DNS서버 설정을 변경합니다. 이를 위해서 MSScriptControl COM 인터페이스를 불러와서 사용합니다.


[그림 6] VB스크립트를 이용해서 DNS주소 변경을 시도하는 부분


위 그림에서 v8변수는 암호화 된 문자열을 가리키는데, 해당 부분을 복호화 하게 되면 아래와 같이 Visual Basic 스크립트 코드가 나타나게 됩니다.


[그림 7] 현재 사용중인 네트워크 어댑터의 DNS주소를 변경하는 Visual Basic 스크립트


기본 DNS서버의 주소를 127.0.0.1로 설정하고 보조 DNS서버의 주소를 8.8.8.8로 설정합니다. 127.0.0.1은 localhost이고 8.8.8.8은 구글(Google)의 DNS서버 주소입니다. 기본 DNS주소를 localhost로 한 것으로 봐서 감염PC에서 DNS서버의 역할을 수행하는 무엇인가 있을 것이라고 추측해 볼 수 있습니다.


VB스크립트 실행 이후에는 아래와 같이 DNS주소 정보가 변경됩니다.


[그림 8] DNS서버 주소가 변경된 모습



- 파밍 작업 : DNS캐시 초기화


시스템에 존재하는 DNS캐시 정보를 초기화합니다. DNS캐시 정보를 초기화 하는 이유는, 이미 존재하는 DNS캐시로 인해서 공격자가 의도하지 않는 동작이 발생해서 파밍이 제대로 이루어지지 않을 가능성을 미연에 방지하기 위함 입니다. DNS캐시 초기화는 문서화 되지 않은 함수인 DnsFlushResolverCache Win32 API를 사용합니다.


[그림 9] DNS캐시를 초기화 하는 부분


또한 DNS캐시를 주기적으로 10분마다 초기화 시켜주기 위해서 타이머 프로시저를 이용하는 부분도 존재합니다.


[그림 10] DNS캐시의 주기적인 초기화를 위한 타이머 프로시저를 작동시키는 부분



- 파밍 작업 : QQ 블로그를 이용한 파밍 정보 획득


공격자는 파밍 공격에 필요한 정보를 악성코드 내부에 담아 두지 않고 QQ 블로그에 담아둔 뒤, 악성코드에서 이를 받아오는 방법을 선택했습니다. 이를 위해서 암호화 해둔 QQ 블로그 사용자 ID를 악성코드 내부에 삽입해 두었으며, 이를 복호화 해서 가져온 뒤 해당 블로그에 연결을 시도합니다.


[그림 11] QQ 블로그 사용자 ID가 암호화 된 상태로 들어 있는 모습


복호화 된 QQ 블로그 사용자 ID는 2934318127 이었으며, 이 ID를 Blog URL과 조합해서 하나의 URL을 만들어 냅니다. 그리고 해당 URL로부터 데이터를 받아온 뒤 nickname이라는 문자열을 파싱합니다. 아래는 이에 해당되는 부분입니다.


[그림 12] 블로그로부터 데이터를 얻어온 뒤 nickname이라는 문자열을 파싱하는 모습


아래는 접속을 시도하는 URL과 해당 URL로부터 얻어온 데이터를 나타낸 것입니다. 데이터의 nickname 항목을 살펴보면 IP주소(114.181.150.158)가 적혀져 있는데 이것이 파밍에 사용되는 IP주소입니다. 즉, nickname 문자열을 파싱하는 것은 파밍에 사용될 IP주소를 파싱하려는 목적이라고 볼 수 있습니다.


접속 시도하는 URL

URL로부터 얻어온 데이터 

hxxp://r.qzone.qq.com/cgi-bin/user/cgi_personal_card?uin=2934318127  

_Callback(

{"uin":2934318127

"qzone" :0

"intimacyScore" :0

"nicknama":"114.181.150.158",

"realname":""

"smartname":"",

"friendship" :0

"isFriend" :0,

"bitmap":"08009c8002000101"

"avatarUrl":"http://qlogo4.store.qq.com/qzone/***"});



- 파밍 작업 : DNS서버 소켓 생성 및 DNS메시지 해석과 파밍


UDP 53번 소켓을 생성합니다. 53번 포트는 DNS서비스의 포트 번호입니다. 앞서 DNS서버 기본 주소를 localhost로 변경하는 행위가 있었습니다. 즉, 악성코드 스스로가 DNS메시지를 해석하는 DNS서버의 역할을 수행하는 것이라고 볼 수 있습니다.


[그림 13] 53번 포트의 소켓을 생성하는 부분


사용자가 인터넷 창에서 URL을 입력하고 실행하게 되면, URL의 해석을 위해서 DNS서버로 요청을 보냅니다. 그런데 DNS서버 주소는 이미 악성코드에 의해서 localhost로 바뀌어져 있는 상태이기 때문에 악성코드가 DNS메시지를 받아서 처리하는 형태가 됩니다. 아래는 DNS메시지를 받아 오는 루틴을 나타낸 것입니다.


[그림 14] 사용자가 요청한 DNS메시지를 Loopback으로 받아 오는 부분


정상적인 컴퓨터 환경의 경우라면, 아래와 같이 사용자가 URL 입력 시 DNS서버에 요청을 보내고, DNS서버는 해당 URL에 알맞은 IP주소를 알려 줍니다.


[그림 15] 정상적인 PC와 DNS서버간의 관계도

 

그러나 해당 악성코드에 감염되면 악성코드는 PC의 DNS주소를 자기 자신으로 바꿔버리고, 악성코드가 감염된 PC자체가 DNS서버로 변경됩니다.


[그림 16] 악성코드에 감염된 PC와 DNS서버간의 관계도

 

악성코드 내부에는 아래와 같이 받아온 DNS메시지를 해석하는 부분이 존재합니다.


[그림 17] DNS메시지를 해석하는 루틴의 일부


악성코드는 사용자가 요청한 DNS메시지를 받아와서 메시지 해석을 수행하며, 해석을 완료하고 나면 악성코드 제작자가 임의로 정의해 놓은 문자열 형식으로 치환됩니다. 아래는 악성코드가 받아온 DNS메시지를 보여줍니다.


[그림 18] 악성코드에서 수신한 DNS메시지

 

위와 같은 형태의 DNS메시지를 해석하고 나면 아래와 같은 형식으로 치환됩니다.


[그림 19] DNS메시지 해석을 마치고 치환된 결과


이는 공격자가 임의로 편하게 정의해 놓은 형식으로, 아래와 같은 구조를 가집니다.

 

ID^DNSType^URL^URL^URL


ID : 고유 ID값

DNSType : A, CNAME, MX

URL : 인터넷 주소


결과적으로 사용자로부터 전달된 DNS메시지와 악성코드 자체 해석 결과, 그리고 조작된 DNS응답 메시지를 정리해보면 아래와 같습니다. DNS응답을 보낼 때 끝부분의 IP주소를 담는 부분에, 조작된 IP주소를 보내서 파밍이 이루어지도록 합니다.



항목 

데이터 

 사용자 요청 DNS메시지

 2985 0100 0001 0000 0000 0000 03 7A756D 03 636F6D 00 0001 0001

 악성코드 자체 해석 결과

 2985^A^zum^com

 조작된 DNS응답

 2985 8400 0001 0001 0000 0000 03 7A756D 03 636F6D 00 0001 0001 C 00C 0001 0001 0000000A 0004 72B5969E5B19


사용자로부터 요청 받은 DNS메시지 중에서 아래 URL에 해당하면 DNS해석 결과를 변조해서 파밍사이트 결과를 내보내게 됩니다. 아래 URL목록은 악성코드 내부에 암호화 된 형태로 저장되어져 있습니다.



결과적으로 사용자가 악성코드가 공격 대상으로 지정한 웹사이트를 방문하게 되면, 치밀하게 제작된 가짜 웹사이트를 보게 됩니다.


[그림 20] 파밍 공격이 이루어진 모습


- 공인인증서 탈취


악성코드는 공인인증서를 외부로 탈취하는 기능도 지니고 있습니다. 많이 알려진 NPKI 공인인증서 경로를 탐색하여, 파일이 존재할 경우 윈도우 운영체제에서 제공하는 압축 라이브러리인 zipfldr.dll을 이용해서 압축한 뒤 외부 서버로 업로드를 시도합니다. 공인인증서를 탈취하기 위해서 악성코드가 탐색하는 경로는 아래와 같습니다.


A ~ Z드라이브 중 존재하는 드라이브의 최상위 루트 NPKI 폴더

Program Files 이하의 NPKI 폴더

[시스템드라이브]:\Users\[사용자계정]\AddData\LocalLow\NPKI (윈도우 비스타 이상에만 존재)


위 경로들 중 하나 이상이라도 존재하면, 내부의 모든 파일을 아래의 경로로 복사합니다.

 

윈도우XP : [시스템드라이브]:\Documents and Settings\[사용자계정]\Local Settings\Temp\Hs_\Pf\NPKI

윈도우비스타 이상 : [시스템드라이브]:\Users\[사용자계정]\AppData\Local\Temp\Hs_\Pf\NPKI


실제로 아래는 악성코드가 공인인증서를 탈취한 모습을 나타내고 있습니다.


[그림 21] 악성코드가 공인인증서를 임의의 폴더로 복사한 모습


공인인증서 파일을 성공적으로 탈취했다면 zipfldr.dll 라이브러리를 사용해서 ZIP확장자로 압축을 시도합니다. 이를 위해 zipfldr.dll이 정상적으로 시스템에 등록되어있는지 확인하고, 등록되어있지 않을 경우에는 regsvr32를 이용해서 시스템에 등록 시도하는 모습을 확인할 수 있습니다.


[그림 22] zipfldr.dll 시스템 라이브러리를 사용하는 부분


Zipfldr.dll의 사용 준비를 마쳤다면, Visual Basic 스크립트를 구동시켜 공인인증서 파일의 압축을 시도합니다. 아래는 그에 사용되는 VB스크립트를 나타낸 것입니다.


[그림 23] 압축에 사용되는 VB 스크립트


VB스크립트의 실행이 완료되면 아래와 같이 Temp폴더 내부에 정상적인 ZIP 압축 파일이 생성됩니다.


[그림 24] 공인인증서 파일들을 압축한 모습


공인인증서 파일의 압축을 완료했다면 원격 서버로 전송을 시도합니다. 아래는 원격 서버로 전송을 시도하는 루틴의 일부를 나타낸 것입니다.


[그림 25] 외부 서버로 업로드를 시도하는 루틴의 일부



악성코드 분석 결론


해당 악성코드는 이전까지의 수법이었던 Winsock LSP, 호스트 파일 변조가 아닌, 악성코드 자기 자신이 로컬에서 DNS서버가 되어 DNS메시지 해석을 수행하는 다른 종류의 파밍 악성코드입니다.


이에 감염되면 UDP 53번 포트가 개방되고, 네트워크 어댑터의 DNS서버 정보를 로컬IP주소(127.0.0.1)로 설정하여 DNS정보 요청 시 Loopback 형태로 연결되도록 합니다. 사용자가 인터넷을 하면서 URL을 입력하면 악성코드가 해당 URL의 정보를 받아와서 DNS메시지 해석을 수행하고, 사용자가 접속하고자 하는 웹사이트가 공격자가 타겟으로 하는 웹사이트라면 미리 제작해 둔 가짜 웹사이트로 연결이 되도록 합니다.


이러한 유형의 악성코드는 국내에서 지속적으로 유포되고 있습니다. 또한 호스트 파일의 변조 없이 악성코드 프로세스 내부에서 모든 것이 이루어지기 때문에, 향후 커널모드 루트킷 등과 결합되면 탐지하기가 어려워지고 위험성도 높아질 것으로 예상됩니다.



  1. Ec0nomist 2014.10.28 02:43 신고  수정/삭제  댓글쓰기

    아....자체 DNS 방식이었군요. 좋은 정보 감사합니다^^

  2. Ec0nomist 2014.10.28 14:08 신고  수정/삭제  댓글쓰기

    잘 읽었습니다^^

  3. 메트릭스알약 2014.10.28 18:54  수정/삭제  댓글쓰기

    보조 DNS를 구글로 하는 이유가 뭔가요?

    • 알약(Alyac) 2014.10.29 09:48 신고  수정/삭제

      구글 퍼블릭 DNS가 가장 안정적인 서비스이기에 이를 사용하는 것으로 추측됩니다. https://developers.google.com/speed/public-dns/ 이 곳을 참고하시면 구글 퍼블릭 DNS를 사용하여 얻는 장점에 대해 확인하실 수 있습니다.

  4. 지나가던이 2015.02.02 15:25  수정/삭제  댓글쓰기

    좋은 글 잘 읽었습니다.

    다름이 아니라 글을 읽으면서 확인을 해보니까 해당 과정 중에서 [시스템드라이브]:\Documents and Settings\[사용자계정]\Local Settings\Temp\Hs_\Pf\NPKI 폴더로 공인인증서 계열의 파일을 복사한 것까지는 일치했는데 zip과 같이 압축파일은 존재하지 않았습니다.

    그렇다면 zip 파일이 없으면 실행 중 중단된 것이라 보고 문제가 없다고 봐도 될까요? 그리고 복사된 폴더에 공인인증서, 보안인증서 파일이 있는 것 같은데 이를 삭제해도 되나요?

    • 알약(Alyac) 2015.02.03 16:03 신고  수정/삭제

      저희가 해당 시스템을 들여다보지 않았기 때문에 정확하게 답변은 어렵지만, 일반적으로 해당폴더의 zip파일은 공인인증서가 해당경로에 존재하면 무조건 생성되기 때문에 zip파일이 생성이 되지 않았다면 가져갈 공인인증서 파일이 없었을 것이라고 추측됩니다. 다만 이것은 말씀해주신 상황만 가지고 판단한 추정이며, 동일한 악성코드가 아닌 변종인 경우에는 동작이 달라질 수 있는 점도 참고부탁드립니다.

티스토리 방명록 작성
name password homepage