Get best of the week

Sekali pada pentest, atau Bagaimana memecahkan semuanya dengan bantuan seorang ahli urologi dan Roskomnadzor


Artikel ini didasarkan pada pentest yang sangat sukses, yang dilakukan oleh spesialis Group-IB beberapa tahun yang lalu: sebuah kisah terjadi yang mengklaim sebagai adaptasi film di Bollywood. Sekarang, mungkin, reaksi pembaca akan mengikuti: "Oh, artikel PR lain, sekali lagi ini ditarik, seberapa baik mereka, jangan lupa untuk membeli pentest." Ya, di satu sisi, benar. Namun, ada sejumlah alasan mengapa artikel ini muncul. Saya ingin menunjukkan apa yang sebenarnya dilakukan pentester, betapa menarik dan non-sepele pekerjaan ini bisa, keadaan lucu apa yang dapat berkembang pada proyek, dan yang paling penting, untuk menunjukkan materi langsung dengan contoh nyata.

Untuk mengembalikan keseimbangan kesopanan di dunia, setelah beberapa saat kita akan menulis tentang pentest, yang tidak berjalan. Kami menunjukkan bagaimana proses yang telah mapan di perusahaan dapat melindungi dari seluruh jajaran serangan, bahkan yang dipersiapkan dengan baik, hanya karena proses ini ada dan benar-benar berfungsi.

Pelanggan dari artikel ini, juga, semuanya baik-baik saja secara umum, setidaknya lebih baik dari 95% pasar di Federasi Rusia, menurut perasaan kami, tetapi ada sejumlah nuansa kecil yang membentuk rantai panjang peristiwa, yang pertama-tama menghasilkan laporan panjang tentang karya tersebut. , dan kemudian ke artikel ini.

Jadi, siapkan popcorn, dan selamat datang di detektif. Saya memberikan kesempatan kepada Pavel Suprunyuk , Direktur Teknis Audit dan Consulting Group-IB.

Bagian 1. Dokter Pochkin


2018 tahun. Ada pelanggan - perusahaan IT berteknologi tinggi, yang dengan sendirinya melayani banyak pelanggan. Dia ingin mendapatkan jawaban atas pertanyaan: apakah mungkin, tanpa pengetahuan dan akses awal, bekerja melalui Internet, untuk mendapatkan hak administrator untuk domain Direktori Aktif? Tidak ada rekayasa sosial yang menarik ( eh, tetapi sia-sia ), mereka tidak secara khusus akan mengganggu pekerjaan, tetapi mereka dapat secara tidak sengaja memuat ulang server yang bekerja aneh, misalnya. Tugas tambahan adalah mengidentifikasi sebanyak mungkin vektor serangan lain sehubungan dengan perimeter eksternal. Perusahaan secara teratur melakukan tes seperti itu, dan sekarang batas waktu untuk tes baru. Kondisinya hampir khas, memadai, dapat dimengerti. Turun.

Ada nama pelanggan - biarlah "Perusahaan", dengan situs utama www.company.ru. Tentu saja, pelanggan dipanggil secara berbeda, tetapi dalam artikel ini semuanya akan direpersonalisasikan.
Saya melakukan intelijen jaringan - Saya mencari tahu alamat dan domain mana yang terdaftar oleh pelanggan, menggambar diagram jaringan, bagaimana layanan didistribusikan ke alamat-alamat ini. Saya mendapatkan hasilnya: lebih dari 4000 alamat IP langsung. Saya melihat-lihat domain di jaringan ini: untungnya, sebagian besar adalah jaringan yang ditujukan untuk pelanggan pelanggan, dan mereka tidak menarik minat kita secara resmi. Pelanggan meyakini hal yang sama.

Masih ada satu jaringan dengan 256 alamat, yang saat ini sudah ada pemahaman tentang distribusi domain dan subdomain dengan alamat IP, ada informasi tentang port yang dipindai, yang berarti Anda dapat melihat layanan untuk yang menarik dengan mata Anda. Secara paralel, semua jenis pemindai diluncurkan pada alamat IP yang dapat diakses dan secara terpisah - di situs web.

Ada banyak layanan. Ini biasanya menyenangkan bagi pentester dan antisipasi kemenangan cepat, karena semakin banyak layanan, semakin besar bidang serangan dan semakin mudah untuk menemukan artefak. Melihat sekilas pada situs web menunjukkan bahwa kebanyakan dari mereka adalah antarmuka web dari produk-produk terkenal dari perusahaan dunia besar yang mengatakan bahwa mereka tidak senang dengan Anda. Mereka meminta nama pengguna dan kata sandi, dari ambang batas mereka mengguncang bidang untuk memasukkan faktor kedua, mereka meminta sertifikat klien TLS atau mengirimnya ke Microsoft ADFS. Beberapa tidak tersedia dari Internet. Untuk beberapa, Anda jelas perlu memiliki klien berbayar khusus untuk tiga gaji atau untuk mengetahui URL yang tepat untuk masuk. Kami akan menghilangkan satu minggu lagi dari keputusasaan bertahap dalam proses mencoba “menerobos” perangkat lunak sesuai versi untuk kerentanan yang diketahui, mencari konten tersembunyi di jalur web dan membocorkan akun dari layanan pihak ketiga seperti LinkedIn,mencoba untuk memilih kata sandi untuk mereka, serta menggali kerentanan di situs web yang dijelaskan sendiri - omong-omong, menurut statistik, ini adalah vektor serangan eksternal yang paling menjanjikan hingga saat ini. Segera saya perhatikan senapan bioskop, yang kemudian ditembakkan.

