Laporan Investigasi

Challenge Cyber Defender CWL

Pendahuluan

Challenge Cyber Defender CWL merupakan latihan investigasi Blue Team yang menggunakan pendekatan multi-artefak. Peserta tidak hanya diminta membaca log pada SIEM, tetapi juga melakukan analisis terhadap network capture dan memory dump. Dengan kata lain, challenge ini dirancang untuk melatih cara berpikir seorang analis ketika harus menghubungkan bukti dari beberapa sumber sekaligus.

Dalam investigasi ini, artefak yang dianalisis terdiri atas tiga bagian utama. Pertama, Cyber Defender CWL sebagai environment lab yang menyediakan akses ke Wazuh SIEM. Kedua, Network Dump yang berisi file external.pcapng dan suspected.pcap untuk analisis lalu lintas jaringan. Ketiga, Memory Dump yang berisi file suspected.raw untuk kebutuhan analisis memori.

Tujuan dari investigasi ini adalah menjawab sepuluh pertanyaan challenge berdasarkan bukti digital yang tersedia, sekaligus menyusun hasil temuan ke dalam write-up yang runtut dan dapat dipahami pembaca lain.

Scenario Overview

Artefak yang diberikan pada challenge ini terdiri dari tiga bagian utama. Pertama, folder Cyber Defender CWL yang berisi VM untuk menjalankan environment lab dan mengakses Wazuh Dashboard. Kedua, folder Network Dump yang berisi file suspected.pcap dan external.pcapng. Ketiga, folder Memory Dump yang berisi file suspected.raw.

Dari struktur pertanyaannya, sudah terlihat bahwa challenge ini memang dibagi ke dalam tiga jenis analisis. Beberapa jawaban harus dicari dari Wazuh, beberapa dari PCAP, dan sisanya dari memory forensic.

Tentang Challenge

Di challenge ini kita diberikan 10 pertanyaan yang harus dijawab sebagai pembuktian kita telah menyelesaikan 10 pertanyaan tersebut.

Pertanyaan

1. Periksa dan identifikasi nama agent yang terhubung dengan SIEM yang dideploy secara lokal.
2. Identifikasi nama web server yang digunakan atau terhubung dengan SIEM lokal.
3. Sebutkan nama index di Wazuh yang digunakan untuk menyimpan semua log mentah (RAW logs) yang dikumpulkan oleh SIEM lokal.
4. Periksa jumlah total aktivitas SQL Injection (SQLI) yang terdeteksi selama menyelesaikan latihan SQL-Injection Activity Detected.
5. Identifikasi HTTP status code yang terkait dengan aktivitas Cross-Site Scripting (XSS).
6. Identifikasi nama file yang terkait dengan aktivitas File Inclusion.
7. Tentukan port yang terkait dengan komunikasi jaringan mencurigakan pada latihan Remote File Inclusion Activity Detected.
8. Identifikasi source port (src port) yang terhubung dengan destination port 4444 pada file external.pcapng.
9. Tentukan PID (Process ID) yang terkait dengan shell.exe pada file memory dump suspected.raw.
10. Tentukan URL yang terkait dengan aktivitas Local File Inclusion (LFI) yang terdeteksi pada SIEM lokal.

Penyelesaian Challenge

Untuk menyelesaikan challenge ini kita perlu masuk ke folder cyberwarfarelabs terlebih dahulu, lalu lanjut ke folder Cyber Defender CWL

setelah itu kita akan masuk kedalam wazuh-servernya, dan login menggunakan cred yang ditampilkan di kiri atas.

Setelah login kita lanjut menuju step selanjutnya yaitu menjalankan perintah

ip a

yang berfungsi untuk melihat ip kita yang nantinya berfungsi buat alamat tujuan ke mesin yang menjalankan Wazuh.

setelah itu kita tinggal login ke halaman utama Wazuh menggunakan cred default.

Step 1 — Mengidentifikasi agent yang terhubung ke SIEM lokal

