Memahami Brute Force: Password Guessing vs Password Spraying

Kita lanjut lagi iseng buat tulisan dari pada puyeng dipendam di kepala sendiri. Kalau berbicara mengenai serangan Brute Force, sebagian besar orang mungkin menganggap semua bentuk serangan tersebut sama saja, yaitu mencoba login berulang kali sampai berhasil. Padahal jika mengacu pada framework MITRE ATT&CK, Brute Force memiliki beberapa sub-teknik dengan karakteristik yang berbeda.

 

Dua teknik yang paling sering ditemui adalah:

• Password Guessing (T1110.001)
• Password Spraying (T1110.003)

Sekilas memang terlihat mirip karena sama-sama mencoba menebak kata sandi. Namun, jika diperhatikan lebih dalam, pola serangannya justru berlawanan.

Password Guessing (T1110.001)

Password Guessing merupakan teknik di mana penyerang mencoba banyak kombinasi password terhadap satu atau beberapa akun tertentu.

Misalnya seorang attacker menargetkan akun admin, kemudian mencoba berbagai kemungkinan password seperti berikut:

admin
admin123
admin1234
password
administrator

Seluruh password tersebut dicoba ke akun yang sama sampai ada yang berhasil.

Karena satu akun menerima banyak percobaan login gagal dalam waktu singkat, teknik ini biasanya akan memicu mekanisme Account Lockout apabila sistem telah menerapkan kebijakan keamanan yang baik.

Teknik ini sering disebut sebagai serangan vertikal, karena fokusnya hanya pada satu akun tetapi dengan banyak variasi password.

Password Spraying (T1110.003)

Berbeda dengan Password Guessing, Password Spraying menggunakan pendekatan yang berkebalikan.

Pada teknik ini, penyerang hanya menggunakan satu password yang dianggap umum, kemudian mencobanya ke banyak akun yang berbeda.

Sebagai contoh, attacker menggunakan password:

Password123

Kemudian password tersebut dicoba ke banyak akun seperti:

andi
budi
rina
bedul

Mengapa cara ini dilakukan?

Karena sebagian besar sistem keamanan akan mengunci akun apabila terdapat banyak kegagalan login pada akun yang sama. Dengan mencoba satu password ke banyak akun, attacker berusaha menghindari mekanisme Account Lockout sehingga serangan dapat berlangsung lebih lama tanpa menimbulkan kecurigaan. Teknik ini dikenal sebagai serangan horizontal, karena satu password "disebarkan" ke banyak akun.

Apakah Firewall Bisa Membedakan Keduanya?

Inilah yang sering menjadi kesalahpahaman, terutama bagi analyst yang baru belajar SIEM.

Banyak orang mengira firewall atau IPS mampu menentukan apakah suatu serangan termasuk Password Guessing atau Password Spraying.

Padahal kenyataannya tidak demikian.

Firewall biasanya hanya mendeteksi bahwa telah terjadi aktivitas Brute Force atau Multiple Login Failure. Informasi tersebut memang sangat berguna sebagai indikator awal, tetapi belum cukup untuk menentukan sub-teknik MITRE ATT&CK yang digunakan oleh attacker.

Yang menentukan apakah serangan tersebut merupakan Password Guessing atau Password Spraying adalah analyst, berdasarkan pola aktivitas yang terlihat.

Sebagai contoh:

• Jika satu akun menerima ratusan percobaan password yang berbeda, maka besar kemungkinan itu adalah Password Guessing.
• Sebaliknya, jika satu password digunakan untuk mencoba login ke puluhan atau bahkan ratusan akun yang berbeda, maka pola tersebut lebih mengarah ke Password Spraying.

Dengan kata lain, firewall hanya memberikan petunjuk bahwa terjadi aktivitas Brute Force. Proses analisis tetap harus dilakukan oleh manusia.

Mengapa Label SIEM Tidak Selalu Benar?

Hal berikutnya yang sering membuat bingung analyst adalah ketika hasil korelasi dari SIEM ternyata tidak selalu sesuai dengan teknik MITRE ATT&CK yang sebenarnya.

