Спасибо, вам, о Хабралюди, за небольшую прибавку к карме. Теперь я наконец-то смогу написать про вчерашние события на Одноклассниках с техническими подробностями.
2.06.2008 была произведена массовая спам-рассылка, нацеленная на пользователей «Одноклассников». В сообщениях содержалась ссылка на некий сайт. К сожалению, когда я пришел на работу и начал проблемой заниматься, ссылка уже была мертва. Но юзеры успели по ней перейти и в итоге прислали нам несколько исполняемых файлов. Скорее всего, по ссылке был како-то из эксплоитов, позволяющий загружать на компьютер жертвы файлы без ведома пользователя и их запускать. Первый попавший на компьютер жертвы файл я не анализировал, мне достался какой-то из этапов его зловредного жизненного пути.
Итак, WinNt32.dll.
Обычная DLL, разве что экспортов нет и сразу бросается в глаза что файл шифрован или сжат. Первым делом из двух забитых констант вычисляется адрес KiFastSystemCall и производится вызов этой функции. В EAX в это время 0x09, что, вроде бы, соответствует NtEnumerateBootEntries:
.text:004011A6 mov edx, 67C7AE8Eh
.text:004011AB mov ebx, [edx+18365472h]
.text:004011B1 dec ebx
.text:004011B2 call ebx
Это своеобразная привязка к ОС и защита от отладки: в одной из наших виртуальных машин файл не заработал. В секции .rsrc файл содержит большой массив зашифрованных данных, адрес которых затем передается в VirtualProtect. После этого вызывается функция расшифровки, в результате чего в памяти получается полноценный исполняемый файл. Теперь дело за малым — VirtualAlloc, несколько раз memcpy и в свежевыделенной памяти образ файла, готовый к исполнению. Замечу, что расшифрованный файл не сбрасывается на диск!
Расшифрованный и загруженный на первом этапе файл несет в себе всю полезную нагрузку. Он создает в HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\WinNt32 два параметра: ID и Unique (заполняется случайной строкой). После этого по неясному алгоритму (скорее всего случайным образом) формируется GET-запрос. Следующий шаг — загрузка из сети шифрованных данных. Применяется не InternetReadFile или UrlDownloadToFile, а базовые функции Windows Sockets: connect-send-recv. Запрашиваемый URL всегда разный, равно как и принятые данные, что наводит на мысль о том, что получаемые данные зависят от запрашиваемого URL'а. После расшифровки принятых данных в памяти оказываются 2 PE-файла. Первый из файлов сохраняется на диск и запускается, а вот судьба второго немного интереснее. Троянец запускает процесс svchost, а затем инжектит в него при помощи WriteProcessMemory второй полученный файл и передает управление на его код.
Итого: в спаме распространялась ссылка на страницу, предположительно содержащую вредоносный код, скачивающий и запускающий на компьютере жертвы некий файл. В результате работы этого файла на диске жертвы оказывался файл WinNt32.dll, который получал через сеть два шифрованных файла, один из которых сохранял и запускал, а второй — инжектил в svchost.
Функционал скачанных файлов сейчас анализирую. Ждите новостей!
2.06.2008 была произведена массовая спам-рассылка, нацеленная на пользователей «Одноклассников». В сообщениях содержалась ссылка на некий сайт. К сожалению, когда я пришел на работу и начал проблемой заниматься, ссылка уже была мертва. Но юзеры успели по ней перейти и в итоге прислали нам несколько исполняемых файлов. Скорее всего, по ссылке был како-то из эксплоитов, позволяющий загружать на компьютер жертвы файлы без ведома пользователя и их запускать. Первый попавший на компьютер жертвы файл я не анализировал, мне достался какой-то из этапов его зловредного жизненного пути.
Итак, WinNt32.dll.
Обычная DLL, разве что экспортов нет и сразу бросается в глаза что файл шифрован или сжат. Первым делом из двух забитых констант вычисляется адрес KiFastSystemCall и производится вызов этой функции. В EAX в это время 0x09, что, вроде бы, соответствует NtEnumerateBootEntries:
.text:004011A6 mov edx, 67C7AE8Eh
.text:004011AB mov ebx, [edx+18365472h]
.text:004011B1 dec ebx
.text:004011B2 call ebx
Это своеобразная привязка к ОС и защита от отладки: в одной из наших виртуальных машин файл не заработал. В секции .rsrc файл содержит большой массив зашифрованных данных, адрес которых затем передается в VirtualProtect. После этого вызывается функция расшифровки, в результате чего в памяти получается полноценный исполняемый файл. Теперь дело за малым — VirtualAlloc, несколько раз memcpy и в свежевыделенной памяти образ файла, готовый к исполнению. Замечу, что расшифрованный файл не сбрасывается на диск!
Расшифрованный и загруженный на первом этапе файл несет в себе всю полезную нагрузку. Он создает в HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\WinNt32 два параметра: ID и Unique (заполняется случайной строкой). После этого по неясному алгоритму (скорее всего случайным образом) формируется GET-запрос. Следующий шаг — загрузка из сети шифрованных данных. Применяется не InternetReadFile или UrlDownloadToFile, а базовые функции Windows Sockets: connect-send-recv. Запрашиваемый URL всегда разный, равно как и принятые данные, что наводит на мысль о том, что получаемые данные зависят от запрашиваемого URL'а. После расшифровки принятых данных в памяти оказываются 2 PE-файла. Первый из файлов сохраняется на диск и запускается, а вот судьба второго немного интереснее. Троянец запускает процесс svchost, а затем инжектит в него при помощи WriteProcessMemory второй полученный файл и передает управление на его код.
Итого: в спаме распространялась ссылка на страницу, предположительно содержащую вредоносный код, скачивающий и запускающий на компьютере жертвы некий файл. В результате работы этого файла на диске жертвы оказывался файл WinNt32.dll, который получал через сеть два шифрованных файла, один из которых сохранял и запускал, а второй — инжектил в svchost.
Функционал скачанных файлов сейчас анализирую. Ждите новостей!