bypass UAC (user admin control) full tutorial plus vidio execution !

Azharbase- hello slurr dalam posting ini kita akan melihat prinsip dasar yang terlibat dalam serangan bypass UAC (User Account Control). Saya tidak akan membahas lebih jauh tentang apa yang dikatakan Microsoft UAC atau tidak kecuali di sini di bagian pendahuluan. UAC, diperkenalkan dengan Windows Vista, memungkinkan pengguna Admin untuk mengoperasikan mesin Windows mereka dengan hak pengguna standar sebagai lawan dari hak Administratif.

Secara default, akun pengguna awal pada Windows adalah bagian dari grup Administrator, ini hanyalah persyaratan. Karena hal ini, pada zaman dahulu (sebelum era Vista), para pengembang cenderung berasumsi bahwa pengguna memiliki hak admin lokal dan sering kali mengembangkan aplikasi mereka secara sembarangan untuk memerlukan hak yang lebih tinggi. Baris resmi adalah bahwa UAC diperkenalkan sebagai cara untuk mengekang perilaku ini dan untuk memberikan kompatibilitas ke belakang.

Meskipun demikian, manfaat langsung UAC adalah melindungi pengguna Admin dari, atau memperingatkan mereka untuk, tindakan jahat, peningkatan, yang dilakukan oleh komponen perangkat lunak. Microsoft tidak akan setuju, tapi saya pikir UAC sebenarnya adalah mekanisme keamanan yang sangat mahir (jika kita lupa tentang masalah sisi-loading dll yang lazim!). Siapa pun yang ingin berdebat ini hanya perlu melihat beberapa perangkat malware canggih atau kerangka kerja eksploitasi seperti Metasploit / Cobalt Strike, yang semuanya

termasuk mekanisme untuk memintas UAC. Selain itu, jangan lupa bahwa Microsoft telah menambal sejumlah besar bypass, misalnya menggunakan WUSA untuk mengekstrak file CAB ke jalur tertentu. Sayang sekali bahwa perbaikan pemuatan samping yang solid tidak dapat diimplementasikan karena hal itu akan sangat meningkatkan keamanan pengguna akhir. Ngomong-ngomong, UAC selalu memicu perdebatan sengit, jadi saya tidak akan mengatakan apa-apa lagi tentang masalah ini. Mari kita melihat-lihat beberapa fitur "kompatibilitas" ini!

Auto-Elevation

Hal utama yang harus dipahami adalah bahwa token proses yang dibuat oleh pengguna Admin dilucuti dari hak-hak tertentu ketika proses itu diluncurkan secara normal sebagai lawan dari dengan hak istimewa yang ditinggikan (misalnya: Jalankan sebagai Administrator ..). Kami dapat dengan mudah memverifikasi ini dengan membuang hak istimewa token menggunakan Get-TokenPrivs atau dengan proses explorer Sysinternals. Tangkapan layar di bawah ini menunjukkan dua contoh "cmd.exe", satu diluncurkan secara normal dan satu diluncurkan sebagai Administrator.

Pada dasarnya, pengguna yang termasuk dalam grup Administrator mengelola mesin mereka dengan hak yang sama dengan pengguna lain. Jadi apa perbedaan sebenarnya antara pengguna privat tinggi dan rendah? Tidak terlalu banyak ketika turun ke sana, tindakan yang ditinggikan masih memerlukan perubahan token ini dan, tergantung pada pengaturan UAC, dapat memberi tahu pengguna / meminta kata sandi.

Namun yang terpenting, pada dua pengaturan UAC tengah, salah satunya adalah default, sejumlah program Windows akan terangkat secara otomatis jika pengguna termasuk dalam grup Administrator. Biner ini dapat diidentifikasi dengan membuang manifesnya seperti yang ditunjukkan di bawah ini.

Cara mudah untuk menemukan binari ini adalah dengan membuang string secara rekursif dan mencari "autoElevate> true". Logikanya di sini adalah bahwa binari ini ditandatangani oleh Microsoft; mengingat asal mereka dan bahwa pengguna adalah Administrator, tidak perlu meminta untuk meningkatkan (dengan kata lain itu adalah fitur kegunaan).