Langkah pertama yang paling masuk akal adalah memastikan host mana yang sebenarnya mengirim log ke Wazuh. Pada event-event yang relevan di Discover, field agent.name secara konsisten menunjukkan nilai metasploitable. selain itu di side bar menu Wazuh -> total agents juga terdapat satu agent terdaftar dengan ID 001 bernama metasploitable.

Hal ini penting karena di event yang sama juga muncul manager.name: wazuh-server. Kalau tidak teliti, dua field ini bisa membingungkan. Namun wazuh-server di sini adalah manager SIEM, sedangkan endpoint yang log-nya sedang dikumpulkan adalah metasploitable.

Dari situ, identitas agent yang diminta challenge menjadi jelas.

Answer 1: metasploitable

Step 2 — Menentukan web server yang digunakan

Setelah agent teridentifikasi, langkah berikutnya adalah mencari tahu web server yang menghasilkan log tersebut. Petunjuk paling jelas datang dari field location, yang menunjuk ke file:

/var/log/apache2/access.log

command filter :

decoder.name:"web-accesslog"

Path itu adalah lokasi standar access log milik Apache pada sistem Linux. Jadi daripada menebak dari nama service atau asumsi environment, bukti paling kuat justru datang langsung dari sumber log itu sendiri.

Answer 2: Apache2

Step 3 — Menemukan indeks Wazuh yang menyimpan raw logs

Sebelum masuk ke analisis serangan web, saya perlu memastikan bahwa saya sedang melihat data yang benar. Investigasi dilakukan di halaman Discover menggunakan indeks:

wazuh-archives-*

Indeks ini penting karena berisi raw events, bukan hanya alert ringkas. Untuk challenge seperti ini, raw logs jauh lebih berguna karena masih menyimpan detail seperti request path, parameter URL, dan status code HTTP.

Karena challenge secara spesifik menanyakan indeks yang digunakan untuk menyimpan seluruh log mentah, maka jawabannya langsung mengarah ke indeks tersebut.

Answer 3: wazuh-archives-*

Step 4 — Menghitung total aktivitas SQL Injection

Bagian berikutnya berfokus pada aktivitas SQL Injection. Untuk mengisolasi event yang relevan, saya memfilter web access log pada endpoint yang mengandung sqli.

Hasil pencarian menunjukkan 5 hit. Yang membuat hasil ini semakin meyakinkan adalah isi request-nya sendiri. Beberapa event memperlihatkan payload seperti:

UNION SELECT user,password FROM users

command filter :

decoder.name:"web-accesslog"
and data.url:*sqli*

Itu adalah pola klasik SQL Injection yang digunakan untuk mengambil data sensitif dari database. Jadi bukan hanya jumlah event yang cocok, tetapi konteks request-nya pun memang jelas mengarah ke eksploitasi SQLi.

Dengan begitu, jumlah aktivitas SQL Injection yang terdeteksi dapat dipastikan.

Answer 4: 5

Step 5 — Menentukan HTTP status code yang terkait dengan aktivitas XSS

Setelah SQL Injection, saya berpindah ke aktivitas Cross-Site Scripting (XSS). Di Wazuh, event-event yang relevan mengarah ke endpoint:

/prod/vulnerabilities/xss_r/

command filter :

decoder.name:"web-accesslog"
and data.url:*xss*

Beberapa request memuat payload JavaScript yang mencoba menjalankan alert(document.cookie), yang merupakan pola umum untuk menguji atau mendemonstrasikan XSS.

Pada event utama yang memuat payload tersebut, response server menunjukkan HTTP 200. Memang ada juga request lain yang menghasilkan 404, tetapi itu tampaknya merupakan request turunan atau request yang tidak valid. Sementara aktivitas XSS inti yang berhasil diproses aplikasi justru mengembalikan 200.

Karena pertanyaan meminta status code yang terkait dengan aktivitas XSS, maka kode yang paling relevan adalah status dari request yang benar-benar berhasil diproses.

Answer 5: 200

