Apa selanjutnya setelah akun domain Windows dikompromikan?

Kami sedang mempersiapkan skenario ketika salah satu akun di domain dikompromikan — apa yang harus dilakukan selanjutnya?

Menonaktifkan akun akan menjadi jawaban masuk pertama saya, tetapi kami memiliki pentester di sini beberapa minggu yang lalu dan mereka dapat menggunakan login hash dari pengguna admin yang pergi beberapa bulan yang lalu.

Dua jawaban kami sejauh ini adalah:

Hapus akun dan buat kembali (buat SID baru tetapi juga lebih banyak drama untuk pengguna dan buat kami)
Ubah kata sandi minimal 3 kali dan nonaktifkan akun

Apa yang akan menjadi metode Anda, atau apa yang akan Anda rekomendasikan?

active-directory security

— JurajB
sumber

Jika akun admin yang disusupi, maka lanjutkan membuat lebih banyak akun admin untuk tujuan Anda sendiri. Jika akun priv (low user) rendah, lakukan pemindaian jaringan dan cari akun Admin untuk kompromi. Memiliki seorang pengguna biasa akan membantu Anda melakukan lebih banyak serangan "bertarget".

— blaughw

Apakah Anda mengatakan bahwa akun pengguna admin yang pergi beberapa bulan yang lalu tidak dinonaktifkan pada saat keberangkatan orang itu? Saya kira saya tidak melihat bagaimana contoh itu berbicara tentang keefektifan atau ketidakefektifan penonaktifan akun. Apa alasan untuk mengganti kata sandi 3 kali daripada sekali?

— Todd Wilcox

@ToddWilcox akun dinonaktifkan tepat ketika orang itu pergi dan grup dihapus (itu adalah praktik standar ketika orang pergi) namun mereka mengklaim mereka bisa mendapatkan akses menggunakannya.

— JurajB

Jadi itu tidak dihapus dengan benar - Anda ingin token kedaluwarsa dan akses untuk akun itu dihapus pada semua sistem

— Rory Alsop

Jawaban:

Jika hanya akun pengguna standar yang dikompromikan, maka mengubah kata sandi sekali dan membiarkan akun diaktifkan harus baik-baik saja. Hash tidak akan berfungsi setelah kata sandi diubah. Ini juga tidak akan berfungsi jika akun dinonaktifkan. Sebagai seorang pen-tester sendiri, saya ingin tahu apakah para pen-tester menggunakan tiket Kerberos. Dalam keadaan tertentu ini dapat terus berfungsi jika kata sandi diubah, atau jika akun dinonaktifkan ATAU bahkan dihapus (lihat tautan untuk mitigasi).

Jika akun administrator domain telah disusupi, maka itu benar-benar berakhir. Anda perlu menjadikan domain Anda offline, dan mengubah SETIAP kata sandi. Kata sandi akun krbtgt perlu diubah dua kali, jika tidak, penyerang masih dapat mengeluarkan tiket Kerberos yang valid dengan informasi yang telah mereka curi. Setelah Anda melakukan semua itu, Anda dapat mengembalikan domain Anda ke internet.

Terapkan kebijakan penguncian akun, sehingga kata sandi yang diubah tidak dapat ditebak. Jangan ganti nama akun Anda. Penyerang dapat dengan mudah mengetahui nama login.

Poin penting lainnya adalah melatih pengguna Anda. Mereka mungkin melakukan sesuatu yang tidak bijaksana yang berarti akun itu dikompromikan. Penyerang bahkan mungkin tidak tahu kata sandi, mereka mungkin hanya menjalankan proses sebagai akun itu. Misalnya, jika Anda membuka lampiran malware yang memberikan akses penyerang ke mesin Anda, mereka akan berjalan sebagai akun Anda. Mereka tidak tahu kata sandi Anda. Mereka tidak dapat memperoleh hash kata sandi Anda, kecuali jika Anda seorang administrator. Jangan biarkan pengguna berjalan sebagai admin lokal di workstation mereka. Jangan biarkan admin domain masuk ke workstation dengan hak admin domain - selamanya!

Tautan untuk info / mitigasi lebih lanjut:

https://blogs.microsoft.com/microsoftsecure/2015/02/11/krbtgt-account-password-reset-scripts-now-available-for-customers/

http://www.infosecisland.com/blogview/23758-A-Windows-Authentication-Flaw-Adows-DeletedDisabled-Accounts-to-Access-Corporate-Data.html

https://mva.microsoft.com/en-us/training-courses/how-to-avoid-golden-ticket-attacks-12134

— bao7uo
sumber

Bagaimana jika Anda bekerja di lingkungan yang relatif permisif, seperti akademisi? Anda mungkin berurusan dengan pengguna yang memiliki masa kerja dan tidak bersedia untuk "dilatih," dan karena mereka memiliki masa jabatan Anda tidak diizinkan untuk menyingkirkan mereka atau mengurangi hak istimewa mereka.