Jadi, ada dua situs yang menonjol dari ratusan layanan. Situs-situs ini memiliki satu kesamaan: jika Anda tidak melakukan pengintaian jaringan yang cermat berdasarkan domain, tetapi lihat "di dahi" untuk port terbuka atau meracuni pemindai kerentanan pada rentang IP yang diketahui, maka situs-situs ini akan menjauh dari verifikasi, mereka tidak akan terlihat tanpa mengetahui nama DNS. Mungkin mereka terlewatkan lebih awal, setidaknya, dan alat otomatis kami tidak menemukan masalah di dalamnya, bahkan jika mereka diatur langsung pada sumber daya.

Omong-omong, tentang fakta bahwa scanner yang diluncurkan sebelumnya umumnya ditemukan. Biarkan saya mengingatkan Anda: bagi sebagian orang, "pentest" sama dengan "pemindaian otomatis". Dan pemindai pada proyek ini tidak mengatakan apa-apa. Yah, kerentanan sedang menunjukkan maksimum (3 dari 5 dalam hal bahaya): beberapa layanan memiliki sertifikat TLS buruk atau algoritma enkripsi yang ketinggalan zaman, dan sebagian besar situs memiliki Clickjacking. Tetapi dalam hal ini Anda tidak akan sampai pada tujuan. Mungkin, pemindai akan lebih bermanfaat di sini, tetapi izinkan saya mengingatkan Anda: pelanggan itu sendiri dapat membeli program-program semacam itu dan menguji dirinya dengan program-program itu, dan menilai dari hasil yang membosankan, ia sudah memeriksanya.

Kembali ke situs "abnormal". Yang pertama adalah sesuatu seperti Wiki lokal di alamat non-standar, tetapi biarkan wiki.company [.] Ru berada di artikel ini. Dia juga segera meminta nama pengguna dan kata sandi, tetapi sudah melalui NTLM di browser. Untuk pengguna, ini terlihat seperti jendela pertapa yang meminta nama pengguna dan kata sandi. Dan ini adalah praktik buruk.

. NTLM - . — Active Directory. company.ru, «» DNS-. , - , , - . — NTLM (, ?), «» , . , . — , . — . — , , . — pass-the-hash-. ADFS .

Ada satu fitur buruk dari produk Microsoft: bahkan jika Anda belum secara khusus menerbitkan NTLM tersebut, itu akan menjadi instalasi default di OWA dan Lync, setidaknya.

Ngomong-ngomong, penulis artikel ini dengan cara yang sama secara tidak sengaja memblokir sekitar 1000 akun karyawan dari satu bank besar hanya dalam satu jam dan kemudian memiliki penampilan yang agak pucat. Layanan TI bank juga pucat, tetapi semuanya berakhir dengan baik dan memadai, kami bahkan dipuji bahwa kami adalah orang pertama yang menemukan masalah ini dan memicu koreksi yang cepat dan menentukan.
Situs kedua memiliki alamat "jelas-beberapa-nama belakang.company.ru". Ditemukan melalui Google, sesuatu seperti ini di halaman 10. Desainnya mulai pertengahan 2000, dan orang terhormat melihat dari halaman utama, seperti ini:


Lalu dia mengambil bingkai dari "Dog's Heart", tapi percayalah, itu mirip, bahkan skema warna dalam warna yang sama. Biarkan situs itu disebut preobrazhensky.company.ru .

Itu adalah situs pribadi ... seorang ahli urologi. Menjadi menarik apa yang dilakukan situs ahli urologi pada subdomain perusahaan teknologi tinggi. Penggalian cepat di Google menunjukkan bahwa dokter ini adalah salah satu pendiri salah satu badan hukum pelanggan kami dan bahkan menyumbang sekitar 1.000 rubel modal terdaftar. Situs ini mungkin dibuat bertahun-tahun yang lalu, dan sumber daya server pelanggan digunakan sebagai hosting. Situs ini telah lama kehilangan relevansinya, tetapi karena beberapa alasan dibiarkan bekerja untuk waktu yang lama.