Step 6 — Mengidentifikasi nama file yang terkait dengan File Inclusion

Bagian ini sempat terlihat mirip dengan pertanyaan tentang LFI, padahal sebenarnya fokusnya berbeda. Pada event-event File Inclusion, salah satu request yang paling jelas adalah:

/prod/vulnerabilities/fi/?page=include.php

command filter :

decoder.name:"web-accesslog"
and data.url:*fi*

Dari request itu terlihat bahwa file yang secara langsung dijadikan target parameter aplikasi adalah include.php. Karena pertanyaannya meminta nama file yang terkait dengan aktivitas File Inclusion, maka fokusnya memang bukan pada seluruh URL, melainkan pada nama file yang muncul di parameter tersebut.

Itulah kenapa jawaban untuk pertanyaan ini bukan /etc/passwd, melainkan file yang secara langsung dipanggil aplikasi.

Answer 6: include.php

Untuk soal nomor 7–8 kita berpindah artifak, selanjutnya kita akan mengidentifikasi file PCAP & PCAPNG

Step 7 — Menemukan port yang terkait dengan komunikasi jaringan mencurigakan

Di titik ini, investigasi tidak lagi cukup jika hanya mengandalkan Wazuh. Saya kemudian beralih ke suspected.pcapuntuk melihat apakah ada komunikasi yang mendukung temuan dari SIEM.

Dari PCAP tersebut, terlihat alur yang cukup jelas. Penyerang melakukan upload file ke endpoint aplikasi, lalu file hasil upload itu diakses kembali melalui path:

/prod/hackable/uploads/rev.php

command filter :

ip.addr == 192.168.117.190

alasan saya mencurigai ip tersebut karna ketika saya membaca menu conversation.

Tidak lama setelah itu, traffic menunjukkan kemunculan shell interaktif, ditandai dengan string:

SOCKET: Shell has connected! PID: 6068

filter command :

tcp.port == 9001

Setelah koneksi terbentuk, beberapa perintah seperti whoami, ip a, dan hostname dijalankan. Dari flow koneksi itu, port yang paling jelas terkait dengan komunikasi shell mencurigakan adalah 9001.

Port inilah yang paling masuk akal untuk dijadikan jawaban pada pertanyaan tentang komunikasi jaringan mencurigakan pada tahap serangan tersebut.

Answer 7: 9001

Step 8 — Menentukan source port yang terhubung ke destination port 4444

Pertanyaan berikutnya berasal dari file external.pcapng, dan tugasnya jauh lebih spesifik: cari source port yang terhubung ke destination port 4444.

Saat traffic TCP ditinjau, terlihat sesi berikut:

192.168.132.238:49816 -> 192.168.132.242:4444

Setelah koneksi terbentuk, traffic bahkan menampilkan shell interaktif Windows dengan prompt seperti C:\Users\Emp10\Downloads>, yang menandakan bahwa sesi tersebut memang penting dan bukan traffic acak biasa.

Karena pertanyaan hanya meminta source port dari koneksi menuju port 4444, maka nilainya bisa diambil langsung dari flow tersebut.

Answer 8: 49816

Step 9 — Menentukan PID yang terkait dengan shell.exe pada memory dump

Untuk menjawab pertanyaan ini, analisis dilakukan pada file memory dump suspected.raw menggunakan Volatility 3. Pencarian proses dilakukan dengan plugin windows.pslist dan windows.psscan, lalu hasilnya difilter menggunakan kata kunci shell.exe.

command filter:

suspected.raw windows.pslist | grep -iw "shell.exe"

Pada output Volatility ditemukan entri proses shell.exe dengan PID 7396. Hasil ini juga konsisten pada dua plugin yang berbeda, sehingga identifikasi PID dapat dianggap tervalidasi.

Answer 9: 7396

Step 10 — Mengidentifikasi URL yang terkait dengan aktivitas Local File Inclusion

