Setiap hari di JSOC CERT kami menjumpai acara dari kotak pasir berbeda yang berfungsi sebagai bagian dari solusi AntiAPT pelanggan kami dan membiarkan ribuan file dari web dan lalu lintas email melewatinya. Perlu dicatat bahwa sistem Sandbox modern dalam pengembangannya berjalan lebih jauh dari sekadar mencegat panggilan sistem dalam Mode Kernel dan fungsi API dalam Mode Pengguna. Semakin banyak, mereka menggunakan hypervisor mereka sendiri, sebuah sistem untuk meniru aktivitas pengguna, instrumentasi dinamis, hashing dan pengelompokan bagian kode, analisis cakupan kode, dll. Berbagai macam teknologi menciptakan ilusi bahwa jika file tidak bekerja di kotak pasir dan tidak menunjukkan "wajah aslinya", maka ini mungkin APT atau teknologi inovatif untuk mendeteksi lingkungan virtual, yang belum disadari oleh komunitas IB. Tapi ...
Karena kita tidak tahu fitur internal dari pekerjaan kotak pasir komersial, dalam beberapa kasus kita melakukan pemeriksaan ulang - secara manual menganalisis sampel yang lulus tes. Baru-baru ini, kami telah menemukan beberapa kali bahwa beberapa kotak pasir komersial (untuk alasan obyektif, kami tidak bisa mengatakan yang mana) tidak mendeteksi file berbahaya tertentu selama analisis dinamis, dan jika penganalisa statis juga diam, file itu dilewati sama sekali.
Pemindaian kotak pasir berhasil mem-bypass keluarga malware terkenal seperti Pony, Loki dan Hawkeye. Hanya satu hal yang menyatukan mereka - mereka dilindungi oleh paket yang ditulis dalam Visual Basic.
Mengingat bahwa keluarga HPE ini telah lama bukan hal yang baru, vonis kotak pasir “positif” sangat menyedihkan. Oleh karena itu, kami memutuskan untuk menjelaskan prinsip umum pengoperasian pengepak ini dan pengamatan yang kami lakukan selama beberapa waktu.
Skema umum pekerjaan pengepak secara kondisional dibagi menjadi 4 tahap dan ditunjukkan dalam diagram di bawah ini.
Titik masuk file jahat terlihat khas dari aplikasi Visual Basic:
Kami menemukan berbagai opsi untuk paket ini, dan kode Wrapper VB sering berubah, tetapi tugas yang dilakukan tetap sama: mentransfer kontrol ke kode Tahap 1. Dalam sampel sebelumnya, kontrol ditransfer menggunakan fungsi API kelas Enum * (misalnya, EnumWindows, EnumCalendarInfo, dll.). e) dimana alamat Tahap 1 dari kode ditunjukkan sebagai parameter. Baru-baru ini, kami mengamati bahwa kontrol ditransfer secara langsung.
Tahap 1
Manajemen menerima kode Tahap 1. Kode ini tidak dienkripsi, tetapi dikaburkan. Metode kebingungan bervariasi dari sampel ke sampel, tetapi algoritma operasi umum tidak berubah:
- Siklus dengan banyak (termasuk sampah) instruksi yang menghasilkan kunci yang diperlukan untuk mendekode kode Tahap 2. Keunikan potongan kode ini adalah tidak ada fungsi Tidur, tetapi karena banyaknya iterasi, pelaksanaannya memakan waktu rata-rata 1-2 menit.
- Dekripsi (XOR reguler) dan transfer kontrol ke kode Tahap 2.
Tangkapan layar di bawah ini menunjukkan contoh metode kebingungan yang digunakan:
2 tahap
Tugas utama kode pada Tahap 2 adalah untuk memeriksa lingkungan dan menerapkan metode anti-debugging. Beberapa bagian kode dienkripsi (didekripsi sebelum eksekusi, dan setelah itu, dienkripsi kembali dengan algoritma XOR yang sama) untuk membuatnya sulit dideteksi dengan tanda tangan. Setelah dekripsi, fitur-fitur karakteristik terlihat, yang menurutnya kode Tahap 2 dapat dikenali dengan analisis manual.
Daftar cek cukup besar dan berbeda dalam versi berbeda dari pengemas, jadi kami akan memberikan beberapa metode yang ditemukan di semua versi, dengan tangkapan layar, dan pada akhirnya kami mencantumkan seluruh daftar di tabel.
1) GetTickCount + Tidur
Stempel waktu saat ini diambil, Tidur dipanggil selama 2 detik, setelah itu stempel waktu lain segera diambil.
Setelah itu, perbedaan antara tanda diperiksa (apakah 2 detik benar-benar berlalu).
2) SetErrorMode
Memeriksa operasi yang benar dari panggilan API SetErrorMode. Fungsi dipanggil dua kali berturut-turut dengan parameter 0x800 dan 0x0, setelah itu hasil panggilan kedua diperiksa: itu harus sama dengan 0x800.
3) SetLastError
Pertama, SetLastError disebut dengan parameter 0x5, setelah itu diperiksa bahwa nilai kode kesalahan terakhir dalam TEB diatur dengan benar (yaitu, itu adalah 0x5).
4) Memeriksa pergerakan kursor
Kode memasuki loop tanpa akhir menunggu mouse bergerak.
5) DbgBreakPoint dan DbgUiRemoteBreakin
Fungsi-fungsi ini dimodifikasi untuk mencegah debugger terhubung ke proses.
Teknik
| Komentar
|
GetTickCount + Sleep
| Memeriksa Cap waktu
|
SetErrorMode
| Memeriksa fungsi yang benar
|
SetLastError
| Memeriksa fungsi berfungsi dengan benar
|
GetCursorPos
| Periksa pergerakan kursor
|
Dbgbreakpoint
| Modifikasi fungsi untuk mencegah lampiran debugger
|
DbgUiRemoteBreakin
| Modifikasi fungsi untuk mencegah lampiran debugger
|
Penghapusan kait
| 5 byte pertama dari fungsi dipulihkan di ntdll.dll jika ada kait
|
NtSetInformationThread
| Parameter 0x11 (ThreadHideFromDebugger)
|
GetThreadContext + periksa DR
| Register debugger DR0-DR3, DR6, DR7 diperiksa.
|
Periksa breakpoints
| Instruksi INT3 (0xCC), int 3 (0xCD 0x03) dan ud2 (0x0F 0x0B) di awal beberapa fungsi diperiksa
|
cpuid (EAX = 0x0)
| Register EAX, ECX, EDX diperiksa
|
cpuid (EAX = 0x40000000)
| Register EAX, ECX, EDX diperiksa
|
cpuid (EAX = 0x1)
| ECX 31 bit dicentang
|
PEB (BeingDebugged)
| Nilai cek 0x1
|
PEB (NtGlobalFlag)
| Nilai yang diperiksa 0x70
|
NtQueryInformationProcess
| Dipanggil dengan flag ProcessDebugPort (0x7), ProcessDebugFlags (0x1F), ProcessDebugObjectHandle (0x1E)
|
Periksa nama proses
| String "sample", "sandbox", "virus", "malware", "self." Diperiksa
|
Jika semua teknik tahap 2 selesai, baris perintah diperiksa untuk kesesuaian dengan format khusus. Jika pemeriksaan gagal, maka tindakan berikut dilakukan:
1) Fungsi CreateProcess dipanggil dengan flag CREATE_SUSPENDED untuk memulai kembali proses saat ini. Dalam hal ini, baris perintah memiliki format yang diperlukan.
2) Menggunakan fungsi GetContextThread dan SetContextThread, titik masuk diubah ke yang baru, yang terletak di kode Tahap 1.
3) Ulangi langkah 1 dan 2 (termasuk siklus panjang dan semua pemeriksaan). Kali ini, pemeriksaan baris perintah berhasil dan proses berlanjut ke langkah berikutnya.
3 tahap
Pada tahap ini, tubuh virus utama didekripsi dan teknik Proses Pengosongan dilakukan pada proses saat ini, setelah itu kontrol ditransfer ke titik masuknya virus utama.
Pelajaran yang dipetik
Kami tidak dapat mengatakan dengan tepat apa yang menyebabkan kotak pasir ini atau itu dalam kasus ini, tetapi saya ingin percaya bahwa kemungkinan menggunakan teknik yang dijelaskan dalam artikel oleh malware telah disediakan oleh vendor untuk waktu yang lama, dan masalahnya hanya terletak pada penundaan waktu yang lama pada tahap pertama pekerjaan pengepak paket. .
Terlepas dari kenyataan bahwa kotak pasir modern sebagian besar diposisikan sebagai bagian dari sistem perlindungan terhadap serangan APT, pengamatan kami menunjukkan bahwa keluarga jahat yang dikenal masyarakat pun menembus infrastruktur dengan keteguhan yang patut ditiru. Karena tidak ada jaminan bahwa sampel yang melewati kotak pasir tidak akan memiliki beberapa teknik antivirus dalam arsenalnya, Anda tidak dapat mengandalkan banyak solusi perlindungan ini saja. Dalam kasus seperti itu, proses pemantauan yang dibangun dengan benar, termasuk peristiwa keamanan informasi dari host akhir, dapat memastikan respon tepat waktu dan meminimalkan potensi kerusakan.