Bagi mereka yang sudah cukup bermain dengan
teka-teki crackme , kami membawa Trojan baru. Di alam bebas, pengunduh Hancitor masih ditemukan di habitat aslinya - surat spam. Saat ini, secara aktif digunakan untuk mengunduh trojan perbankan Panda, yang merupakan modifikasi dari Zeus yang terkenal jahat.
Suatu malam musim panas yang dingin, kami bertemu muka dengannya, melihat email spam. Jika Anda suka menonton apa yang dimiliki malware di bawah tenda, baca penguraian terbalik baru kami.
Dokumen jahat kami terlihat seperti ini:
Secara default, makro diblokir, jadi sistem memperingatkan: "Makro telah dinonaktifkan." Namun, isi pesan mengatakan bahwa makro harus dimasukkan. Baiklah, mari kita lakukan. Setelah mengklik tombol Aktifkan Konten, komputer terinfeksi. Sekarang mari kita lihat makro seperti apa yang dieksekusi dan bagaimana tepatnya infeksi terjadi. Ini dapat dilakukan segera di Word dengan membuka tab View-> Vacros \ View Macros.
Anda dapat melakukan lebih banyak secara profesional - gunakan
olevba dari paket oletools. Anda dapat menginstal paket di sana di tautan. Selanjutnya, ketik olevba doc_file –c –decode> source.txt dan dapatkan sumber makro.
Dengan kode itu, saya langsung ingin mengatakan bahwa trojan itu milik kelas pengunduh. Script hanya mengempis dari suatu tempat ke Malwara. Untuk membuktikan ini, mari kita decode string base64. Lebih mudah bagi kami untuk melakukan ini segera melalui hiew, sehingga kami tidak menyalin-menempel seratus kali. Untuk tujuan ini kita menggunakan plug-in khusus yang dijelaskan
di sini . Inilah yang terjadi:
Ini adalah skrip berbahaya, dipecah menjadi dua bagian dan disimpan sebagai 1.hta. Pada prinsipnya, kami tidak terlalu tertarik dengan cara kerjanya. Itu semua lumrah. Satu-satunya poin penting adalah menentukan URL tempat file jahat diunduh. Mari kita coba menemukannya, karena informasi ini mungkin berguna untuk
keamanan . Mereka dapat menambahkan aturan jaringan untuk memblokir permintaan di URL tersebut, yang dapat menyelamatkan perusahaan dari infeksi.
Ha! Tidak ada tautan. Tapi dari mana file 6.exe berasal, yang dimulai 1.hta? Saatnya untuk melihat lagi file dock kami di hiew, tetapi lebih hati-hati:
Ya, exe-shnik dibangun ke dalam dokumen dok. Ya, dan sangat dikemas. Mari kita jelaskan apa yang sedang terjadi. Makro menjatuhkan skrip 1.hta berbahaya ke folder Temp dan meluncurkannya, dan 1.hta, pada gilirannya, meluncurkan 6.exe dari direktori. Jelas bahwa 6.exe adalah paket PE-shnik yang sama dengan yang kita lihat di layar. Tapi sekarang kita bertanya-tanya bagaimana 6.exe turun dalam% temp%. Dan ini terjadi karena fitur yang menarik di suite Microsoft Office. Faktanya adalah bahwa dalam dokumen OLE apa pun, file lain dalam format Ole10Native dapat disematkan.
Jika ini masalahnya, maka saat startup MS-Office sendiri akan menjatuhkan file yang dibuat dengan cara ini ke folder% temp% di bawah nama yang ditentukan dalam header struktur Ole10Native. Mari kita lihat objek ini. Kami dibantu oleh plugin untuk FAR-manager -
OLE2Viewer . Kami membuka dokumen jahat kami di plugin, pergi ke direktori ObjectPool \ _1593522492 dan lihat ini:
Salin file ini (Ole10Native) dan buka di hiew.
Di sini kita melihat di bawah apa nama objek OLE kita - 5c.pif akan jatuh ke folder% temp%. Sekarang kembali ke makro kita. Tugasnya adalah meluncurkan exe-shnik yang mabuk.
Bahkan, tepatnya, makro tidak selalu memulai file yang dijatuhkan melalui 1.hta, tetapi juga seperti ini: Shell “cmd.exe / c ping localhost -n 100 &&” & Lingkungan (“Temp”) & "\ 6 .pif ", vbSembunyikan
Metode peluncuran, seperti yang kita lihat, tergantung pada keberadaan proses berikut dalam sistem: bdagent.exe dan PSUAMain.exe. Lalu mengapa Anda perlu melakukan ping localhost -n 100? Dan ini adalah trik Yunani kuno untuk membuat penundaan buatan, untuk berjaga-jaga. Biasanya variasinya digunakan untuk menghilangkan diri.
Pada tahap ini, kami memeriksa pengoperasian dokumen jahat. Menjadi jelas bagi kami bahwa dokumen itu sendiri bukan milik malware dari tipe Trojan-Downloader, seperti yang terlihat pada pandangan pertama, tetapi cocok untuk tipe Trojan-Dropper. Inilah yang terjadi saat startup:
Sekarang tinggal membongkar muatan itu sendiri. Kami sudah menyadari bahwa trojan kami sudah dikemas, jadi kami harus membukanya terlebih dahulu. Biasanya proses ini dibagi menjadi dua tahap:
1. Menghapus tempat sampah + yang belum dikemas + mengembalikan tabel impor.
2. Analisis dan pemurnian variabel global.
Kita membutuhkan tahap kedua karena ada banyak fungsi API yang, sebagai hasil dari pekerjaan mereka, mengembalikan nilai yang tidak berulang kepada kita. Sebagai contoh, CreatHeap akan mengembalikan deskriptor tumpukan kepada kami, yang selanjutnya akan digunakan untuk pekerjaan. Sangat sering ada jenis cek dalam kode:
jika deskriptor heap == 0, maka dapatkan deskriptor heap, jika tidak gunakan yang sudah diinisialisasi . Tetapi pada saat dump, variabel yang berisi deskriptor yang diberikan sudah diinisialisasi olehnya dan pada saat itu deskriptor valid. Ketika kami mencoba memulai dump, variabel dengan deskriptor kami akan berisi nilai lama, mis. Tidak sama dengan 0, yang berarti bahwa tes akan lulus.
Setelah itu, segera setelah program mencoba menggunakan deskriptor ini, OS akan melempar pengecualian dan program akan crash dengan kesalahan. Jadi, untuk menghindari ini, Anda perlu nol variabel ini. Mereka biasanya terletak di bagian data yang dapat ditulisi. Mungkin Anda menyarankan membuka bagian ini di hex editor dan menimpa semuanya dengan nol? Anda sebagian benar, tetapi Anda tidak harus mengambil tindakan gegabah. Ada trojan yang memeriksa variabel bukan pada 0, tetapi pada DWORD acak. Dan tergantung pada apakah tes sedang diuji atau tidak, berbagai tindakan diambil. Anda tidak perlu pergi jauh untuk contoh. Lihat saja
Cridex (baru-baru ini telah menghilang di suatu tempat dari radar, tampaknya telah sepenuhnya ditingkatkan menjadi EMOTETA).
Jadi, mari kita jalankan sampel kami (di mesin virtual, tentu saja). Juga diinginkan bahwa lalu lintas yang akan keluar dari mesin virtual melalui VPN.
Kami meluncurkan Trojan kami, dan itu hanya hang dalam proses. Hebat! Biasanya, Trojan melakukan hal-hal dengan cepat, dan kemudian segera berakhir dan merusak diri sendiri. Oleh karena itu, Anda harus mencari tempat dalam kode yang bertanggung jawab atas tindakan ini, menghentikannya, dan kemudian membuangnya. Dalam kasus kami, kami bisa melakukannya begitu saja.
Untuk dump, kami menggunakan utilitas luar biasa - Process Dump, yang dapat ditemukan di
sini . Utilitas ini tidak hanya menemukan semua modul yang dapat dieksekusi yang tersembunyi dan membuangnya, tetapi juga mengembalikan tabel impor itu sendiri. Utilitas harus dijalankan sebagai administrator dengan cara berikut: pd / pid xxxx, di mana xxxx adalah id dari proses Trojan. Setelah itu, utilitas akan membuang semua modul proses. Kami menghapus yang ekstra dan inilah yang tersisa:
Nama file yang dapat dieksekusi dari proses Trojan adalah 1.exe. Ternyata trojan yang dibongkar terletak di 0x2C0000. Buka di hiew:
Hanya mata yang senang! Sekarang file dibongkar, terlihat jelas. Tabel impor juga diakui. Mari kita buka di IDA-PRO.
Kami telah mengganti nama beberapa fungsi saat kami mengurutkan sampel. Hal pertama yang dimulai dengan trojan adalah menentukan alamat muat modulnya. Dan sungguh: bagaimana dia tahu di alamat apa rintisannya dibongkar? Hal ini dilakukan dengan teknik lama yang sudah terbukti - membalik halaman memori kembali pada 0x1000 relatif ke alamat saat ini sampai kita menemukan byte "MZ". Ini berfungsi karena modul yang dapat dieksekusi selalu memuat OS di alamat yang merupakan kelipatan 0x1000. Lihat sendiri. Dalam kasus kami, batas 100 pengupasan ditetapkan.
Jika seseorang tidak mengerti di mana ada membalik kembali, maka di sinilah tempatnya:
hasil + = 0xFFFFF000 setara dengan hasil - = 0x1000.
Setelah menerima alamat pengunduhan modulnya, trojan yang dibongkar menerima alamat fungsi yang diperlukan untuk operasinya. Untuk mulai dengan, alamat dua fungsi dicari - LoadLibraryA dan GetProcAddress. Mengetahui alamat fungsi-fungsi ini, Anda dapat menggunakannya untuk mendapatkan sisanya. Fungsi-fungsi ini ada di pustaka kernel32. Alamatnya diperoleh dengan membaca elemen pertama (nol-ntdll, kernelbase pertama, dll.) Dari daftar cincin yang menjelaskan semua modul yang dimuat dalam urutan inisialisasi dengan struktur _LDR_DATA_TABLE_ENTRY. Pointer ke daftar ditarik dari PEB.
Setelah menerima alamat kernel32.dll (dimulai dengan Windows 7 - kernelBase.dll), trojan dapat secara manual mem-parsing tabel ekspornya dan menemukan dua fungsi yang diperlukan, yang diperkirakan dilakukan dalam subrutin sub_EF1E60.
Sekarang lihat fungsi yang kita sebut getHeap.
Di sini kita mengamati hanya situasi yang dijelaskan di atas. Pada saat dump, variabel hHeap berisi nilai 600000h. Karena itu GetProcessHeap tidak akan dipanggil. Sebagai gantinya, program akan menuju label loc_EF11DD, di mana HeapAlloc dipanggil dengan pegangan yang tidak valid, yang akan memberi kita kesalahan. Oleh karena itu, kami mengambil hex editor dan nol angka ini. Kami menghitung enam tempat serupa.
Selanjutnya, kesenangan dimulai. Trojan menghasilkan ID "klien" unik berdasarkan nomor seri hard disk dan alamat MAC. Informasi yang diterima di sini:
Kami juga mendapatkan yang berikut: alamat IP, versi OS, nama jaringan dan nama pengguna. Berdasarkan semua ini, permintaan HTTP dihasilkan ke panel admin, alamat yang belum kita ketahui. Itu tidak dalam garis (bahkan dalam bentuk yang belum dibongkar). Tetapi tidak ada di sana, karena dienkripsi dalam konfigurasi. Alamatnya dapat ditarik dari kode:
Konfigurasi beratnya 0x2008 byte dan memiliki format berikut: 8 byte pertama adalah kunci RC4, 0x2000 byte adalah data terenkripsi.
Fakta bahwa algoritma enkripsi RC4 digunakan menjadi jelas dari daftar berikut:
Harap dicatat bahwa 8 byte pertama saja bukan kunci untuk RC4. Kuncinya adalah hash SHA1 dari byte ini. Anda juga perlu memperhatikan flag 0x280011 untuk fungsi CryptDeriveKey. MSDN memiliki penafian terkait bendera ini:
Dari sini menjadi jelas bahwa 16 bit tinggi dari flag ini mengatur ukuran kunci dalam bits. Yaitu, dalam byte ukuran kunci adalah: (0x280011 >> 16) / 8 = 5. Oleh karena itu, kunci akan menjadi lima byte pertama dari hash dari delapan byte pertama dari konfigurasi. Mari kita buang konfigurasi dan menulis skrip python yang akan mendekripsi untuk kita. Scriptnya terlihat seperti ini:
Hasil karyanya adalah file config.rc4. Buka di hiew:
Kami melihat daftar area admin yang didekripsi. Kata pertama adalah "19nep07" - nomor build. 16 byte dialokasikan untuk itu. Berikutnya adalah daftar URL admin yang dipisahkan oleh "|".
Jadi, panggilan pertama ke panel admin akan memiliki format ini:
GUID = 3068075364164635648 & BUILD = 19nep07 & INFO = MENANG-56G04BL06SL @ MENANG -56G04BL06SL \ Membalikkan & IP = 35.0.127.52 & JENIS = 1 & MENANG = 6.1 (x32
Kemudian permintaan yang dihasilkan dikirim terlebih dahulu dalam daftar panel admin.
Selanjutnya, respons dari admin dibaca, tentu saja, jika masih hidup. Jawabannya harus dienkode base64. Jika ini bukan masalahnya, maka admin berikutnya dari daftar diambil. Terkadang admin langsung mengembalikan jawaban yang aneh:
Sudah akrab, bukan? Ya, ini
nomor yang sama! Bahkan, seorang penulis tahu mengapa admin mulai mengembalikannya! Dalam bentuk normal, perintah kembali. Sayangnya, tidak mungkin untuk mengatakan dengan pasti apa format responsnya, karena tidak ada traffic, semua admin sudah mati. File yang diterjemahkan juga diterjemahkan ke 0x7A:
Respons harus berisi perintah. Jika tidak, ada banding ke panel admin berikutnya. Kode perintah dikodekan sebagai "x:", di mana x adalah huruf yang mengkode perintah tertentu. Ada 7 dari mereka: 'r', 'l', 'e', 'b', 'd', 'c', 'n'. Pertimbangkan perintah "b" dan "r".
Penangan perintah ini memiliki fungsi yang sama. Kami menamakannya seperti GetExe. Begini tampilannya:
Saya pikir semuanya jelas di sini. Trojan membuat permintaan http dan file yang dapat dieksekusi dikembalikan sebagai respons dalam bentuk terkompresi, yang kemudian didekompresi. Maka variasi dimungkinkan. Dalam kasus perintah "b", tiga tindakan berikut terjadi:
1. Pembuatan proses svchost dalam bentuk beku
2. Injeksi ke dalam ruang alamat dari proses modul yang diunduh
3. Kontrol transfer ke modul yang disuntikkan
Dalam kasus perintah r, tiga tindakan berikut terjadi:
1. Mengunduh file yang dapat dieksekusi dengan memanggil fungsi GetExe.
2. Menyimpan file yang diunduh ke folder temp dengan nama acak.
3. Luncurkan file yang dijatuhkan.
Selesai
PS Lain kali kita dapat menguraikan Panda atau cryptor. Tulis di komentar malware mana yang paling Anda minati (untuk tujuan penelitian, tentu saja).