Ini masuk akal sampai Anda membuka monitor proses dan mencari tahu seberapa buruk biner berhasil memuat sumber daya yang mereka butuhkan (tidak hanya dll tetapi juga kunci registri). Sayangnya ini memberikan pengguna jahat dengan peluang pembajakan yang cukup. Contoh di bawah ini menunjukkan kasus yang diketahui dengan baik di mana MMC digunakan untuk meninggikan RSOP, RSOP pada gilirannya mencoba memuat “wbemcomn.dll” dengan integritas tinggi (= sebagai Administrator).

Hal yang konyol adalah bahwa, melihat output yang difilter, setidaknya ada tiga UAC "0days" lainnya di sini (..sigh). Jika ada yang ingin mengirimkan permintaan tarik ke Bypass-UAC, bunuh diri! Operasi File yang Ditinggikan Anda mungkin berpikir, "B33f telah kehilangan kelerengnya, dll ini berada di direktori aman"! Sama seperti binari yang kita diskusikan di atas, ada juga objek COM yang mengangkat-otomatis (operasi COM yang ditinggikan pantas mendapatkan pos mereka sendiri). Salah satu objek COM ini digunakan khusus untuk kita, IFileOperation. Objek COM ini berisi banyak metode berguna seperti salin / pindah / ganti nama / hapus untuk objek sistem file (file dan folder). Secara tradisional, penyerang menulis dll yang instantiate objek IFileOperation COM dan mengeksekusi metode yang memindahkan file penyerang ke direktori yang dilindungi (misalnya: C: \ Windows \ System32 \ wbem \ wbemcomn.dll seperti pada contoh di atas) .

Untuk mendapatkan objek COM untuk meninggikan secara otomatis dll disuntikkan ke dalam proses integritas sedang yang berjalan di direktori tepercaya, biasanya “explorer.exe” (-> fdwReason == DLL_PROCESS_ATTACH). Contoh sumber dll dapat ditemukan di @ParvezGHH posting di sini. Namun, ternyata, ada cara yang lebih fleksibel untuk menggunakan metode IFileOperation yang tidak akan memicu bel alarm dengan menyuntikkan dll di semua tempat. Objek COM mengandalkan Proses Status API (PSAPI) untuk mengidentifikasi proses yang sedang mereka jalankan. Lucunya PSAPI mem-parsing proses PEB untuk mendapatkan informasi ini tetapi penyerang dapat menangani proses mereka sendiri dan menimpa PEB untuk mengelabui PSAPI dan akibatnya setiap objek COM yang dipakai dari PID palsu (= mind blown)! Saya menulis PowerShell POC, Masquerade-PEB, untuk menggambarkan hal ini. Dalam contoh di bawah ini PowerShell disamarkan sebagai penjelajah dan proses penjelajah Sysinternals ternyata juga tertipu....

Studi Kasus: WinSxS, UAC 0day sepanjang hari Pengaturan UAC default benar-benar tidak lebih dari plasebo, terima kasih @ hFireF0X karena membuat saya sinis! Untuk studi kasus pertama kami, kami akan melihat masalah pemuatan dll Windows Side-By-Side (WinSxS) .. WinSxS diperkenalkan di Windows ME sebagai solusi untuk masalah yang disebut "dll."

Pada dasarnya ini mirip dengan cache rakitan global, ketika biner membutuhkan akses ke pustaka tertentu, ia dapat merujuk versi pustaka itu di manifesnya dan OS kemudian akan melanjutkan untuk memuat dll yang relevan dari folder WinSxS (C: \ Windows \ WinSxS). Untuk studi kasus kami, kami akan melihat binary Microsoft Remote Assistance yang dinaikkan secara otomatis (C: \ Windows \ System32 \ msra.exe). Di bawah ini kita dapat melihat manifes biner.

Perhatikan bagian ketergantungan, msra membutuhkan beberapa versi perpustakaan "Microsoft.Windows.Common-Controls". Mari kita lihat apa yang terjadi di monitor proses ketika kita menjalankan msra.

Pada titik tertentu, msra mencari direktori yang disebut "msra.exe.Local", ketika tidak menemukan folder itu mengakses "C: \ Windows \ WinSxS" dan memuat perpustakaan yang ditentukan dalam manifes itu. Folder dotlocal dapat digunakan, secara sah, oleh pengembang untuk tujuan debugging.