Dalam hal kerentanan, situs web itu sendiri aman. Ke depan, saya akan mengatakan bahwa itu adalah seperangkat statika - halaman html sederhana dengan sisipan ilustrasi dalam bentuk ginjal dan kandung kemih. "Menghancurkan" situs seperti itu tidak berguna.

Tetapi server web di bawahnya lebih menarik. Dilihat oleh header HTTP Server, ada IIS 6.0, yang berarti bahwa Windows 2003 digunakan sebagai sistem operasi. Pemindai sebelumnya mengungkapkan bahwa situs web khusus urologis ini, tidak seperti host virtual lainnya di server web yang sama, merespons perintah PROPFIND, yaitu, WebDAV bekerja di sana. Omong-omong, pemindai mengeluarkan informasi ini dengan tanda Info (dalam bahasa pemindai melaporkan ini adalah bahaya terendah) - hal-hal seperti itu biasanya dilewati begitu saja. Dalam kombinasi, ini memberikan efek yang menarik, yang terungkap hanya setelah penggalian lain ke dalam Google: kerentanan buffer overflow yang langka terkait dengan satu set Shadow Brokers, yaitu CVE-2017-7269, yang sudah memiliki exploit siap. Dengan kata lain, itu akan menjadi bencana jika Anda memiliki Windows 2003 dan WebDAV berjalan di IIS.Meskipun bekerja dalam produksi Windows 2003 pada 2018, ini dengan sendirinya merupakan bencana.

Eksploitasi berakhir di Metasploit dan segera diuji dengan beban yang mengirim permintaan DNS ke layanan terkontrol - Burp Collaborator secara tradisional digunakan untuk menjebak pertanyaan DNS. Anehnya, itu bekerja pertama kali: brengsek diterima di DNS. Kemudian ada upaya untuk membuat koneksi back-end melalui port 80 (yaitu, koneksi jaringan dari server ke penyerang, dengan akses ke cmd.exe pada host korban), tetapi kemudian kegagalan terjadi. Sambungan tidak datang, dan setelah upaya operasi ketiga, situs, bersama dengan semua gambar yang menghibur, menghilang untuk selamanya.

Biasanya ini diikuti oleh surat dengan gaya "pelanggan, bangun, kami telah menjatuhkan segalanya." Tetapi kami diberitahu bahwa situs tersebut tidak ada hubungannya dengan proses bisnis dan bekerja di sana secara umum, tidak jelas mengapa, seperti seluruh server, dan bahwa kami dapat menggunakan sumber daya ini sesuka kami.
Setelah sekitar satu hari, situs itu tiba-tiba mulai bekerja sendiri. Setelah membangun stand dari WebDAV pada IIS 6.0, saya menemukan bahwa pengaturan default adalah me-restart alur kerja IIS setiap 30 jam. Yaitu, ketika kontrol keluar dari kode shell, alur kerja IIS berakhir, kemudian restart beberapa kali sendiri dan kemudian beristirahat selama 30 jam.

Karena pertama kali bekconnect di tcp gagal, saya menghapus masalah ini ke port yang tertutup. Artinya, ia menyarankan adanya beberapa firewall yang tidak membiarkan koneksi keluar. Saya mulai menjalankan kode shell yang mengurutkan banyak port tcp dan udp, tidak ada efek. Koneksi terbalik dimuat melalui http (s) dari Metasploit - meterpreter / reverse_http tidak bekerja. Tiba-tiba, koneksi ke port 80 yang sama terjalin, tetapi segera putus. Dia menulisnya untuk tindakan IPS masih imajiner, yang tidak suka lalu lintas meterpreter. Mengingat fakta bahwa koneksi tcp murni ke port 80 gagal, tetapi http berhasil, saya menyimpulkan bahwa proxy http entah bagaimana dikonfigurasikan dalam sistem.

Mencoba bahkan meterpreter melalui DNS (terima kasihd00kieatas upayanya, menyelamatkan banyak proyek), mengingat kesuksesan pertama, tetapi ia bahkan tidak bekerja di stand - kode shell terlalu tebal untuk kerentanan ini.

Pada kenyataannya, itu terlihat seperti ini: 3-4 upaya untuk menyerang dalam 5 menit, kemudian menunggu selama 30 jam. Jadi selama tiga minggu berturut-turut. Saya bahkan menyiapkan pengingat agar tidak membuang waktu. Selain itu, ada perbedaan dalam perilaku lingkungan pengujian dan pertempuran: ada dua eksploitasi serupa untuk kerentanan ini, satu dari Metasploit, yang kedua dari Internet, yang diperbaiki dari versi Shadow Brokers. Jadi, pada pertempuran itu hanya Metasploit yang berhasil, di stand - hanya yang kedua, yang semakin rumit men-debug dan menghancurkan otak.