— Katherine Villyard

Saya selalu merekomendasikan praktik terbaik. Akan selalu ada beberapa jenis organisasi yang tidak dapat menerapkannya 100% Beberapa orang melihat diri mereka di atas hukum, dan beberapa organisasi melihat penguasaan / ego lebih penting daripada menerapkan kebijakan / keamanan secara adil dan seragam. Orang-orang dan organisasi tersebut harus bertanggung jawab atas konsekuensi tindakan mereka. Mari berharap organisasi-organisasi akademik itu tidak mencari penelitian penting yang bermanfaat bagi kepentingan asing .....

— bao7uo

Saya telah melakukan beberapa kursus MVA tentang tiket emas dan mitigasi pth tetapi pemahaman saya adalah bahwa ia mengingat 2 kata sandi, maka Anda perlu mengubahnya setidaknya dua kali, tidak hanya sekali. Bahkan skrip untuk krbtgt melakukannya dua kali.

— JurajB

tidak dapat mengedit di atas sehingga menambahkan: Bahkan skrip untuk krbtgt melakukannya dua kali. Bukankah pilihan terbaik (untuk akun pengguna) adalah mengubah kata sandi dua kali dan kemudian menonaktifkan akun?

— JurajB

You need to bring your domain offline. Itu mungkin bekerja untuk kantor kecil, tetapi tidak mungkin bahwa perusahaan besar hanya dapat mengambil domain / hutan offline.

— Greg Askew

mereka dapat menggunakan login hash dari pengguna admin yang meninggalkan beberapa bulan yang lalu.

Hash kredensial curian tidak berfungsi untuk akun yang dinonaktifkan, kecuali jika ada di komputer yang tidak terhubung ke jaringan. Proses masih perlu meminta tiket atau mengautentikasi dengan pengontrol domain. Tidak dapat melakukannya jika akun dinonaktifkan.

Anda perlu menonaktifkan akun administratif untuk mantan karyawan ketika mereka pergi.

— Greg Askew
sumber

Bagaimana hash kredensial curian membantu penyerang? Jika mereka tidak memiliki kata sandi yang sebenarnya, tidak ada cara untuk mendapatkan kembali kata sandi dari hash (kecuali untuk mendapatkan kata sandi kecil menggunakan tabel pelangi), benar? Tidak yakin apa yang saya lewatkan di sini.

— Chirag Bhatia - chirag64

@ ChiragBhatia-chirag64 Anda mengasumsikan bahwa skema otentikasi tahan terhadap replay. Mungkin tidak, dalam hal ini semua hash yang perlu Anda otentikasi.

— Jonas Schäfer

Bisakah Anda memberikan contoh di mana skema otentikasi Windows menggunakan hash sebenarnya daripada kata sandi teks? Maaf jika ini terdengar seperti pertanyaan bodoh, saya belum pernah melihat implementasi seperti itu sebelumnya (atau mungkin saya salah mengerti mekanisme otentikasi Windows)

— Chirag Bhatia - chirag64

@ ChiragBhatia-chirag64 en.m.wikipedia.org/wiki/Pass_the_hash

— Greg Askew

@GregAskew terima kasih, saya tidak tahu ini adalah hal dalam otentikasi Windows. Agak mengejutkan mereka tidak menggunakan sesuatu seperti SSL untuk mengirim kata sandi. Ini sepertinya masalah keamanan besar bagi saya.

— Chirag Bhatia - chirag64

Dengan asumsi akun pengguna standar, Anda mungkin ingin mempertimbangkan:

Ubah kata sandi.
Nonaktifkan akun.
Ganti nama akun (tersangka nama pengguna) dan buat akun baru untuk pengguna yang terpengaruh.
Tambahkan akun yang dicurigai ke grup keamanan "Pengguna yang dinonaktifkan / dikompromikan".

Untuk # 4, sudah ada kebijakan grup yang melakukan hal berikut:

Tolak akses ke komputer ini dari jaringan: "Dinonaktifkan / dikompromikan pengguna"
Tolak masuk melalui Layanan Desktop Jarak Jauh: "Dinonaktifkan / dikompromikan pengguna"
Tolak masuk secara lokal: "Dinonaktifkan / dikompromikan pengguna"

Untuk akun admin domain, seluruh jaringan Anda bersulang.

— Katherine Villyard
sumber

mengapa Anda menyarankan untuk mengganti kata sandi lebih dari satu kali?

— bao7uo

jika akun admin domain dikompromikan maka itu berarti setiap akun pengguna dikompromikan. apakah Anda ingin mereka mengganti nama setiap akun pengguna?

— bao7uo

@PHPaul: Bergantung pada serangan, jika akun masih digunakan, penggantian nama mungkin merupakan taktik yang valid. Dan tentu saja mereka tidak merekomendasikan untuk mengganti nama setiap akun.

— Greg Askew