Bisakah Anda menebak apa yang terjadi ketika kami membuat struktur direktori berikut. # Kita dapat melakukan ini menggunakan metode objek IFileOperation COM yang ditinggikan C: \ Windows \ System32 \ | __> msra.exe.Lokal | ___> x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.10586.494_none_ea85e725b9ba5a4b

Begitu banyak * facepalm *, yang perlu kita lakukan untuk mem-bypass UAC pada saat ini adalah menggunakan objek COM IFileOperation untuk membuat folder itu dengan payload dll dan menjalankan msra dari baris perintah. Ini sedikit disederhanakan karena dll payload kemungkinan harus meneruskan beberapa ekspor dll tetapi Anda mendapatkan ide. Jika ada yang ingin mengirimkan permintaan tarik ke Bypass-UAC, bunuh diri! Alasan saya memilih WinSxS sebagai studi kasus adalah bahwa Anda benar-benar akan melihat masalah ini di mana-mana ketika Anda mulai melihat biner auto-elevating. Saya sangat menyarankan Anda membaca utas ini KernelMode.

Studi Kasus: Membajak Ole32.dll dengan .NET => Bypass-UAC Karena ada banyak bagian yang bergerak ke jenis bypass UAC (menggunakan COM yang ditinggikan), saya membuat kerangka kerja PowerShell untuk menangani semua pengangkatan berat.

Bypass-UAC memiliki beberapa komponen yang berbeda: (1) Masquerade-PEB yang menangani proses spoofing, (2) Invoke-IFileOperation yang mengekspos metode objek IFileOperation COM ke PowerShell dan (3) Emit-Yamabiko yang menjatuhkan payload dll. ke disk. Untuk studi kasus terakhir saya mencari UAC "0day" yang relatif sederhana, saya ingin sesuatu yang tidak mengharuskan saya untuk memperbarui Yamabiko dan itu akan berfungsi pada x32 / x64 Win7-Win10. Pada akhirnya saya memutuskan untuk menyalahgunakan perilaku beban .NET framework. Ada banyak cara untuk memicu perilaku pemuatan yang salah tetapi untuk mem-bypass UAC kita akan menggunakan MMC (apa pun * .msc akan dilakukan). MMC profiling: Mari kita lihat apa yang terjadi di monitor proses ketika kita meluncurkan "mmc gpedit.msc" (difilter pada: Baris perintah memiliki "mmc", nama tidak ditemukan dan path memiliki "dll"). Cuplikan layar di bawah ini menunjukkan hasil masing-masing pada Win 7 dan Win 10.

Win7

Win10

Ya, kedua versi OS memiliki beberapa entri menakutkan! Namun, dengan mengabaikan keanehan dan entri yang tidak tumpang tindih, kita dibiarkan dengan "MFC42LOC.DLL" dan "ole32.dll". MFC42LOC membutuhkan penyelidikan lebih lanjut, saya sudah melihatnya beberapa kali tetapi tampaknya tidak bermain bagus.

 Ole32 di sisi lain terbukti menjadi kandidat yang cocok. Pembajakan Ole32: Satu masalah yang perlu kita tangani adalah bahwa dll itu jelas dimuat dari direktori yang berbeda, penyelidikan singkat mengungkapkan bahwa ia mencari ole32 di folder versi .NET standar. Kita bisa mendapatkan versi itu menggunakan perintah PowerShell berikut. # Menangkan 7 PS C: \> [System.Reflection.Assembly] :: GetExecutingAssembly (). ImageRuntimeVersion v2.0.50727 # Menangkan 10 PS C: \> [System.Reflection.Assembly] :: GetExecutingAssembly (). ImageRuntimeVersion v4.0.30319 Masalah lainnya, yang tidak tampak, adalah bahwa proxy Yamabiko dll di Bypass-UAC membuka PowerShell tetapi PowerShell sendiri memicu bug pemuatan yang salah ini mengakibatkan kerang yang tidak terbatas (terangkat) muncul ...

Untuk menghindari perilaku ini kita harus mendeteksi bahwa payload kita Dll dimuat dan kemudian hapus sehingga hanya dijalankan sekali! Implementasi Bypass-UAC: Menambahkan metode ke Bypass-UAC sangat mudah, jika Anda ingin tahu lebih banyak, silakan periksa proyek di GitHub! Untuk menjalankan bypass kami, saya menambahkan metode berikut, semoga ini bisa lebih atau kurang jelas. Jangan ragu untuk meninggalkan komentar jika Anda memiliki pertanyaan!