Pada akhirnya, kode shell terbukti efektif, yang mengunduh file exe dari server tertentu melalui http dan menjalankannya pada sistem target. Shellcode cukup kecil untuk muat, dan setidaknya itu berhasil. Karena server TCP sama sekali tidak menyukai lalu lintas dan http (s) diperiksa untuk meterpreter, saya memutuskan bahwa cara tercepat adalah dengan mengunduh file exe yang berisi DNS-meterpreter melalui shellcode ini.

Di sini muncul lagi masalah: ketika mengunduh file-exe dan, seperti yang ditunjukkan oleh upaya, apa pun yang terjadi, unduhannya terputus. Sekali lagi, beberapa jenis perangkat perlindungan antara server saya dan ahli urologi tidak suka lalu lintas http dengan exe di dalamnya. Sepertinya solusi "cepat" untuk mengubah shellcode sehingga mengaburkan lalu lintas http dengan cepat, sehingga data biner abstrak ditransfer alih-alih exe. Akhirnya, serangan itu berhasil, kontrol datang melalui saluran DNS yang tipis:


Segera menjadi jelas bahwa saya memiliki hak paling sederhana untuk alur kerja IIS yang memungkinkan saya untuk tidak melakukan apa pun. Ini adalah tampilannya di konsol Metasploit:


Semua metodologi pentest sangat menyarankan bahwa Anda perlu meningkatkan hak ketika mendapatkan akses. Biasanya saya tidak melakukan ini secara lokal, karena akses pertama dianggap hanya sebagai titik masuk jaringan, dan kompromi mesin lain pada jaringan yang sama biasanya lebih mudah dan lebih cepat daripada meningkatkan hak istimewa pada host yang ada. Tapi ini bukan masalahnya, karena saluran DNS sangat sempit dan itu tidak akan memungkinkan lalu lintas untuk menjelajah.

Dengan asumsi bahwa server ini dengan Windows 2003 tidak diperbaiki dari kerentanan MS17-010 yang terkenal, saya tunneling traffic ke port 445 / TCP melalui meterpreter DNS tunnel ke localhost (ya, ini juga mungkin) dan mencoba untuk menjalankan exe yang sebelumnya diunduh melalui kerentanan. Serangannya berhasil, saya mendapatkan koneksi kedua, tetapi dengan hak istimewa SISTEM.


Menariknya, server masih berusaha melindungi terhadap MS17-010 - ia telah menonaktifkan layanan jaringan yang rentan pada antarmuka eksternal. Ini benar-benar melindungi terhadap serangan melalui jaringan, tetapi serangan dari dalam localhost berhasil, karena Anda tidak bisa begitu saja mengambil dan dengan cepat mematikan SMB di localhost.
Selanjutnya, detail menarik baru terungkap:

  1. Memiliki izin SISTEM, Anda dapat dengan mudah menginstal kembali-terhubung melalui TCP. Jelas, larangan TCP langsung secara eksklusif merupakan masalah pengguna terbatas IIS. Spoiler: Lalu lintas pengguna IIS entah bagaimana dibungkus dengan Proxy ISA lokal di kedua arah. Bagaimana tepatnya ini tidak direproduksi.
  2. Saya berada di "DMZ" tertentu (dan ini bukan domain Direktori Aktif, tetapi WORKGROUP) - kedengarannya logis. Tetapi alih-alih alamat IP pribadi ("abu-abu") yang diharapkan, saya cukup "putih", persis sama dengan yang saya serang sebelumnya. Ini berarti bahwa perusahaan sudah sangat tua untuk dunia pengalamatan IPv4 sehingga mampu mempertahankan zona DMZ di 128 alamat “putih” tanpa NAT sesuai dengan skema, seperti yang diilustrasikan dalam manual Cisco 2005.

Karena server sudah lama, Mimikatz dijamin untuk langsung bekerja dari memori:


Saya mendapatkan kata sandi administrator lokal, saya tunnel traffic RDP melalui TCP dan saya masuk ke desktop yang nyaman. Karena Anda bisa melakukan apa saja dengan server, saya menghapus antivirus, saya menemukan bahwa server dapat diakses dari Internet hanya pada port TCP 80 dan 443, dan 443 tidak sibuk. Saya menaikkan server OpenVPN ke 443, menambahkan fungsi NAT untuk lalu lintas VPN saya dan mendapatkan akses langsung ke jaringan DMZ dalam bentuk tidak terbatas melalui OpenVPN saya. Patut dicatat bahwa ISA, dengan beberapa fitur IPS non-disable, memblokir lalu lintas saya dengan pemindaian port, yang harus diganti dengan RRAS yang lebih sederhana dan lebih fleksibel. Jadi, pentester terkadang masih harus mengatur semuanya.


Pembaca yang penuh perhatian akan bertanya: "Dan apa situs kedua - wiki dengan otentikasi NTLM, yang sudah begitu banyak ditulis?" Tentang itu lebih jauh.

Bagian 2. Apakah Anda masih tidak mengenkripsi? Lalu kami pergi ke Anda sudah di sini


