Baru-baru ini, spesialis PT ESC menemukan dokumen format Penerbit yang disebut “Undangan 29-30 November, 2018.pub” (1edd5b6a02ec82cec381c1a1ec74a67e). Dalam artikel ini, kami akan memberi tahu Anda bagaimana dokumen yang tampak biasa berubah menjadi trojan, memungkinkan penyerang untuk menangkap gambar dari webcam, merekam suara dengan perintah atau ketika jendela Skype terdeteksi, jalankan skrip PowerShell, ambil tangkapan layar, salin file dari perangkat media.
Jadi, ketika Anda membuka dokumen, sebuah jendela muncul dengan tulisan rintisan buram dan permintaan untuk memasukkan skrip Microsoft Publisher.
Setelah pengguna menyalakannya, skrip dibangun ke dalam dokumen berjalan dalam JavaScript. Ini terlihat seperti ini:
Hasil skrip akan menjadi decoding dari dua file, PDF dan EXE, dari Base64. Kedua file akan ditulis ke C: \ Users \ {Username} \ AppData \ Roaming \ DBFUpdate. Dengan demikian, kedua file akan dieksekusi, dan pengguna akan melihat tulisan rintisan di layar dokumen:
Pemburu Harta Karun RAT
Penyerang menggunakan RAT multi-modul dengan seperangkat fungsi besar yang menyediakan akses penuh ke mesin yang terinfeksi.
Fitur Kode:
- Sepenuhnya ditulis dalam C ++ dengan sejumlah besar konstruksi STL yang digunakan secara internal.
- Aplikasi meningkatkan perpustakaan, khususnya JSON dan Arsip.
- Fungsi debugging (lebih banyak pada bagian tentang stager).
Trojan utama
Trojan utama diperbaiki pada mesin korban dan merupakan platform di mana modul jahat dimuat dari C2.
Pertama, stager menginisialisasi direktori kerja, yang selanjutnya akan menyimpan informasi yang dikumpulkan oleh modul, utilitas yang diperlukan agar modul berfungsi, dll.
Di bawah ini adalah inisialisasi jalur untuk membuat direktori kerja:
Setelah direktori yang diperlukan dibuat, trojan utama mengumpulkan informasi tentang mesin yang terinfeksi dan mengirimkannya ke server kontrol.
Troyan tertarik pada data tersebut:
- pengidentifikasi versi OS di mana trojan utama berjalan;
- Bahasa antarmuka default
- Nomor versi utama dari OS Paket Layanan;
- nama komputer dan pengenal mesin (untuk perincian tentang cara mendapatkan pengenal mesin, lihat bagian pada protokol jaringan).
Ini adalah bagaimana informasi tentang mesin yang terinfeksi dikumpulkan:
Selanjutnya, trojan utama diperbaiki pada mesin yang terinfeksi melalui modifikasi nilai dalam registri di HKCU \ Environment \ UserInitMprLogonScript. Nama file yang dapat dieksekusi yang dialokasikan selama inisialisasi direktori kerja ditulis di sini, dalam hal ini sama dengan "DCTHOST.exe". Metode ini
dijelaskan di blog Hexacorn , dan juga digunakan oleh APT28 dan grup Cobalt dalam ComDLLDroper mereka.
Dan langkah terakhir dalam menginisialisasi trojan utama adalah menyalin file yang dapat dieksekusi dari lokasi saat ini ke direktori kerja dengan nama yang sama yang dipilih ketika direktori kerja diinisialisasi.
Setelah trojan utama diinisialisasi, persiapan untuk menerima perintah dilakukan. Modul Core ditambahkan ke daftar modul yang sedang berjalan, yang merupakan trojan utama. Selanjutnya, sebuah perintah diluncurkan dari modul Core dengan identifier 0. Tidak ada implementasi dari perintah ini di modul utama, melainkan hanya sebuah rintisan. Konstruktor objek modul Inti disajikan di bawah ini.
Pada akhirnya, dua utas dimulai. Salah satu utas memulai penghitung waktu, yang bangun secara default setiap detik dan mencoba meminta perintah dari C2.
Streaming kedua memuat perpustakaan tambahan dan modul standar. Perpustakaan, seperti modul, memiliki pengidentifikasi, tetapi tidak seperti modul, pengidentifikasi perpustakaan negatif, mulai dari -1, tumbuh menuju angka yang lebih rendah. Di bawah ini adalah daftar perpustakaan yang diunduh dari C2.
Fitur debugging dari trojan utama
Pada awal pekerjaannya, segera setelah inisialisasi, trojan utama menetapkan penangan pengecualian melalui SetUnhandledExceptionFilter, yang berisi fungsionalitas yang menarik. Ketika pengecualian terjadi, mereka jatuh ke dalam handler, yang menulis minidump aplikasi, sementara juga menyimpan informasi tentang pengecualian. Kemudian restart sendiri. Di layar - membuat minidump:
Protokol jaringan
Pertukaran antara perangkat lunak dan C2 berlangsung menggunakan protokol biner yang ditulis sendiri. Setiap pesan dideskripsikan menggunakan BinPackage (nama diambil dari RTTI). Setiap BinPackage pada dasarnya adalah pembungkus di atas std :: vector, yang menyimpan set PackageRecord (namanya diciptakan). PackageRecord adalah unit minimum untuk menyimpan data.
struct PackageRecord { _DWORD dataId; _DWORD datatype; _DWORD szData; char[] data; };
Lebih lanjut tentang bidang struktur ini:
- dataId - menunjukkan jenis catatan. Entah entri tersebut adalah pengidentifikasi modul, atau pengidentifikasi perintah, atau muatan.
- szData - ukuran data yang disimpan dalam catatan.
- datatype adalah tipe data.
Secara total, penggunaan tiga tipe data dicatat:
- Nilai "0" berarti bahwa data yang disimpan dalam catatan harus ditafsirkan sebagai DWORD.
- Nilai "1" - data yang disimpan dalam catatan harus ditafsirkan sebagai string ASCIIZ.
- Nilai "2" - data yang disimpan dalam catatan harus ditafsirkan sebagai data terenkripsi / buffer mentah.
Saat mengirim BinPackage ke server kontrol, pengenal mesin ditambahkan ke dalamnya. Identifier adalah GUID dari bagian dari mana semua karakter khusus dipotong. Pada gambar - mendapatkan pengenal mesin:
Sebelum mengirim, semua catatan yang disimpan di BinPackage dikumpulkan secara berurutan dalam satu buffer dan dienkripsi. Untuk enkripsi, perpustakaan
WinAES digunakan , khususnya AES-128-CBC.
Menggunakan CryptoAPI Windows, dua pseudo-random array 16-byte dihasilkan. Satu untuk IV, yang lain untuk kuncinya. Enkripsi dilakukan dan data terenkripsi ditambahkan kembali ke BinPackage, yang berisi paket terenkripsi dan terdiri dari tiga entri:
- rekam dengan ID 0x777 - berisi kunci yang digunakan untuk enkripsi;
- catatan dengan ID 0x555 - berisi IV yang digunakan untuk enkripsi;
- catatan dengan ID 0x999 - berisi data terenkripsi (secara umum, catatan dengan ID ini menunjukkan muatan dan digunakan tidak hanya untuk menyimpan data terenkripsi).
Setelah proses enkripsi selesai, BinPackage yang dihasilkan dikumpulkan lagi dalam satu buffer dan dikirim melalui permintaan HTTP POST ke server pengelola 151.80.2.237.222.
Di bawah ini adalah contoh dari paket yang berisi informasi mesin:
Dan ini adalah contoh paket terenkripsi dengan informasi sistem:
Modul
Setiap modul, kecuali Core, dimuat dari server kontrol. Semua modul dapat dibagi menjadi dua kategori - modul yang dimuat secara otomatis, dan modul yang dimuat berdasarkan permintaan dari server kontrol.
Contoh paket yang meminta modul:
Respons terhadap permintaan modul:
Setiap modul memiliki antarmuka sederhana yang terdiri dari tiga fungsi: dipanggil saat memuat modul Init, dipanggil setelah penyelesaian fini, dan fungsi yang mengubah konfigurasi modul. Setiap modul juga memiliki ekspor bernama GetModule, yang membangun objek yang mewakili modul ini dan mengembalikannya ke trojan utama. Semua modul yang kami temukan diluncurkan dalam memori menggunakan pemuatan reflektif.
Selanjutnya, nama-nama modul diberikan dalam bentuk di mana mereka hadir dalam RTTI sebagai nama kelas.
Modul CCore
Modul ini mewakili fungsi dasar dan dibangun langsung ke trojan utama. Konstruktornya dapat dilihat pada tabel di bawah ini:
| Modul id | ID tim | Deskripsi |
|---|
| 0 | 0 | Pada dasarnya, trojan bukan perintah adalah sebuah rintisan, dan tujuan pastinya tidak dapat ditetapkan |
| 1 | Ubah konfigurasi modul |
| 2 | Minta informasi komputer |
| 3 | Unduh utilitas dari server kontrol |
| 4 | Minta daftar direktori yang berisi utilitas |
| 5 | Unduh modul dan jalankan |
Modul CShell
Modul ini menyediakan shell jarak jauh ke mesin yang terinfeksi. Ketika modul diinisialisasi, proses cmd.exe dibuat, di mana dua pipa terpasang: satu untuk input standar dan satu untuk output standar, di mana perintah diterima dan dikirim dari server kontrol dan sebaliknya. Juga pada saat ini, utas dimulai, yang secara otomatis mengambil semua output dan mengirimkannya ke server kontrol. Gambar tersebut menunjukkan inisialisasi modul CShell.
| Modul id | ID tim | Deskripsi |
|---|
| 2 | 0 | Kirim perintah ke shell |
| 1 | Cetak file. File dibaca, jalur yang ditransmisikan dari server kontrol, dan konten file ini diunggah ke server kontrol |
| 2 | Dapatkan daftar semua drive yang ada di sistem. Data dikirim ke server kontrol dalam format JSON |
| 3 | Unduh file dari server kontrol. Jalur tempat menyimpan file, dan data diterima dari server kontrol |
Modul CFileSystemBrowser
Ini adalah modul pasif, yang atas permintaan memungkinkan Anda menerima informasi tentang struktur sistem file. Ini adalah bagaimana inisialisasi modul CFileSystemBrowser terjadi:
| Modul id | ID tim | Deskripsi |
|---|
| 3 | 0 | Dapatkan daftar semua disk yang ada di sistem. Data dikirim ke C2 dalam format JSON |
| 1 | Dapatkan daftar direktori. Daftar dihasilkan dalam format JSON |
| 2 | Cetak file. File dibaca, jalur yang ditransfer dari C2, dan konten file ini diunggah ke C2 |
| 3 | Hapus file. Jalur ke file ditransfer dari C2 |
Modul CScreenShot
Modul ini memungkinkan Anda untuk mengambil tangkapan layar atau mengambil gambar dari webcam. Ini dapat melakukan ini baik berdasarkan permintaan dan dengan periode waktu tertentu.
| Modul id | ID tim | Deskripsi |
|---|
| 4 | 0 | Ambil tangkapan layar dan kirimkan ke server kontrol |
| 1 | Jalankan penghitung waktu, setelah itu tangkapan layar diambil dari layar mesin. Tangkapan layar yang dihasilkan dikemas dalam BinPackage dan disimpan ke folder log. Nama untuk file dihasilkan menggunakan API GetTempFileName dengan awalan "MS_". |
| 2 | Dapatkan video perangkat yang tersedia di mesin yang terinfeksi |
| 3 | Ambil bingkai dari webcam dan kirimkan ke server kontrol |
Modul CSender
Modul ini awalnya tidak diaktifkan. Itu mengunggah isi folder log ke server kontrol. Itu diaktifkan ketika permintaan datang untuk mengubah konfigurasi, yang berisi periode verifikasi.
Modul CKeylogger
Modul ini pada awalnya juga tidak diaktifkan. Ini diaktifkan ketika permintaan untuk perubahan konfigurasi tiba yang berisi ukuran buffer di mana log disimpan. Intersepsi input dilakukan melalui
input mentah . Selain itu, keylogger memonitor jendela di mana pengguna membuat input dan mencatat judulnya.
Modul CDictaphone
Modul ini merekam suara dengan perintah atau saat mendeteksi jendela Skype. Ketika diluncurkan, ia memulai utas yang mencantumkan semua jendela dan jendela anak mereka di sistem dan mencari jendela di antara kelas-kelas yang nama kelasnya adalah TLiveConversation atau TCallMonitorControl. Jika jendela seperti itu ditemukan, perekaman dimulai. Di bawah ini adalah inisialisasi modul CDictaphone:
Dan pencarian jendela Skype
Perekaman dilakukan melalui MCI dengan mengirimkan perintah khusus. Ini adalah bagaimana siklus menulis modul CDictaphone terlihat:
Setelah menutup jendela atau menerima perintah untuk menyelesaikan rekaman, data yang diterima disimpan dalam folder sementara, setelah itu dikodekan oleh MP3 encoder lame (dianggap sebagai utilitas dan harus sudah dimuat, itu tidak mungkin untuk mendapatkannya dari server kontrol). File yang disandikan disimpan di folder log. Membuat nama folder mirip dengan membuat nama untuk tangkapan layar.
| Modul id | ID tim | Deskripsi |
|---|
| 7 | 0 | Mulai merekam dan menyelesaikannya setelah 15 menit |
| 1 | Hentikan rekaman |
| 2 | Periksa status: sedang merekam sedang berlangsung |
Modul Manajer Proses
Ini adalah modul pasif, yang mampu mengembalikan daftar proses berdasarkan permintaan atau diakhiri oleh PID yang diteruskan kepadanya.
| Modul id | ID tim | Deskripsi |
|---|
| 8 | 0 | Mengembalikan daftar proses: nama mereka, PID, dan nama pengguna yang memiliki proses. |
| 1 | Selesainya proses PID |
Modul Pengunduh CD
Modul ini dirancang untuk mengunggah file besar ke server kontrol. Melakukan transmisi data dengan potongan, yang ukurannya ditentukan oleh konfigurasinya. Modul membaca data dari file, jalur yang diterimanya dari server kontrol, dan paket potongan di BinPackage. Untuk setiap BinPackage yang berisi chunk, entri dengan pengenal 0x888 ditambahkan, termasuk jalur ke file. Setelah melewati setiap chunk, tidur dilakukan selama 5 detik.
| Modul id | ID tim | Deskripsi |
|---|
| 9 | 0 | Stub, gagal menetapkan nilai yang tepat |
| 1 | Melakukan transfer sejumlah besar data (0x500000 byte), setelah itu mengukur waktu yang dihabiskan untuk transfer, dan mengirimkan nilai ini ke C2 |
| 2 | Unduh file dari mesin |
Modul CPS
Modul ini memungkinkan Anda untuk menjalankan skrip PowerShell.
| Modul id | ID tim | Deskripsi |
|---|
| 10 | 0 | Menerima skrip PowerShell dari C2 dan menjalankannya |
Modul CDeviceMonitor
Modul pasif yang memonitor perangkat media yang terhubung dan menyalin file dari mereka. Ini menggunakan pesan siaran WM_DEVICECHANGE untuk mendeteksi konektivitas perangkat. Setelah menghubungkan perangkat ke server kontrol, informasi dikirim tentang kapan perangkat terhubung, label volumenya dan jalur ke perangkat. Kode yang digunakan untuk mendapatkan jalur ke perangkat sangat mirip dengan ini. Semua file disalin ke folder log. Nama dibuat dengan cara yang sama seperti untuk tangkapan layar. File fsIndex.dat dibuat secara terpisah, di mana kamus bersambung dengan boost :: archive berada. Kamus ini menyimpan jalur asli ke file yang disalin, dan hash MD5 mereka. Di bawah ini adalah tanda terima dari DevicePath:
Sebagai epilog, beberapa rekomendasi:
- Tidak perlu membuka lampiran dalam surat dari penerima yang tidak dikenal, apalagi menyertakan skrip Microsoft Publisher.
- Tidak kalah berbahaya untuk mengklik tautan dalam surat dari pengirim yang tidak dikenal. Situs tujuan Anda dapat meng-host malware yang secara otomatis akan mengunduh ke PC Anda.
- Anda harus secara teratur memperbarui perangkat lunak, terutama Microsoft Windows dan Microsoft Office, yang akan menutup akses ke berbagai malware.