Sebagai contoh, saya pernah menemukan kasus ketika FortiGate menghasilkan log IPS dengan signature:

Spring.Boot.Actuator.Unauthorized.Access

Namun setelah log tersebut diproses oleh FortiSIEM, incident yang muncul justru diberi label:

Privilege Escalation
T1548.004

Sekilas mungkin terlihat benar karena berasal dari sistem otomatis. Akan tetapi setelah dilakukan validasi menggunakan referensi MITRE ATT&CK, teknik yang lebih tepat sebenarnya adalah:

T1190
Exploit Public-Facing Application

Mengapa bisa berbeda? Karena label yang diberikan oleh SIEM hanyalah hasil korelasi berdasarkan rule yang telah dibuat sebelumnya. Rule tersebut memang membantu mempercepat proses deteksi, tetapi bukan berarti selalu benar dalam semua kondisi.

Oleh karena itu, seorang analyst tidak boleh langsung menerima hasil korelasi begitu saja. Raw log dari perangkat keamanan, signature vendor, konteks serangan, serta referensi MITRE ATT&CK tetap harus diperiksa sebelum menentukan klasifikasi akhir sebuah incident.

Anggap saja label dari SIEM adalah hipotesis awal, sedangkan keputusan akhirnya tetap berada di tangan analyst.

Cara Memberikan Nama Tiket yang Baik

Setelah mengetahui jenis serangan yang sebenarnya, langkah berikutnya adalah memberikan nama tiket secara konsisten.

Kesalahan yang cukup sering terjadi adalah menggunakan nama signature dari vendor sebagai judul tiket. Padahal setiap vendor memiliki format penamaan yang berbeda-beda.

Agar lebih mudah dipahami dan tetap konsisten, saya lebih menyarankan menggunakan taksonomi MITRE ATT&CK sebagai judul utama tiket, sedangkan informasi spesifik dari vendor disimpan sebagai informasi pendukung.

Sebagai contoh, apabila firewall berhasil memblokir exploit terhadap aplikasi web, maka tiket dapat diberi nama seperti berikut.

EVT | Initial Access: Exploit Public-Facing Application (T1190)
Source : 213.209.159.175
Target : 10.101.64.32
Outcome : Dropped

Sementara informasi seperti berikut cukup disimpan pada field tambahan di sistem ticketing:

• Vendor Signature
• SIEM Event Type
• Reporting Device
• FortiSIEM Incident ID

Dengan cara ini, judul tiket akan tetap konsisten meskipun log berasal dari FortiGate, Palo Alto, Cisco, Check Point, ataupun vendor lainnya.

Apabila kemudian diketahui bahwa exploit tersebut berhasil masuk ke server dan terdapat indikasi kompromi, maka statusnya berubah menjadi Incident.

Sebagai contoh:

INC | Initial Access: Exploit Public-Facing Application (T1190)

Host : 10.101.64.32
Status : Suspected Exposure

Selanjutnya, apabila analyst meminta administrator untuk memblokir alamat IP penyerang, maka aktivitas tersebut dapat dibuat sebagai Service Request, misalnya:

SR | Block Source IP

Object : 213.209.159.175
Reference : INC-65287

Dengan pendekatan seperti ini, judul tiket menjadi lebih rapi, mudah dipahami, serta tetap konsisten walaupun berasal dari berbagai jenis perangkat keamanan yang berbeda.

Yauda segitu dulu sharing singkatnya dan contoh IP yang ada itu fiktif belaka yah. 

Memahami Perbedaan Event, Incident, dan Service Request di Cyber Security

Menyambung tulisan terdahulu di https://rungga.blogspot.com/2015/03/whats-incident-problem-information.html

Jadi sekarang niatnya ingin lebih memperluas tulisan itu agar saya ga lupa dan siapa tahu bisa berguna suatu saat. Tulisan ini juga dibantu sama AI untuk dapat mempersingkat agar saya tidak terlalu panjang sampai berhalaman ^_^

Oke langsung mulai. Salah satu kesalahan yang paling sering saya temui ketika membangun Security Operation Center (SOC) adalah masih banyak yang menganggap semua alert dari SIEM harus dibuat menjadi tiket Incident.