Jadi, ada akses ke segmen jaringan DMZ. Anda harus pergi ke administrator domain. Hal pertama yang terlintas dalam pikiran adalah untuk secara otomatis memeriksa keamanan layanan di dalam segmen DMZ, terlebih lagi karena mereka sekarang jauh lebih terbuka untuk penelitian. Gambaran umum dalam uji penetrasi: perimeter eksternal lebih terlindungi daripada layanan internal, dan ketika Anda mendapatkan akses ke infrastruktur besar, jauh lebih mudah untuk mendapatkan hak diperpanjang dalam domain hanya karena domain ini mulai dapat diakses untuk alat, dan kedua, selalu ada beberapa masalah kritis dalam infrastruktur untuk beberapa ribu host.

Saya memuat pemindai pada DMZ melalui terowongan OpenVPN, saya menunggu. Saya membuka laporan - lagi tidak ada yang serius, ternyata seseorang berjalan dengan cara yang sama kepada saya. Langkah selanjutnya adalah memeriksa bagaimana host berkomunikasi dalam jaringan DMZ. Untuk melakukan ini, sebagai permulaan, Wireshark reguler diluncurkan dengan mendengarkan permintaan siaran, terutama ARP. Paket ARP dikumpulkan sepanjang hari. Ternyata beberapa gateway digunakan di segmen ini. Ini akan berguna nanti. Merekatkan data pada data tanggapan-permintaan ARP dan data pemindaian port, saya menemukan titik-titik keluaran lalu lintas pengguna dari dalam jaringan lokal di samping layanan-layanan yang sebelumnya dikenal, seperti web dan surat.

Karena saat ini saya tidak memiliki akses ke sistem lain dan tidak ada satu akun untuk layanan perusahaan, diputuskan untuk mengambil setidaknya beberapa akun dari lalu lintas menggunakan ARP Spoofing.

Cain & Abel diluncurkan di server urologis. Dengan mempertimbangkan arus lalu lintas yang teridentifikasi, pasangan yang paling menjanjikan dipilih untuk serangan "man in the middle", kemudian dengan peluncuran jangka pendek selama 5-10 menit, dengan timer untuk memulai kembali server jika terjadi "pembekuan", beberapa lalu lintas jaringan diterima. Seperti dalam lelucon, ada dua berita:

  1. Bagus: banyak kredensial tertangkap dan serangan secara keseluruhan berhasil.
  2. Buruk: semua kredensial berasal dari pelanggan sendiri. Memberikan layanan dukungan, spesialis pelanggan terhubung ke layanan pelanggan yang tidak selalu memiliki enkripsi lalu lintas yang dikonfigurasi.

Akibatnya, saya mendapatkan banyak kredensial yang tidak berguna dalam konteks proyek, tetapi jelas menarik sebagai peragaan bahaya serangan. Router perbatasan dari perusahaan besar dengan telnet, meneruskan debugging http-port ke CRM internal dengan semua data, akses langsung ke RDP dari Windows XP pada jaringan lokal dan obskurantisme lainnya. Ternyata semacam Supply Chain Compromise sesuai dengan matriks MITER .

Juga menemukan peluang yang menyenangkan untuk mengumpulkan email dari lalu lintas, sesuatu seperti ini. Ini adalah contoh surat jadi yang beralih dari pelanggan kami ke port SMTP kliennya, lagi-lagi, tanpa enkripsi. Andrei tertentu meminta namanya untuk mengirim ulang dokumentasi, dan diletakkan di cloud disk dengan nama pengguna, kata sandi, dan tautan dalam satu surat balasan:


Ini adalah pengingat lain bahwa Anda perlu mengenkripsi semua layanan. Tidak diketahui siapa dan kapan akan membaca dan menerapkan secara khusus data Anda - penyedia, administrator sistem perusahaan lain, atau pentester semacam itu. Saya diam bahwa banyak orang dapat dengan mudah mencegat lalu lintas yang tidak dienkripsi.

Meskipun sukses nyata, ini tidak dibawa lebih dekat ke tujuan. Tentu saja mungkin untuk duduk lama dan mendapatkan informasi yang berharga, tetapi bukan fakta bahwa itu akan muncul di sana, dan serangan itu sendiri sangat berisiko dalam hal integritas jaringan.

Setelah menggali lagi dalam layanan, sebuah ide menarik muncul di benak saya. Ada sebuah utilitas yang disebut Responder (mudah untuk menemukan contoh aplikasi dengan nama ini), yang, dengan "meracuni" permintaan siaran, memicu koneksi melalui berbagai protokol seperti SMB, HTTP, LDAP, dll. dengan cara yang berbeda, maka setiap orang yang terhubung diminta untuk mengotentikasi dan menyesuaikan sehingga otentikasi melewati NTLM dan dalam mode transparan untuk korban. Paling sering, seorang penyerang dengan demikian mengumpulkan jabat tangan NetNTLMv2 dan dari mereka, menurut kamus, dengan cepat memulihkan kata sandi domain pengguna. Saya menginginkan sesuatu seperti ini, tetapi pengguna duduk "di belakang dinding", atau lebih tepatnya, mereka dipisahkan oleh firewall, dan di WEB mereka pergi melalui cluster proxy Blue Coat.

