IBo nefig: pengungkapan keamanan siber terbaik tahun 2020 menurut JSOC

Paruh pertama tahun ini akan segera berakhir, dan kami memutuskan untuk mengingat kasus paling menarik dari kehidupan JSOC yang kami temui tahun ini. Pertemuan dengan penjahat dunia maya "teman lama" di pelanggan baru, skrip jahat di Penjadwal Tugas dan teka-teki kurva konfigurasi penyeimbang - kami membaca dan menembus di bawah batas.





Bidikan dari serial South Park



Kami mengenalinya dengan tulisan tangannya



Selama keberadaan JSOC, kami menghadapi infrastruktur TI yang berbeda dan keinginan pelanggan yang berbeda untuk memantau cakupan lanskap TI mereka. Sering terjadi, misalnya, pelanggan hanya ingin memantau server, menghilangkan kesempatan untuk melihat apa yang terjadi di sekitar segmen yang dipantau. Pendekatan ini dapat mengakibatkan deteksi serangan terlambat, ketika sebagian besar infrastruktur telah disusupi. Dan jika pelanggan kami yang ada tidak memiliki situasi seperti itu, maka dalam proyek percontohan ini adalah cerita yang umum.



Jadi, selama salah satu uji coba, pelanggan sedang dalam proses membangun kembali lanskap TI-nya sendiri dan ingin melihat bagaimana SOC akan cocok dengan infrastruktur dan proses barunya. Karena berbagai keadaan di luar kendali kami, kami tidak memiliki satu sumber jaringan yang terhubung, yang manakapets seberapa besar hal itu membatasi kita dalam mendeteksi berbagai insiden. Hanya pengontrol domain, beberapa server Windows, server email, dan antivirus yang terhubung. Pilot lulus dengan cukup tenang dan merupakan standar bagi kami : beberapa malware ditemukan di infrastruktur, penggunaan TOR, dan RAT yang dilarang. Tetapi suatu hari, sejumlah besar aturan kami mulai berfungsi, di antaranya adalah aturan dari kategori Berburu Ancaman, yang mengotomatiskan proses mengidentifikasi jejak penyusup. Analis yang bertanggung jawab dengan cepat menyadari bahwa kasus itu berbau minyak tanah, dan bahkan menyadari dengan siapa dia berurusan.



Apa yang terjadi? Hal pertama yang kami lihat adalah menambahkan akun baru ke grup Admin Domain. Tetapi satu aturan lagi berfungsi, yaitu nama akun yang mencurigakan, yang telah kami temui. Seorang kenalan lama kami, seorang penyerang, ketika melakukan serangan, membuat dua akun yang tertulis dalam skripnya: dua nama ini "mengembara" dari satu korban ke korban lainnya - perubahan kecil hanya dapat disebabkan oleh aturan penamaan akun dari organisasi yang diserang. Kami telah bertemu dengannya berkali-kali saat menyelidiki insiden. Ini menyerang organisasi dari semua ukuran dan industri dengan metode yang sama, dan biasanya berakhir dengan mengenkripsi server utama perusahaan.



Sayangnya, mesin pertama yang disusupi berada di luar cakupan sumber yang terhubung, sehingga saat peluncuran skrip itu sendiri tidak dapat direkam. Setelah pembuatan akun, kami merekam perubahan aturan pada firewall lokal yang mengizinkan penggunaan alat administrasi jarak jauh tertentu, dan kemudian layanan agen dari alat tersebut dibuat. Omong-omong, antivirus yang digunakan pelanggan tidak mengenali alat ini, jadi kami mengontrolnya dengan membuat layanan yang sesuai dan memulai prosesnya.







Ceri di atas adalah distribusi utilitas enkripsi yang sah ke host yang dikompromikan. Dia tidak punya waktu untuk mengunggahnya ke semua pembawa acara. Penyerang "diusir" dari infrastruktur 23 menit setelah kejadian pertama memicu kejadian ini.



Tentu saja, saya dan pelanggan ingin mendapatkan gambaran lengkap tentang kejadian tersebut dan menemukan titik masuk bagi penyerang. Berdasarkan pengalaman kami, kami meminta log dari peralatan jaringan, tetapi, sayangnya, tingkat pencatatannya tidak memungkinkan kami untuk menarik kesimpulan apa pun. Namun, setelah menerima konfigurasi peralatan jaringan edge dari administrator, kami melihat yang berikut:



ip nat di dalam sumber static tcp "alamat abu-abu" 22 "alamat putih" 9922

ip nat di dalam sumber statis tcp "alamat abu-abu" 3389 "alamat putih" 33899



Dari situ disimpulkan bahwa, kemungkinan besar, salah satu server tempat NAT tersebut dikonfigurasi menjadi titik masuk. Kami menganalisis log dari server ini dan melihat otentikasi berhasil di bawah akun admin, meluncurkan Mimikatz dan kemudian meluncurkan skrip yang membuat administrator domain. Melalui insiden ini, pelanggan melakukan audit penuh atas aturan firewall, kata sandi, dan kebijakan keamanan dan mengidentifikasi beberapa kekurangan lagi dalam infrastruktur mereka. Dan saya juga mendapat pemahaman yang lebih sistematis tentang mengapa SOC dibutuhkan dalam organisasinya.



Router jarak jauh dan rumah - surga peretas



Jelas, dalam kondisi perusahaan yang beralih ke remote control, memantau kejadian di perangkat akhir menjadi jauh lebih sulit. Ada dua alasan utama:



  1. sejumlah besar karyawan menggunakan perangkat pribadi untuk bekerja;
  2. VPN , .


Ini juga merupakan fakta yang jelas bahwa bahkan penyerang berpengalaman pun menjadi tertarik pada jaringan rumah, karena ini sekarang merupakan titik penetrasi yang ideal ke dalam perimeter perusahaan.



Salah satu pelanggan kami memiliki 90% karyawan yang beralih ke mode kerja jarak jauh, dan semuanya memiliki laptop domain - oleh karena itu, kami dapat terus memantau perangkat akhir - tentu saja, dengan mempertimbangkan poin 2 di atas. Dan poin inilah yang melawan kami.



Salah satu pengguna selama isolasi diri tidak terhubung ke VPN hampir sepanjang hari. Pada akhirnya, dia masih membutuhkan akses ke sumber daya perusahaan. Dia menggunakan VPN, kami mendapatkan log dari mesin kerjanya dan melihat sesuatu yang aneh. Sebuah tugas yang mencurigakan dibuat di Penjadwal Tugas: itu meluncurkan file tertentu setiap hari Rabu pukul 17:00. Mereka mulai mengerti.







Jejak tersebut mengarah ke dua file dokumen: salah satunya membuat tugas, yang kedua adalah file yang dapat dieksekusi dalam tugas. Pengguna mengunduhnya dari Google Drive.



Pada tahap pencarian kami, layanan keamanan pelanggan telah terhubung dan memulai penyelidikan internal. Ternyata pengguna menerima surat ke surat pribadinya, yang berisi tautan ke Google Drive, tempat dokumen diunduh. Secara bertahap kami sampai ke router pengguna - tentu saja, login / kata sandi untuk itu adalah admin \ admin (seolah-olah sebaliknya?). Tetapi hal yang paling menarik ditemukan dalam pengaturan server DNS router: alamat IP salah satu negara Eropa ditunjukkan di sana. Kami memasukkan alamat ini ke VirusTotal - sebagian besar sumber menyala merah. Setelah penyelidikan berakhir, pelanggan mengirimkan dua file kepada kami untuk penelitian, dan kami melihat bahwa file yang diluncurkan oleh tugas mulai "berjalan" melalui berbagai direktori dan mengunduh data dari sana.



Kronologi kejadiannya adalah sebagai berikut: penyerang memperoleh akses ke router pengguna, mengubah pengaturan di dalamnya, menentukan servernya sendiri sebagai server DNS. Untuk beberapa waktu saya melihat "korban" saya dan mengirim surat ke surat pribadi pengguna. Pada langkah ini, kami menemukannya, tidak memungkinkan kami untuk masuk jauh ke dalam infrastruktur perusahaan.



Mereka juga merusak milik mereka