Padahal kenyataannya tidak demikian. Kalau setiap alert langsung dijadikan Incident, jumlah tiket akan membengkak, analyst akan mengalami alert fatigue, dan tim justru akan kesulitan menemukan ancaman yang benar-benar berbahaya.

Nah, pada artikel ini kita akan membahas bagaimana cara membedakan Security Event, Security Incident, dan Service Request berdasarkan praktik terbaik IT Service Management (ITSM) serta implementasinya pada SOC menggunakan SIEM seperti FortiSIEM.

Di dunia IT Service Management (ITSM) atau lebih dikenal melalui framework ITIL dan ISO/IEC 20000, terdapat tiga proses yang sering kali terdengar mirip, padahal memiliki tujuan yang berbeda. Ketiga proses tersebut adalah Event Managemen, Incident Management dan Request Fulfillment.

Memahami perbedaannya merupakan fondasi utama sebelum membangun proses SOC yang baik. 

Jadi Event adalah setiap aktivitas atau kejadian yang berhasil dideteksi oleh suatu sistem dan memiliki arti bagi operasional layanan. Namun perlu dipahami bahwa tidak semua event berarti ada masalah.

Banyak event hanya bersifat informasional atau bahkan sudah berhasil ditangani secara otomatis oleh perangkat keamanan. Karena itulah mayoritas Event tidak perlu dibuat tiket. Event cukup dicatat, dipantau, atau digunakan sebagai data analisis.

Event baru akan naik status apabila membutuhkan tindakan lebih lanjut. Sebagai contoh:

• Disk server mencapai utilisasi 80% tetapi layanan masih berjalan normal.
• Firewall berhasil menolak satu percobaan brute force.
• IPS mendeteksi exploit kemudian langsung melakukan action Dropped.
• Backup sempat gagal sekali tetapi retry berikutnya berhasil.

Semua contoh tersebut masih termasuk Event, bukan Incident.

Oke sudah mulai terbayang dan puyeng? Janganlah mari kita lanjut lagi (ini gaya saya bukan AI loh). Berbeda dengan Event, Incident adalah kondisi ketika terjadi gangguan terhadap layanan atau terdapat indikasi kompromi yang harus segera ditangani.

Fokus utama Incident Management adalah memulihkan kondisi secepat mungkin serta melakukan investigasi penyebabnya.

Contohnya antara lain:

• Database server mati sehingga aplikasi tidak dapat diakses.
• Akun administrator berhasil diambil alih oleh attacker.
• Malware berhasil masuk ke endpoint.
• Firewall gagal memblokir exploit dan terdapat indikasi host telah terkompromi.

Pada kondisi inilah SOC akan membuat Security Incident Ticket agar proses investigasi dan penanganan dapat dilakukan secara terstruktur.

Kita lanjut lagi ke penjelasan yang terakhir. Berbeda lagi dengan Incident, Service Request merupakan permintaan layanan yang bersifat rutin, standar, dan memiliki risiko rendah.

Service Request bukan muncul karena adanya gangguan, melainkan karena pengguna atau administrator membutuhkan tindakan tertentu.

Contohnya:

• Membuat akun email untuk karyawan baru.
• Menambah kapasitas storage sebesar 100 GB.
• Membuka port firewall sesuai prosedur.
• Melakukan whitelist aplikasi tertentu.
• Memblokir IP Address yang telah dipastikan berbahaya.

Semua aktivitas tersebut merupakan pekerjaan operasional yang telah memiliki prosedur baku.

Oke di bawah ini saya kasih contoh nyata biar tambah lieur yah (hahahaaa):

Situasi	Kategori	Alasan
Disk server mencapai 80%	Event	Baru berupa peringatan, layanan masih normal
Database server mati	Incident	Layanan terganggu
Membuat akun email	Service Request	Permintaan standar
Backup gagal namun retry berhasil	Event	Sudah pulih otomatis
Menambah kapasitas storage	Service Request	Permintaan terencana

 

Ini dia yang menarik bahwa di SOC, perbedaan ketiga istilah ini jauh lebih penting. Misalnya terdapat satu percobaan brute force ke server. Firewall langsung mendeteksi aktivitas tersebut kemudian melakukan aksi Deny.