Ingat, saya menetapkan bahwa nama domain Active Directory bertepatan dengan domain "eksternal", yaitu company.ru? Jadi, Windows, lebih tepatnya Internet Explorer (dan Edge, dan Chrome), memungkinkan pengguna untuk mengotentikasi secara transparan dalam HTTP melalui NTLM, jika mereka menganggap bahwa situs tersebut berada dalam "Zona Intranet". Salah satu tanda "Intranet" adalah panggilan ke alamat IP "abu-abu" atau nama DNS pendek, yaitu tanpa titik. Karena server dengan IP "putih" dan nama DNS preobrazhensky.company.ru siap digunakan, dan mesin domain biasanya mendapatkan akhiran domain Direktori Aktif melalui DHCP untuk menyederhanakan entri nama, mereka hanya perlu menulis URL preobrazhensky di bilah alamatsehingga mereka menemukan jalan yang benar ke server urologis yang dikompromikan, tidak lupa bahwa itu sekarang disebut "Intranet". Artinya, pada saat yang sama memberi saya pengguna jabat tangan NTLM tanpa sepengetahuannya. Tetap membuat browser klien berpikir tentang kebutuhan mendesak untuk mengakses server ini.

Utilitas hebat Intercepter-NG datang untuk menyelamatkan (terima kasihIntercepter) Itu memungkinkan Anda untuk mengubah lalu lintas saat bepergian dan bekerja dengan baik pada Windows 2003. Bahkan ada fungsi terpisah untuk memodifikasi hanya file JavaScript dalam arus lalu lintas. Direncanakan semacam Cross-Site Scripting besar-besaran.

Blue Coat proksi yang melaluinya pengguna mengakses WEB global yang di-cache secara berkala. Dengan mencegat lalu lintas, jelas bahwa mereka bekerja sepanjang waktu, tanpa henti meminta statika yang sering digunakan untuk mempercepat tampilan konten selama jam sibuk. Selain itu, BlueCoat memiliki User-Agent tertentu, yang dengan jelas membedakannya dari pengguna yang masih hidup.

Javascript disiapkan, yang dengan bantuan Intercepter-NG pada malam hari menghabiskan seluruh jam menerapkan setiap jawaban dengan file JS untuk Blue Coat. Script melakukan hal berikut:

  • Mendeteksi browser saat ini oleh User-Agent. Jika itu Internet Explorer, Edge atau Chrome - itu berhasil.
  • Menunggu hingga DOM halaman terbentuk.
  • Saya menyisipkan gambar yang tidak terlihat dengan atribut src dari tipe preobrazhensky ke DOM : 8080 / NNNNNNNN.png, di mana NNN adalah angka yang berubah-ubah sehingga BlueCoat tidak melakukan cache.
  • Tetapkan variabel bendera global tempat injeksi dibuat dan Anda tidak perlu lagi menyisipkan gambar.

Browser mencoba memuat gambar ini, pada port 8080 dari server yang dikompromikan, ia menunggu terowongan TCP ke laptop saya, di mana Responder yang sama diluncurkan, yang memerlukan login NTLM dari browser.


Dilihat oleh log Responder, di pagi hari orang-orang datang untuk bekerja, menyalakan stasiun kerja mereka, kemudian mulai mengunjungi server urologis secara massal dan tanpa disadari, tidak lupa untuk "menggabungkan" jabat tangan NTLM. Jabat tangan menghujani sepanjang hari dan mengumpulkan materi dengan jelas untuk serangan pemulihan kata sandi yang terkenal sukses. Ini adalah apa yang tampak seperti log Responder:

Kunjungan rahasia besar-besaran ke server urologis oleh pengguna

Anda mungkin sudah memperhatikan bahwa keseluruhan cerita ini dibangun berdasarkan prinsip "semuanya baik-baik saja, tetapi ada yang mengecewakan, lalu ada yang mengatasi, dan kemudian semuanya menjadi sukses". Jadi, ada yang mengecewakan. Dari lima ratus jabat tangan yang unik, tidak ada yang terungkap. Dan ini mempertimbangkan fakta bahwa bahkan pada laptop dengan prosesor yang mati, jabat tangan NTLMv2 ini berhasil dengan kecepatan beberapa ratus juta upaya per detik.