Kalau pertanyaan nomor 6 berfokus pada nama file, maka pertanyaan ini berfokus pada URL yang digunakan dalam aktivitas Local File Inclusion.

Pada event File Inclusion yang sama, terlihat beberapa variasi payload yang berusaha membaca file sistem Linux. Salah satu yang paling jelas adalah:

/prod/vulnerabilities/fi/?page=/etc/passwd

command filter:

decoder.name:"web-accesslog"
and data.url:*fi*

Request ini menunjukkan pola LFI yang sangat klasik: memanfaatkan parameter page agar aplikasi membaca file lokal yang seharusnya tidak boleh diakses. Ada juga variasi traversal yang mengarah ke file yang sama, tetapi request di atas adalah bentuk yang paling langsung dan paling mudah diverifikasi dari bukti yang tersedia.

Itulah kenapa jawaban untuk pertanyaan ini bukan include.php, melainkan URL eksploitasi yang mencoba membuka file sistem.

Answer 10: /prod/vulnerabilities/fi/?page=/etc/passwd

Kesimpulan

Investigasi pada challenge Cyber Defender CWL menunjukkan bahwa analisis insiden yang baik tidak cukup dilakukan dari satu sumber bukti saja. Pada kasus ini, proses investigasi perlu menggabungkan SIEM, network capture, dan memory dump agar rangkaian aktivitas serangan dapat dipahami secara utuh.

Dari sisi Wazuh, berhasil diidentifikasi bahwa agent yang relevan adalah metasploitable, dengan web server Apache2, serta raw logs yang tersimpan pada indeks wazuh-archives-*. Analisis log juga menunjukkan adanya beberapa aktivitas serangan pada aplikasi web, yaitu SQL Injection, Cross-Site Scripting (XSS), dan Local File Inclusion (LFI). Hasilnya, ditemukan total 5 aktivitas SQL Injection, status code 200 pada aktivitas XSS utama, file include.php yang terkait dengan File Inclusion, serta URL /prod/vulnerabilities/fi/?page=/etc/passwd sebagai indikator LFI.

Dari sisi network forensics, analisis terhadap file suspected.pcap memperlihatkan adanya komunikasi mencurigakan yang berujung pada shell interaktif melalui port 9001. Sementara itu, analisis terhadap external.pcapng menunjukkan koneksi ke destination port 4444 yang berasal dari source port 49816. Temuan ini memperkuat bahwa serangan tidak berhenti pada eksploitasi web saja, tetapi berkembang menjadi aktivitas jaringan yang lebih berbahaya.

Pada sisi memory forensics, file suspected.raw berhasil dianalisis menggunakan Volatility 3, dan ditemukan bahwa proses shell.exe memiliki PID 7396. Temuan ini menjadi bukti tambahan yang memperkuat korelasi antara artefak jaringan dan aktivitas pada host.

Secara keseluruhan, challenge ini memberikan gambaran yang sangat baik tentang bagaimana seorang analis Blue Team harus bekerja: memulai dari alert, memverifikasi bukti pada log, menelusuri traffic jaringan, lalu memvalidasi proses yang berjalan di memori. Dengan pendekatan tersebut, investigasi tidak hanya menghasilkan jawaban untuk setiap pertanyaan, tetapi juga membangun pemahaman yang lebih jelas tentang alur serangan dari awal hingga akhir.

Penutup

Hal paling menarik dari Cyber Defender CWL adalah cara challenge ini memaksa kita berpindah konteks. Awalnya semua terlihat seperti investigasi SIEM biasa, tetapi semakin jauh dianalisis, semakin jelas bahwa challenge ini sebenarnya melatih korelasi antar-artefak.

Wazuh memberi visibilitas awal terhadap serangan aplikasi. PCAP membantu memperlihatkan bagaimana aktivitas itu berkembang menjadi komunikasi shell. Memory dump disiapkan sebagai lapisan validasi terakhir di host. Itulah yang membuat challenge ini terasa lebih realistis dibanding sekadar membaca satu jenis log.

Thank you ;)