Apakah ini Incident?

Jawabannya belum tentu.

Selama firewall berhasil menghentikan serangan dan tidak ada dampak terhadap sistem, maka kondisi tersebut masih dikategorikan sebagai Security Event.

Contoh lain nih ye biar makin paham, IPS mendeteksi exploit terhadap aplikasi web kemudian melakukan action Dropped. Artinya exploit memang terjadi, tetapi berhasil dihentikan sebelum mencapai server.

Kondisi ini juga masih termasuk Security Event.

Sebaliknya, apabila brute force berhasil memperoleh akses ke akun administrator, atau exploit berhasil dijalankan sehingga server mengalami kompromi, maka statusnya berubah menjadi Security Incident.

Di sinilah analyst harus melakukan investigasi lebih lanjut sampai dia puyeng dah dan nenggak espresso sampai berapa shot dah, hahahaa.

 

Lanjut dlu deh dan biasanya nemuin pertanyaan begini "Pak/Mas gimana nih dengan serangan yang masif????". Misalnya terdapat ribuan serangan dari satu alamat IP.

Apakah otomatis menjadi Incident?

Jawabannya tidak selalu.

Serangan masif sebenarnya hanyalah kumpulan dari banyak Security Event. Selama seluruh serangan berhasil diblokir oleh Firewall atau IPS, maka belum tentu menjadi Incident.

Namun apabila terdapat indikasi bahwa sebagian serangan berhasil menembus pertahanan atau menyebabkan dampak terhadap layanan, maka statusnya berubah menjadi Security Incident.

Perbedaan utamanya selalu sama:

Apakah sudah ada dampak atau indikasi kompromi?

Jika jawabannya belum, maka masih berupa Event.

Jika jawabannya ya, maka menjadi Incident.

 

Gimana mulai cerah atau gelap? Kalau gelap kabur aja dlu tapi itu mah kata politikus yang nyinyir dan nye nye nye. Padahal itu hak setiap orang mau pergi atau tetap tinggal dan yang terpenting mah tetap cinta tanah air. Wuuuussshhh fokus jangan nyerempet nanti dicubit bapak itu.

 

Lalu Bagaimana dengan Permintaan Memblokir IP?

Misalnya si analyst menemukan satu IP Address yang terus melakukan scanning dan brute force. Administrator kemudian meminta agar IP tersebut diblokir permanen pada firewall.

Apakah ini Incident?

Jawabannya bukan.

Aktivitas tersebut merupakan Service Request, karena yang diminta hanyalah tindakan operasional standar berupa pemblokiran IP. Namun apabila pemblokiran dilakukan sebagai bagian dari proses containment sebuah Incident yang sedang berlangsung, maka aktivitas tersebut menjadi task di dalam Incident, bukan Service Request yang berdiri sendiri.

Begini agar lebih mudah diingat, berikut aturan sederhana yang banyak digunakan pada SOC modern.

Security Event:

• Aktivitas berhasil dideteksi.
• Firewall atau IPS berhasil melakukan deny, drop, atau block.
• Tidak ada dampak terhadap sistem.
• Tidak membutuhkan investigasi lanjutan.

Biasanya hanya disimpan di SIEM dan tidak dibuat tiket.

Security Incident

• Ada indikasi kompromi.
• Ada dampak terhadap layanan.
• Mitigasi belum pasti berhasil.
• Membutuhkan investigasi analyst.

Pada kondisi ini dibuat Incident Ticket.

Service Request

• Aktivitas operasional rutin.
• Telah memiliki prosedur baku.
• Risiko rendah.
• Memerlukan tindakan administrator.

Contohnya:

• Block IP
• Whitelist
• Membuka port firewall
• Onboarding log source
• SIEM Rule Tuning

 

Segitu dulu ya bray tulisan ini dan jika banyak kesalahan, dimaklumin saja karena seorang Newbie kaya saya yah masih butuh belajar lebih lanjut.

Terima kasih kepada para pengunjung baik yang membaca atau cuman numpang lewat. Semoga bisa jadi amal jariyah saya.