Saya harus mempersenjatai diri dengan teknik mutasi kata sandi, kartu grafis, kamus lebih tebal dan menunggu. Setelah beberapa lama, beberapa akun dengan kata sandi dalam bentuk “Q11111111 ... .1111111q” dibuka, yang menunjukkan bahwa semua pengguna pernah dipaksa untuk membuat kata sandi yang sangat panjang dengan karakter huruf yang berbeda, yang seharusnya rumit. Tapi Anda tidak bisa hanya gagal pengguna berpengalaman, dan dengan cara ini ia membuatnya lebih mudah diingat. Secara total, sekitar 5 buah dibuka, dan hanya satu dari mereka yang memiliki hak berharga untuk layanan.

Bagian 3. Roskomnadzor menyerang balik


Jadi, akun domain pertama diterima. Jika pada titik ini Anda tidak tertidur karena pembacaan yang lama, Anda mungkin akan ingat bahwa saya menyebutkan layanan yang tidak memerlukan faktor otentikasi kedua: ini adalah wiki dengan otentikasi NTLM. Tentu saja, hal pertama yang mereka lakukan adalah masuk. Menggali basis pengetahuan internal dengan cepat membawa hasil:

  • Perusahaan memiliki jaringan WiFi dengan otentikasi akun domain dengan akses ke jaringan lokal. Dengan kumpulan data saat ini, ini sudah merupakan vektor serangan yang berfungsi, tetapi Anda harus pergi ke kantor dengan kaki Anda dan menempatkan diri Anda di suatu tempat di kantor pelanggan.
  • , , … « » , . «» «» . , DMZ.

Tentu saja, "faktor kedua" segera ditambahkan ke akun yang dikompromikan sebagai aplikasi di ponsel saya. Ada sebuah program yang dapat mengirim permintaan push ke telepon dengan keras dengan tombol "setujui" / "setujui", atau tampilkan kode OTP di layar secara diam-diam untuk input independen selanjutnya. Selain itu, metode pertama seharusnya menjadi satu-satunya instruksi yang benar, tetapi tidak berhasil, tidak seperti metode OTP.

Dengan "faktor kedua" yang rusak, saya berhasil masuk ke email Outlook Web Access dan mengakses Citrix Netscaler Gateway dari jarak jauh. Di Outlook, kejutan menunggu di surat:


Dalam bidikan langka ini, Anda dapat melihat bagaimana Roskomnadzor membantu pentester.

Ini adalah bulan-bulan pertama setelah kunci kipas Telegram yang terkenal, ketika seluruh jaringan ke ribuan alamat menghilang dari akses tanpa dapat dihindari . Menjadi jelas mengapa push tidak bekerja segera dan mengapa "korban" saya tidak membunyikan alarm karena mereka mulai menggunakan akunnya di jam buka.

Mereka yang terbiasa dengan Citrix Netscaler membayangkan bahwa itu biasanya diimplementasikan sedemikian rupa sehingga memungkinkan untuk menyampaikan kepada pengguna hanya antarmuka gambar, berusaha untuk tidak memberinya alat untuk meluncurkan aplikasi pihak ketiga dan mentransfer data, dengan segala cara membatasi tindakan melalui cangkang kontrol standar. Menurut pekerjaan saya, saya hanya mendapat 1C:


Setelah berjalan sedikit di antarmuka 1C, saya menemukan bahwa ada modul pemrosesan eksternal di sana. Mereka dapat dimuat dari antarmuka, dan mereka akan dieksekusi pada klien atau server, tergantung pada hak dan pengaturan.

Saya meminta teman-teman programmer 1C untuk membuat pemrosesan yang akan mengambil string dan menjalankannya. Di 1C, peluncuran prosesnya terlihat seperti ini (diambil dari Internet). Setuju, sintaks bahasa 1C menyerang orang berbahasa Rusia dengan kedekatannya?



Pemrosesan dieksekusi dengan sempurna, ternyata Pentester menyebut "shell" - Internet Explorer diluncurkan melaluinya.


Sebelumnya, alamat suatu sistem ditemukan dalam surat yang memungkinkan Anda memesan tiket ke wilayah tersebut. Saya memesan pass jika saya harus menggunakan vektor serangan melalui WiFi.


Di Internet, mereka mengatakan bahwa di kantor pelanggan masih ada katering gratis yang lezat, tetapi saya masih lebih suka mengembangkan serangan melalui situs jarak jauh, lebih tenang.

AppLocker diaktifkan pada server aplikasi dengan Citrix, tetapi itu dilewati. Meterpreter yang sama dimuat dan mulai melalui DNS, karena versi http tidak ingin terhubung, dan saya tidak tahu alamat proxy internal saat itu. Ngomong-ngomong, sejak saat ini, pentest eksternal pada dasarnya berubah menjadi yang internal.

Bagian 4. Hak admin untuk pengguna - ini buruk, p-nyatnenko?


Hal pertama yang dilakukan Pentester ketika dia mengendalikan sesi pengguna domain adalah mengumpulkan semua informasi tentang hak-hak di domain. Ada semacam utilitas BloodHound, yang secara otomatis memungkinkan Anda mengunduh informasi tentang pengguna, komputer, grup keamanan melalui protokol LDAP dari pengontrol domain, dan informasi tentang pengguna mana yang baru-baru ini masuk dan siapa administrator lokal melalui SMB.

