Cara Terbaik untuk Melacak Enumeration Nama Pengguna Brute-Force / Gagal Username Mencoba AD

Kami memiliki Windows Server yang memiliki aplikasi yang berada di dalamnya, yang menggunakan kredensial domain saat masuk ke aplikasi. Selama tes pena baru-baru ini, penguji dapat menggunakan aplikasi untuk menghitung nama pengguna domain yang valid berdasarkan respons aplikasi (Ini memberikan respons yang berbeda untuk nama pengguna yang tidak valid vs kata sandi yang tidak valid).

Aplikasi sedang diperbaiki sehingga tidak mengungkapkan informasi ini, tetapi saya juga merasa kita harus mendeteksi serangan ini karena ada lebih dari 2000.000 upaya nama pengguna tidak valid dalam waktu singkat. Kami tidak melihatnya, bahkan ketika administrator kami mengawasi Active Directory dengan cermat. Rupanya kegagalan hanya muncul di log peristiwa lokal server tempat aplikasi diinstal.

Pertanyaan saya: 1) Apakah ada cara untuk mendapatkan Active Directory untuk mencatat permintaan nama pengguna yang gagal di lokasi pusat sehingga kami dapat melihat lonjakan di dalamnya?

2) Jika tidak, apa cara terbaik untuk memantau dan secara aktif mendeteksi jenis serangan ini di masa depan (Semoga tanpa harus membeli terlalu banyak peralatan baru).

Terima kasih atas bantuan Anda.

Pertanyaan yang bagus

Hal pertama yang pertama - saya menganggap sebagian besar "penguji penetrasi" sebagai skrip kiddies. Bias saya mungkin tidak adil atau akurat tetapi saya menempatkan disclaimer ini sehingga jika Anda mendeteksi sinisme dalam nada saya, Anda tahu dari mana asalnya. Saya tidak mengatakan tidak ada pentester yang terampil, tetapi ini adalah generalisasi saya.

(Tim biru seumur hidup!)

Pertanyaan saya: 1) Apakah ada cara untuk mendapatkan Active Directory untuk mencatat permintaan nama pengguna yang gagal di lokasi pusat sehingga kami dapat melihat lonjakan di dalamnya?

Anda tidak memberikan informasi yang cukup bagi siapa pun untuk dapat menjawab pertanyaan ini secara menyeluruh dan dengan keyakinan. Anda mengatakan aplikasi Anda ditemukan mengandung cacat yang memungkinkan penyerang untuk menghitung akun pengguna. Saya mencoba memahami dengan cara apa Anda merasa bahwa AD perlu melakukan pencatatan untuk aplikasi Anda .

Rupanya kegagalan hanya muncul di log peristiwa lokal server tempat aplikasi diinstal.

Rupanya kegagalan muncul di log peristiwa di server? Atau kegagalan lakukan muncul di event log di server? Jika demikian, apa sebenarnya yang dikatakan peristiwa itu? Siapa yang login? Aplikasi Anda? Atau Windows? Pergi mencari tahu dan saya mungkin dapat menambahkan klarifikasi tambahan untuk jawaban saya.

Saya akan pergi mengambil risiko di sini berdasarkan pada anggapan Anda bahwa peristiwa-peristiwa ini seharusnya telah dicatat oleh Active Directory entah bagaimana ... bagaimana jika pentester Anda sebenarnya tidak mengeksploitasi cacat pada aplikasi Anda sama sekali, tetapi malah menggunakan cacat yang sangat terkenal di Kerberos itu sendiri untuk menyebutkan nama pengguna? Kerberos sendiri berisi apa yang saya anggap sebagai cacat desain di mana penyerang dapat mencoba ribuan dan ribuan upaya "pra-otentikasi" (yaitu serangan brute force) dan KDC akan merespons secara berbeda tergantung pada apakah akun pengguna ada atau tidak. Ini bukan perilaku spesifik Direktori Aktif, tetapi berlaku juga untuk MIT Kerberos, Heimdal, dll. KDC akan merespons denganKDC_ERR_PREAUTH_REQUIREDjika nama pengguna yang valid disajikan tanpa data pra-auth, bahkan tanpa mencoba otentikasi yang sebenarnya. Dengan cara ini Anda dapat menghitung nama pengguna dari KDC. Tetapi karena penyerang (atau alat yang digunakan penyerang seperti KrbGuess - karena pentester berada pada kondisi terbaiknya ketika mereka menggunakan alat orang lain), tidak harus melanjutkan ke upaya otentikasi penuh, tidak ada yang dicatat karena tidak ada otentikasi yang sebenarnya telah dicoba!

Sekarang, ke pertanyaan Anda berikutnya:

2) Jika tidak, apa cara terbaik untuk memantau dan secara aktif mendeteksi jenis serangan ini di masa depan (Semoga tanpa harus membeli terlalu banyak peralatan baru).

Beberapa hal.

Pertama, ada produk berbayar tingkat perusahaan yang dirancang untuk mendeteksi serangan semacam ini (di antara banyak hal lain.) Banyak vendor menawarkan produk seperti itu, dan rekomendasi produk di luar topik untuk Serverfault, tetapi cukuplah untuk mengatakan bahwa mereka keluar sana. Banyak dari produk ini bekerja dengan mengharuskan Anda untuk mengkonfigurasi mirroring port antara pengontrol domain Anda dan "pengumpul data" ini sehingga mereka melihat dan menganalisis secara harfiah setiap paket yang masuk atau keluar dari pengontrol domain Anda.

