Alat pengembang · Encoder & decoder Base64
Cara memecahkan kode perintah Base64 PowerShell yang mencurigakan tanpa menjalankannya
· Mengapa itu penting
base64 keamanan
Penyerang menggunakan Base64 untuk menyembunyikan skrip dari pemeriksaan biasa. Postingan ini menunjukkan cara mendekode payload -EncodedCommand tanpa menjalankannya, mengapa outputnya mungkin terlihat aneh di decoder UTF-8, dan apa yang harus dicari.
Tugas terjadwal dengan argumen karakter 2,000 — tempat munculnya perintah yang disandikan dan mengapa perintah tersebut merupakan tanda bahaya
Admin sistem menemukan tugas terjadwal dengan argumen 2,000 karakter -EncodedCommand yang terlihat mencurigakan. Tugas ini berjalan pada akun layanan dengan hak istimewa tinggi.
Godaan untuk menempelkan perintah ke PowerShell dan menjalankannya untuk melihat fungsinya adalah berbahaya; jika perintah tersebut berbahaya, menjalankannya akan membahayakan sistem. Pendekatan yang lebih aman adalah dengan memecahkan kode Base64 secara lokal dan membaca hasilnya sebagai teks sebelum memutuskan apakah akan menjalankan sesuatu. Posting ini menjelaskan cara mendekode perintah PowerShell dengan aman tanpa menjalankannya, mengapa output mungkin terlihat kacau dalam decoder UTF-8 standar, dan apa yang harus dicari untuk menilai apakah suatu perintah aman atau mencurigakan.
Decode, jangan pernah mengeksekusi — aturan yang menjaga keamanan analisis, dan mengapa decoder khusus browser adalah pilihan yang tepat
Wawasan utamanya adalah PowerShell menggunakan pengkodean UTF-16LE untuk -EncodedCommand, bukan UTF-8, jadi setiap byte lainnya adalah nol yang ditafsirkan oleh alat standar sebagai terminator nol. Aturan untuk menganalisis kode yang mencurigakan sederhana saja: decode, jangan pernah mengeksekusi. Hal ini berlaku untuk perintah yang dikodekan Base64, skrip terkompresi, skrip dari sumber yang tidak tepercaya, dan apa pun dalam jaringan pengkodean yang tidak dikenal. Mengeksekusi skrip adalah point of no return; setelah dijalankan, perubahan pada sistem telah terjadi, akses telah diberikan, dan data telah dieksfiltrasi.
Mendekode dan membaca skrip sebagai teks memungkinkan Anda mengevaluasinya sebelum langkah yang tidak dapat diubah. Aturan kedua adalah menggunakan alat yang berjalan secara lokal dan tidak membuat permintaan jaringan. Dekoder berbasis browser sangat ideal karena portabel, tidak memerlukan perangkat lunak tambahan, dan menyimpan muatan mencurigakan di perangkat Anda tanpa mengunggahnya ke server mana pun. Jika alat tersebut adalah jenis yang diposkan ke layanan dekoder jarak jauh, jangan gunakan alat tersebut; muatannya kemudian diekspos ke layanan itu. Parameter PowerShell -EncodedCommand menerima string Base64 yang, ketika didekodekan, berisi skrip PowerShell.
Mengapa byte yang didekode terlihat tidak seperti teks UTF-8 — periksa pola byte UTF-16LE dalam hex daripada meminta alat teks UTF-8 ini untuk menafsirkannya
Namun, PowerShell tidak menggunakan pengkodean UTF-8 untuk ini; ia menggunakan UTF-16LE (little-endian UTF-16). Dalam UTF-16, setiap karakter ASCII direpresentasikan sebagai dua byte: kode karakter diikuti dengan byte nol. Huruf A adalah 41 00 dalam hex. Huruf B adalah 42 00. String seperti Hello muncul sebagai 48 00 65 00 6C 00 6C 00 6F 00 dalam UTF-16LE byte. Jika ini dikodekan Base64, hasilnya berisi bentuk semua byte yang dikodekan, termasuk semua angka nol. Penguraian kode dengan dekoder UTF-8 standar menghasilkan teks kacau atau terpotong pada byte nol pertama karena UTF-8 memperlakukan byte nol sebagai terminator string.
Outputnya tampak seperti Halo, bukan Halo, dengan karakter yang tampak acak atau teks hilang. Contoh praktis menunjukkan masalah dan solusinya. Misalkan perintah PowerShell mengkodekan string sederhana Write-Host Hello. PowerShell UTF-16LE-mengkodekan ini ke byte termasuk semua nol, Base64-mengkodekan byte dan menghasilkan string panjang seperti VwByAGkAdABlAC0ASwBvAHMAaAAgACIASABlAGwAbABvACIA. Salin string ini ke encoder & decoder Base64 di browser Anda dan klik Decode. Dekoder default akan mencoba menafsirkan hasilnya sebagai teks UTF-8 dan menghasilkan keluaran yang rusak atau terpotong karena angka nol yang disematkan.
Contoh praktis: mendekode contoh perintah yang disandikan yang tidak berbahaya - membaca teks melewati byte nol yang disisipkan
Solusinya adalah dengan menggunakan tampilan hex. Beralih ke tampilan hex dan Anda melihat byte: 57 00 72 00 69 00 74 00 65 00 2D 00 4B 00 6F 00 73 00 68 00 20 00 22 00 48 00 65 00 6C 00 6C 00 6F 00 22 00. Membaca byte tersebut sebagai UTF-16LE pasangan menghasilkan W-r-i-t-e---K-o-s-h---H-e-l-l-o-. Dengan pengalaman Anda bisa membaca UTF-16LE hex secara langsung, atau Anda dapat menulis byte ke file dan mendekodekannya dengan skrip PowerShell atau Python yang berjalan secara lokal.
Pendekatan praktisnya adalah dengan memperhatikan polanya dan mengingat bahwa PowerShell menggunakan UTF-16LE. Saat Anda memecahkan kode PowerShell -EncodedCommand di browser dan hasilnya terlihat salah, lihat tampilan hex, bukan tampilan teks. Tampilan hex menampilkan setiap byte satu per satu. Setiap karakter ASCII muncul sebagai dua byte dengan angka nol di antaranya. Jika byte mengeja perintah berbahaya seperti Akun Admin Baru, pencarian dns terbalik, atau ekspor kredensial keamanan, perintah tersebut mencurigakan. Jika byte mengeja sesuatu yang tidak berbahaya seperti daftar direktori atau skrip sederhana, perintah tersebut kemungkinan tidak berbahaya.
Encoding dan kompresi bertingkat — Base64 di dalam Base64, dan aliran gzip yang tidak dapat Anda baca sebagai teks
Tampilan hex lebih sulit dibaca dibandingkan teks biasa, namun lebih aman daripada menebak dari keluaran UTF-8 yang rusak. Pengkodean dan kompresi bertingkat menambah kompleksitas analisis malware. Perintah PowerShell mungkin mengkodekan Base64 string Base64 lainnya, atau mengompresi skrip dengan gzip lalu mengkodekan Base64 hasilnya. Dalam skenario bersarang Anda memecahkan kode Base64 bagian luar, membaca hasilnya dan menemukan bahwa itu adalah base64 itu sendiri. Dekode juga dan lanjutkan hingga Anda menemukan teks yang dapat dibaca atau format biner yang tidak dapat Anda tafsirkan. Gzip dan format kompresi lainnya dimulai dengan byte ajaib (1F 8B untuk gzip) yang terlihat dalam tampilan hex.
Jika Anda mendekode Base64 dan tampilan hex dimulai dengan 1F 8B, byte adalah aliran terkompresi yang memerlukan dekompresi. Encoder & decoder Base64 menunjukkan hex kepada Anda, membantu Anda mengidentifikasi pola-pola ini tanpa mengeksekusi apa pun. Payload yang dikompresi atau dikodekan lebih lanjut mencurigakan karena menambahkan lapisan kebingungan.
Apa yang harus dicatat untuk laporan insiden — teks yang didekodekan, sumber, dan hash, bukan payload itu sendiri
Perintah yang sah jarang memerlukan beberapa langkah pengkodean. Mencatat temuan untuk laporan insiden memerlukan disiplin dan akurasi. Tuliskan string Base64 persis yang Anda analisis, di mana Anda menemukannya, dan kapan. Jika Anda memecahkan kodenya dan menemukan perintah yang mencurigakan, jelaskan perintahnya tetapi jangan sertakan skrip lengkap dalam laporan; naskahnya mungkin rumit atau panjang.
Sertakan hash (SHA-256) dari skrip yang didekodekan sehingga temuannya dapat diverifikasi dan dilacak. Jika perintah tersebut jelas-jelas berbahaya atau menggunakan teknik eksploitasi yang diketahui, libatkan tim respons insiden dan keamanan sebelum mengambil tindakan apa pun. Jangan pernah menjalankan perintah sendiri untuk melihat fungsinya. Jika petugas tanggap darurat perlu menjalankannya untuk pengujian, mereka melakukannya di lingkungan sandbox yang dapat menampung segala kerusakan. Tugas Anda adalah memecahkan kode dan menilai risiko pada jarak yang aman. Artikel ini tidak membahas cakupan penuh analisis malware, lingkungan sandbox, atau atribusi serangan.
Apa yang tidak tercakup dalam hal ini — eksekusi sandbox, alat analisis malware, dan atribusi
Itu adalah topik untuk profesional keamanan dan tim tanggap insiden. Cakupan di sini secara sempit terfokus pada mendekode perintah PowerShell yang dikodekan dengan aman tanpa menjalankannya, sehingga Anda dapat membaca skrip dan menilai apakah perlu diselidiki lebih lanjut. Pengkodean Base64 membingungkan, bukan perlindungan. Siapapun yang memiliki pengkodean dan dekoder dapat mengekstrak skrip. Penyerang menggunakan Base64 untuk menghindari deteksi dasar dan mencegah pemeriksaan biasa, bukan untuk menyembunyikan niat mereka dari analisis. Perintah PowerShell yang didekodekan yang mengambil dan mengeksekusi skrip jarak jauh berbahaya baik Anda mendekodekannya sendiri atau alat keamanan yang melakukannya.
Langkah praktis berikutnya setelah memecahkan kode perintah yang mencurigakan adalah melaporkannya ke tim yang sesuai. Jika ini adalah sistem Anda sendiri, tentukan apakah tugas tersebut dibuat dengan sengaja dan oleh siapa. Periksa tanggal pembuatan dan akun yang menjadwalkannya. Jika tugas tersebut tidak sah, nonaktifkan tugas tersebut, simpan detailnya untuk forensik, dan selidiki bagaimana penyerang memperoleh hak istimewa untuk membuatnya. Jika perintah tersebut berisi permintaan jaringan atau mekanisme persistensi seperti perubahan registri atau pembuatan tugas terjadwal, hampir pasti perintah tersebut berbahaya.
Kesimpulan: Base64 adalah kebingungan, bukan perlindungan — bagaimana encoder & decoder Base64 mendekode payload secara lokal tanpa harus meninggalkan mesin Anda
Jika ia menjalankan fungsi administrasi yang sah dan detail pembuatannya normal, itu mungkin skrip administratif sah yang dikodekan karena alasan terkait kebijakan keamanan atau integrasi dengan alat otomatisasi yang lebih besar. Jangan lakukan itu dengan cara apa pun; biarkan penilaian Anda terhadap teks yang diterjemahkan menginformasikan keputusan Anda. Penguraian aman perintah Base64 PowerShell yang mencurigakan mengikuti proses yang mudah. Gunakan encoder & decoder Base64 untuk memecahkan kode string tanpa mengunggahnya atau menjalankan apa pun. Lihatlah tampilan hex untuk memahami apa yang diwakili oleh byte.
Jika Anda melihat pola UTF-16LE (disisipkan nol byte) ingatlah bahwa PowerShell menggunakan UTF-16LE dan bacalah sebagaimana mestinya. Identifikasi pola mencurigakan seperti permintaan jaringan, peningkatan hak istimewa, atau mekanisme persistensi. Catat detail laporan insiden Anda secara akurat, termasuk string Base64 asli dan hashnya. Jangan pernah menjalankan perintah itu sendiri; serahkan hal itu kepada petugas tanggap insiden dalam lingkungan yang terkendali. Percayai decoding lokal Anda dan penilaian Anda terhadap teks biasa, dan biarkan hal itu memandu tindakan Anda selanjutnya.