Teknik khas untuk mengambil hak administrator domain tampak disederhanakan seperti siklus tindakan monoton:

  • Kami pergi ke komputer domain, di mana ada hak administrator lokal, berdasarkan akun domain yang sudah diambil.
  • Mimikatz , Kerberos NTLM , . lsass.exe . Windows 2012R2/Windows 8.1 .
  • , . . - .

"End of Cycle;" seperti yang ditulis oleh programmer 1C di sini.

Jadi, pengguna kami ternyata menjadi administrator lokal hanya pada satu host dengan Windows 7, yang namanya adalah kata "VDI", atau "Virtual Desktop Infrastructure", mesin virtual pribadi. Mungkin, perancang layanan VDI menyiratkan bahwa karena VDI adalah sistem operasi pribadi pengguna, biarkan pengguna kemudian mengubah lingkungan perangkat lunak, sesuai keinginan Anda, toh tuan rumah dapat "diisi ulang". Saya juga berpikir bahwa, secara umum, idenya bagus, saya pergi ke host VDI pribadi ini dan membuat soket di sana:

  • Saya menginstal klien OpenVPN di sana, yang membuat terowongan melalui Internet ke server saya. Klien harus melalui Blue Coat dengan otentikasi domain, tetapi OpenVPN mengatasi, seperti yang mereka katakan, di luar kotak.
  • Diinstal pada VDI OpenSSH. Nah, sungguh, apa ini Windows 7 tanpa SSH?

Beginilah tampilannya. Saya mengingatkan Anda bahwa semua ini harus dilakukan melalui Citrix dan 1C:


Salah satu teknik untuk mempromosikan akses ke komputer tetangga adalah memeriksa kata sandi administrator lokal untuk kecocokan. Di sini keberuntungan sedang menunggu segera: hash NTLM administrator lokal default (yang tiba-tiba disebut Administrator) mendekati host VDI tetangga, yang ada beberapa ratus, melalui serangan pass-the-hash. Tentu saja, serangan itu segera menyerang mereka.
Kemudian administrator VDI menembak kaki mereka dua kali:
  • Pertama kali mesin VDI tidak dijalankan oleh LAPS, pada dasarnya menyimpan kata sandi administrator lokal yang sama dari gambar yang secara besar-besaran dikerahkan ke VDI.
  • — , pass-the-hash . , , — .
Mengapa layanan SSH di Windows itu? Sangat sederhana: sekarang server OpenSSH tidak hanya menyediakan perintah shell interaktif yang nyaman tanpa mengganggu pekerjaan pengguna, tetapi juga proxy socks5 pada VDI. Melalui kaus kaki ini, saya terhubung melalui SMB dan mengumpulkan akun dalam cache dari semua ratusan mesin VDI ini, lalu mencari jalur ke administrator domain dalam grafik BloodHound. Dengan ratusan host yang saya miliki, saya menemukan cara ini dengan cukup cepat. Hak administrator domain telah diperoleh.

Ini adalah gambar dari Internet, menunjukkan pencarian yang serupa. Tautan menunjukkan siapa administrator dan siapa yang memasukkan di mana.


By the way, ingat kondisi dari awal proyek - "jangan terapkan rekayasa sosial." Jadi, saya mengusulkan untuk merenungkan berapa banyak seluruh Bollywood ini akan dipotong dengan efek khusus, jika seseorang dapat menerapkan phishing dangkal. Tetapi secara pribadi saya sangat tertarik untuk melakukan semua ini. Saya harap Anda tertarik membaca ini. Tentu saja, tidak setiap proyek terlihat begitu menarik, tetapi pekerjaan secara keseluruhan sangat membingungkan dan tidak mandek.

Mungkin, seseorang akan memiliki pertanyaan: bagaimana melindungi diri sendiri? Bahkan dalam artikel ini, banyak teknik yang dijelaskan, administrator Windows bahkan tidak tahu banyak dari mereka. Namun, saya mengusulkan untuk melihatnya dari sudut pandang prinsip-prinsip usang dan langkah-langkah keamanan informasi:

  • jangan gunakan perangkat lunak yang ketinggalan jaman (ingat Windows 2003 di awal?)
  • jangan biarkan sistem yang tidak perlu dihidupkan (mengapa situs urologis itu?)
  • periksa sendiri kata sandi pengguna untuk kekuatan (jika tidak tentara ... pentester akan melakukan ini )
  • Tidak memiliki kata sandi yang sama untuk akun yang berbeda (kompromi VDI)
  • dan lainnya

Tentu saja, ini sangat sulit untuk diterapkan, tetapi dalam artikel selanjutnya kita akan menunjukkan dalam prakteknya bahwa ini sangat mungkin.

More articles:


All Articles