(Maaf, itu agak jatuh pada klausa "tanpa membeli terlalu banyak barang baru" Anda.)

Hal lain yang mungkin membantu Anda adalah entri registri:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

LogLevel = 1

Didokumentasikan di sini .

Jika Anda mengaktifkan entri registri ini, Anda harus dibanjiri dengan peristiwa di log peristiwa keamanan Anda tentang kesalahan Kerberos yang menyebutkan bahwa pra-otentikasi Kerberos diperlukan. Contoh kejadian seperti itu:

A Kerberos Error Message was received:
 on logon session DOMAIN\serviceaccount
 Client Time: 
 Server Time: 12:44:21.0000 10/9/2012 Z
 Error Code: 0x19 KDC_ERR_PREAUTH_REQUIRED
 Extended Error: 
 Client Realm: 
 Client Name: 
 Server Realm: DOMAIN
 Server Name: krbtgt/DOMAIN
 Target Name: krbtgt/DOMAIN@DOMAIN
 Error Text: 
 File: e
 Line: 9fe
 Error Data is in record data.

Tapi ini mungkin atau mungkin tidak membantu Anda jika tidak menentukan dari mana tepatnya tsunami permintaan Kerberos berasal. Ini membawa kita kembali ke produk deteksi intrusi perusahaan yang saya sebutkan sebelumnya.

Dan jangan lupa Windows Event Forwarding yang dapat membuat server Anda meneruskan acara ke lokasi terpusat untuk dianalisis dengan alat apa pun yang Anda miliki.

Seluruh jawaban ini sejauh ini didasarkan pada protokol Kerberos, yang bahkan tidak bisa saya anggap remeh karena Anda memberikan begitu sedikit detail dalam posting Anda. Meskipun demikian, saya harap ini membantu setidaknya sedikit.

Ini adalah pertanyaan menarik yang ingin saya dengar jawabannya. Saya telah menemukan beberapa informasi yang mungkin bermanfaat bagi Doug, tetapi saya merasa itu mungkin tidak cukup. Orang lain mungkin dapat memberikan jawaban yang diperluas:

Login ke server tempat Anda ingin menyimpan informasi audit, Jalankan -> RSOP.MSC -> Konfigurasi Komputer -> Pengaturan Windows -> Pengaturan Keamanan -> Kebijakan Lokal -> Kebijakan Audit -> "Acara log masuk akun audit" & " Acara Logon Audit "

Eksplorasi untuk "peristiwa masuk akun" berbunyi:

Peristiwa logon akun audit

Pengaturan keamanan ini menentukan apakah OS mengaudit setiap kali komputer ini memvalidasi kredensial akun.

Peristiwa log masuk akun dihasilkan setiap kali komputer memvalidasi kredensial akun yang otoritatifnya. Anggota domain dan mesin yang tidak bergabung dengan domain berwenang untuk akun lokal mereka; pengontrol domain semuanya otoritatif untuk akun di domain. Validasi kredensial mungkin mendukung logon lokal, atau, dalam kasus akun domain Direktori Aktif pada pengontrol domain, mungkin mendukung logon ke komputer lain. Validasi kredensial tidak memiliki kewarganegaraan sehingga tidak ada peristiwa logoff yang sesuai untuk peristiwa logon akun.

Jika pengaturan kebijakan ini ditentukan, administrator dapat menentukan apakah akan mengaudit hanya keberhasilan, hanya kegagalan, baik keberhasilan maupun kegagalan, atau untuk tidak mengaudit peristiwa ini sama sekali (yaitu tidak ada keberhasilan maupun kegagalan).

Eksplorasi untuk "peristiwa masuk" berbunyi:

Peristiwa logon audit

Pengaturan keamanan ini menentukan apakah OS mengaudit setiap instance dari pengguna yang mencoba untuk masuk atau keluar ke komputer ini.

Acara logout dihasilkan setiap kali sesi logon login akun pengguna diakhiri. Jika pengaturan kebijakan ini ditentukan, administrator dapat menentukan apakah akan mengaudit hanya keberhasilan, hanya kegagalan, baik keberhasilan maupun kegagalan, atau untuk tidak mengaudit peristiwa ini sama sekali (yaitu tidak ada keberhasilan maupun kegagalan).

Anda pada dasarnya perlu mengaktifkan kebijakan itu, menetapkan pengaturan kebijakan dan memilih "gagal" jika Anda hanya ingin memantau upaya yang gagal. Jika Anda mau, Anda bisa memantau kesuksesan juga, tetapi itu mungkin membuatnya agak sulit untuk diurai jika Anda hanya khawatir mencari jenis serangan ini.

Jika Anda khawatir tentang konfigurasi serupa yang rentan terhadap sistem Anda, saya akan merekomendasikan melihat ke pengaturan STIG ( tautan ), ketika digunakan bersama dengan SCAP Scanner, itu benar-benar dapat membantu dalam menyoroti beberapa risiko yang mungkin ditimbulkan oleh organisasi Anda. menghadapi. Penampil STIG cenderung meningkatkan beberapa kesalahan positif, tetapi jika Anda membaca secara spesifik apa yang dimiliki masing-masing masalah, Anda mungkin menganggapnya sebagai non-starter.