'UacMethodNetOle32' {# Hybrid MMC method: mmc some.msc -> Microsoft.NET \ Framework [64] \ .. \ ole32.dll # Bekerja pada x64 / x32 Win7-Win10 (tidak ditambal) if ($ OSMajorMinor -lt 6.1) {echo "[!] OS Anda tidak mendukung metode ini!` n "Kembali} # Meniru explorer.exe echo" `n [!] Meniru peniru explorer.exe!" Masquerade-PEB -BinPath "C: \ Windows \ explorer.exe" if ($ DllPath) {echo "[>] Menggunakan proksi kustom dll .." echo "[+] Jalur Dll: $ DllPath"} else {# Tulis Yamabiko .dll ke disk echo "[>] Menjatuhkan proxy dll .." Emit-Yamabiko} # Dapatkan default .NET versi [String] $ Net_Version = [System.Reflection.Assembly] :: GetExecutingAssembly (). ImageRuntimeVersion # Dapatkan penghitungan PowerShell memproses $ PS_InitCount = @ (Get-Process -Name powershell) .Count # Ekspos objek COM IFileOperation Invoke-IFileOperation # Eksploitasi logika gema "[>] Melakukan peningkatan IFileOperation :: Operasi MoveItem .." # x32 / x64 .NET folder if ( $ x64) {$ IFileOperation.MoveItem ($ DllPath, $ ($ env: SystemRoot + '\ Microsoft.NET \ Framework64 \' + $ Net_Version + '\'), "ole32.dll")} else {$ IFileOperation.MoveItem ($ DllPath, $ ($ env: SystemRoot + '\ Microsoft.NET \ Framework \' + $ Net_Version + '\'), "ole32.dll")} $ IFileOperation.PerformOperations () echo "` n [?] Mengeksekusi mmc .. "IEX $ ($ env: SystemRoot + '\ System32 \ mmc.exe gpedit.msc') # Pindahkan Yamabiko kembali o% tmp% setelah dimuat untuk menghindari kerang yang tak terbatas! while ($ true) {$ PS_Count = @ (Get-Process -Name powershell) .Count if ($ PS_Count -gt $ PS_InitCount) {coba {# x32 / x64 .NET foler if ($ x64) {$ IFileOperation.MoveItem ( $ ($ env: SystemRoot + '\ Microsoft.NET \ Framework64 \' + $ Net_Version + '\ ole32.dll'), $ ($ env: Temp + '\'), 'ole32.dll')} else {$ IFileOperation.MoveItem ($ ($ env: SystemRoot + '\ Microsoft.NET \ Framework \' + $ Net_Version + '\ ole32.dll'), $ ($ env: Temp + '\'), 'ole32.dll') } $ IFileOperation.PerformOperations () break} catch {# Kadang-kadang IFileOperation melempar pengecualian # ketika dieksekusi dua kali berturut-turut, jalankan ulang ..}}} # Clean-up echo "[!] Artefak UAC: $ ​​($ env: Temp + '\ ole32.dll') `n"}

Tutup, kami memiliki bypass UAC baru yang berfungsi di mana-mana! Tangkapan layar di bawah ini menunjukkan pintasan pada Windows 8 (x64) dan Windows 10 (x32).

Win8 x64

Win10x32

Di samping catatan, ini adalah mekanisme ketekunan yang cukup bagus dengan akses tinggi. Jatuhkan pembungkus dll untuk ole32 di folder .NET framework dan jadwalkan apa pun yang menggunakan .NET untuk dijalankan saat startup / idle (mis: PowerShell).

Pikiran terakhir Jika Anda berhasil sejauh ini, saya pikir Anda dapat melihat mengapa Microsoft tidak mengakui bypass UAC (selain dari garis standar "Ini bukan fitur keamanan"). Jujur, saya pikir cara terbaik untuk mendapatkan UAC di jalur adalah dengan secara agresif menambal mekanisme yang memungkinkan penyerang untuk melakukan operasi penyalinan yang ditinggikan (seperti yang mereka lakukan dengan WUSA) dan membiarkan masalah sisi-loading dll seperti apa adanya.

Akhir kata, jangan bosen gaes baca nya...

Exsecution UAC video :

Subscribe my channel support me :

azharbasechannel

Support me subscribe

Baca->teliti->pelajari->praktek!

Thanks ^_^