Pada tahap awal bekerja dengan outsourcing SOC, kami selalu merekomendasikan untuk menghubungkan sumber acara secara bertahap, sehingga pelanggan di sisinya melakukan debug proses, dengan jelas menentukan area tanggung jawab dan, secara umum, terbiasa dengan format ini. Jadi, di salah satu pelanggan baru kami, pertama-tama kami menghubungkan sumber dasar, seperti pengontrol domain, firewall, proxy, berbagai alat keamanan informasi, mail, server DNS dan DHCP dan beberapa server lain yang berbeda. Kami juga menawarkan untuk menghubungkan mesin dari administrator kantor pusat di tingkat log lokal, tetapi pelanggan mengatakan bahwa sejauh ini tidak perlu dan dia mempercayai adminnya. Di sini, sebenarnya, kisah kita dimulai.



Suatu hari, peristiwa berhenti mendatangi kami. Kami mengetahui dari pelanggan bahwa, diduga, karena serangan DDoS skala besar, pusat datanya "jatuh" dan sekarang dia melakukan pemulihan. Ini segera menimbulkan banyak pertanyaan - lagipula, sistem perlindungan DDoS terhubung dengan kami.



Analis segera mulai menggali log-nya, tetapi tidak menemukan sesuatu yang mencurigakan di sana - semuanya dalam mode normal. Kemudian saya melihat log jaringan dan memperhatikan pekerjaan aneh penyeimbang, yang mendistribusikan beban antara dua server yang memproses lalu lintas masuk. Penyeimbang beban tidak mendistribusikan beban, tetapi sebaliknya, hanya mengarahkannya ke satu server hingga "tersendat", dan baru kemudian mengalihkan aliran ke node kedua. Tetapi jauh lebih menarik bahwa begitu kedua server jatuh, lalu lintas ini bergerak lebih jauh dan "meletakkan" semuanya secara umum. Saat pekerjaan restorasi sedang berlangsung, pelanggan mengetahui siapa yang melakukan kesalahan. Ini, tampaknya, adalah akhir dari insiden: ini tidak ada hubungannya dengan keamanan informasi dan hanya terkait dengan tangan yang bengkok.kesalahan administrator. Tetapi pelanggan memutuskan untuk menyelidiki sampai akhir. Setelah memeriksa AWP admin, dia menemukan bahwa semua log OS telah dihapus dari calon pengrajin yang sama, dan kemudian meminta kami untuk memeriksa tindakannya selama seminggu terakhir.



Menariknya, administrator ini menjadi subjek penyelidikan kami beberapa minggu sebelum kejadian. Dia mengakses dari jaringan lokal ke host eksternal pada port 22. Kemudian kejadian ini ditandai sebagai sah, karena admin tidak dilarang menggunakan sumber daya eksternal untuk mengotomatiskan pekerjaan mereka sendiri atau menguji pengaturan peralatan baru. Mungkin hubungan antara jatuhnya pusat data dan panggilan ke host eksternal tidak akan pernah diperhatikan, tetapi ada insiden lain: panggilan dari salah satu server segmen pengujian ke host yang sama di Internet yang sebelumnya telah dihubungi oleh admin - insiden ini juga dicatat oleh pelanggan sebagai sah. Setelah melihat aktivitas administrator, kami melihat permintaan konstan ke server ini dari segmen pengujian dan meminta pelanggan untuk mengujinya.



Dan ini dia, denouement - server web ditempatkan di server yang mengimplementasikan fungsionalitas parsial dari situs web utama pelanggan. Ternyata admin berencana mengalihkan sebagian dari lalu lintas yang masuk ke situs palsunya untuk mengumpulkan data pengguna untuk tujuannya sendiri.



Hasil



Terlepas dari kenyataan bahwa ini sudah tahun 2020, banyak organisasi masih tidak mematuhi kebenaran umum tentang keamanan informasi, dan tidak bertanggung jawabnya staf mereka sendiri dapat menyebabkan konsekuensi bencana.



Berkaitan dengan hal tersebut, berikut beberapa tipnya:



  1. Jangan pernah mengekspos RDP dan SSH ke luar, bahkan jika Anda menyembunyikannya di belakang port lain - itu tidak membantu.
  2. Sesuaikan level logging setinggi mungkin untuk mempercepat deteksi penyusup.
  3. Threat Hunting . TTPs , . .
  4. , . , , .


, Solar JSOC (artkild)



All Articles