RMM Abuse: Teknik Persistence Tanpa Malware Tradisional - Ethical Hacking Indonesia

Ketika Trust Model Menjadi Attack Surface

Sebagian besar sistem keamanan endpoint masih beroperasi dengan asumsi bahwa ancaman datang dari binary yang tidak dikenal, unsigned, atau memiliki reputasi catcat atau rendah. Kampanye ini justru bergerak di arah sebaliknya. Tidak ada eksploitasi kernel, tidak ada shellcode injection, bahkan tidak ada malware dalam bentuk tradisional di tahap awal. Yang digunakan adalah software RMM seperti ITarian, SimpleHelp, dan ScreenConnect semuanya legitimate, signed, dan umum digunakan di lingkungan enterprise.

Baca Juga Tentang: Penggunaan ScreenConnect Dalam Serangan (Analisis Serangan Storm-1175)

Di sinilah problem utamanya muncul. Mekanisme trust yang dibangun untuk mempermudah operasional IT justru menjadi attack surface. Ketika sebuah binary memiliki valid code-signing certificate dan dikenal luas, hampir seluruh lapisan pertahanan dari SmartScreen hingga antivirus secara default akan memperlakukannya sebagai aman.

Serangan Berbasis Legitimate Execution

Rantai serangan dimulai dari phishing yang tidak menggunakan domain attacker secara langsung, melainkan domain legitimate yang telah dikompromi. Ini bukan sekadar teknik pengaburan, tetapi strategi untuk melewati filtering berbasis reputasi yang umum digunakan pada email gateway dan web proxy.

Baca Juga tentang: Spear Phising (FrostArmada)

Payload yang dikirim ke korban tidak terlihat mencurigakan karena memanfaatkan perilaku default Windows. Ekstensi file disembunyikan sehingga executable tampil seperti dokumen biasa, sementara icon dan metadata dimodifikasi agar selaras dengan konteks social engineering. Ketika file dijalankan, tidak ada indikator eksploitasi klasik. Sebaliknya, yang aktif adalah JWrapper sebuah Java-based launcher yang bertindak sebagai abstraction layer.

JWrapper mengeksekusi beberapa langkah penting secara diam-diam. Ia mengekstrak runtime Java yang dibundel, membaca konfigurasi terenkripsi yang disisipkan dalam binary, lalu menjalankan payload tanpa UI. Dari perspektif sistem, proses ini terlihat seperti aplikasi Java biasa yang berjalan dengan parameter tertentu, bukan sebagai loader malware. Inilah titik di mana banyak solusi EDR kehilangan konteks, karena tidak ada anomali struktural pada binary maupun prosesnya.

Persistence dan Session Control Tanpa Exploit Tradisional

Mengeksploitasi vulnerability, attacker membangun kontrol penuh melalui mekanisme sistem yang sah. Mereka mendaftarkan service Windows yang berjalan secara persist dan kemudian memperluas jangkauannya hingga ke user session.

Yang menarik adalah bagaimana persistence dibangun. Service tidak hanya didaftarkan melalui Service Control Manager, tetapi juga diikat ke Safe Mode melalui registry SafeBoot. Artinya, bahkan ketika defender mencoba membersihkan sistem melalui Safe Mode, service tersebut tetap aktif. Ini diperkuat dengan mekanisme watchdog berbasis file yang akan me-restart proses jika berhenti, menciptakan efek self-healing.

Baca Juga Tentang: Persistence Access (Firestarter - Cisco)

Setelah persistence stabil, attacker melakukan eskalasi dari konteks service (SYSTEM) ke konteks user. Ini dilakukan dengan mencuri token dari proses seperti winlogon.exe, kemudian menggunakannya untuk membuat proses baru di session user aktif. Dengan pendekatan ini, attacker tidak hanya memiliki kontrol sistem, tetapi juga kemampuan interaktif melihat layar, mengirim input, dan mengakses resource berbasis user.

Yang membuat operasi ini semakin solid adalah penggunaan dua RMM secara paralel. Satu channel digunakan untuk automation dan monitoring, sementara channel lain untuk akses interaktif. Ini bukan sekadar redundansi, melainkan desain arsitektur yang memastikan akses tetap bertahan meskipun salah satu jalur berhasil diputus.

Baca Juga Tentang: Apa itu RRM?

Dari Akses Diam-Diam ke Pengambilalihan Infrastruktur

Setelah foothold terbentuk, sistem tidak langsung disalahgunakan secara agresif. Sebaliknya, attacker menjalankan monitoring pasif dengan pola yang sangat konsisten. Mereka mengumpulkan informasi tentang jaringan, status keamanan, dan aktivitas user secara berkala. Salah satu teknik yang cukup cerdas adalah memonitor pergerakan mouse untuk menentukan apakah user sedang aktif. Interaksi hanya dilakukan ketika sistem idle, meminimalkan kemungkinan terdeteksi.

Dalam skenario nyata, ini memberikan keuntungan besar bagi attacker. Mereka bisa masuk ke sistem, mengumpulkan kredensial dari browser, mengevaluasi akses VPN, dan memahami topologi internal tanpa menimbulkan alarm. Karena RMM secara natural memang digunakan untuk remote administration, aktivitas seperti command execution atau file transfer tidak terlihat aneh jika dilihat tanpa konteks.

Dampaknya kemudian meluas. Dengan kredensial yang diperoleh, attacker dapat melakukan lateral movement ke sistem lain. Dalam banyak kasus, tahap ini berfungsi sebagai fase awal sebelum deployment ransomware. Yang membedakan adalah seluruh proses berlangsung di atas software yang dipercaya, sehingga visibility terhadap aktivitas berbahaya menjadi sangat terbatas.

Baca Juga Artikel Tentang: Lateral-Movement - Kredensial Harvesting

Dari Signature ke Behavioral Context

Serangan seperti ini tidak bisa dideteksi secara efektif hanya dengan signature atau reputasi file. Yang dibutuhkan adalah pemahaman terhadap behavior dan konteks eksekusi.

Indikator kompromi tidak lagi berupa hash file atau domain mencurigakan, melainkan pola aktivitas. Misalnya, service baru yang dibuat dari direktori tidak umum seperti ProgramData, atau proses RMM yang memicu eksekusi command-line utilities secara berulang. Bahkan detail kecil seperti keberadaan binary yang di-rename misalnya wmic.exe yang berubah nama bisa menjadi indikator kuat karena tidak pernah muncul dalam operasi normal.

Selain itu, organisasi perlu mulai memperlakukan RMM sebagai komponen yang harus diawasi ketat. Tidak cukup hanya mengizinkan software tersebut berjalan; perlu ada baseline yang jelas mengenai bagaimana, kapan, dan oleh siapa software tersebut digunakan. Setiap deviasi dari baseline tersebut harus dianggap sebagai anomali, bukan noise.

Pergeseran ke Living-off-Trusted-Software

Kampanye ini menandai pergeseran penting dalam lanskap threat. Jika sebelumnya attacker berusaha membuat malware terlihat legitimate, kini mereka langsung menggunakan sesuatu yang memang legitimate sejak awal.

Ini memungkinkan evolusi dari konsep Living-off-the-Land menjadi Living-off-Trusted-Software. Perbedaannya bukan sekadar istilah, tetapi implikasi operasional. Ketika software yang digunakan adalah bagian dari workflow IT sehari-hari, maka deteksi tidak bisa lagi bergantung pada apa yang dijalankan, tetapi harus fokus pada bagaimana software tersebut digunakan.

Serangan seperti ini memaksa defender untuk berpindah dari pendekatan berbasis objek ke pendekatan berbasis perilaku. Karena ketika backdoor tidak lagi berupa malware, satu-satunya jejak yang tersisa adalah pola aktivitas yang tidak seharusnya terjadi.

Benediktus Sava – Security Researcher

Sumber:

Securonix

Redcanary

False Positive Microsoft Defender dan Dampaknya pada Trust Chain - Ethical Hacking Indonesia

Ketika mekanisme proteksi endpoint mulai memodifikasi trust anchor sistem, kita tidak lagi berbicara sekadar false positive ini sudah masuk ke domain integrity failure pada root of trust. Kasus deteksi Trojan:Win32/Cerdigent.A!dha oleh Microsoft Defender terhadap entri root certificate DigiCert menjadi contoh nyata bagaimana kontrol keamanan dapat berubah menjadi attack surface yang tidak disengaja.

Masalah inti muncul dari signature update Defender (sekitar 30 April) yang mengklasifikasikan registry key tertentu sebagai indikator malware. Targetnya bukan file berbahaya, melainkan entri trust store Windows di path:

HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\

Secara teknis, lokasi ini menyimpan root CA yang digunakan dalam validasi TLS, code signing, dan berbagai mekanisme trust lainnya. Ketika Defender menghapus entri berdasarkan hash tertentu, sistem kehilangan kemampuan untuk memverifikasi rantai sertifikat yang bergantung pada root tersebut. Ini bukan sekadar alert ini adalah modifikasi aktif terhadap cryptographic trust chain.

Analisa lebih dalam menunjukkan kemungkinan besar bahwa signature detection dibangun dari indikator yang overlap dengan artefak insiden DigiCert sebelumnya. Dalam insiden tersebut, attacker berhasil memperoleh initialization code untuk code-signing certificate dan menggunakannya untuk menandatangani malware. Jika Defender mengandalkan pattern matching terhadap struktur atau metadata sertifikat yang mirip, maka false positive menjadi konsekuensi logis dari pendekatan heuristik yang terlalu agresif.

Skenario eksploitasi yang realistis tidak harus melibatkan eksploit langsung oleh attacker justru yang menarik adalah abuse of defensive side-effects. Bayangkan environment enterprise di mana root certificate tertentu dihapus secara massal. Dampaknya:

TLS handshake ke layanan tertentu gagal - downtime aplikasi internal

Validasi signature software gagal - deployment pipeline berhenti

Endpoint kehilangan kemampuan verifikasi update - membuka peluang supply chain attack lanjutan

Dalam kondisi chaos seperti ini, attacker bisa melakukan opportunistic attack. Misalnya, dengan melakukan MITM pada koneksi yang fallback ke insecure mode atau dengan menyisipkan sertifikat alternatif di endpoint yang sudah kehilangan baseline trust-nya. Ini bukan eksploit klasik, tapi lebih ke arah trust degradation attack memanfaatkan kondisi sistem yang sudah tidak konsisten.

Dampaknya meluas ke beberapa layer:

1. Operational impact – gangguan layanan akibat TLS failure
2. Security impact – potensi bypass verifikasi jika fallback terjadi
3. Psychological impact – admin panik, bahkan sampai reinstall OS tanpa alasan valid

Menariknya, beberapa organisasi justru memperburuk situasi dengan melakukan remediation yang tidak tepat, seperti wipe sistem, padahal root cause ada pada signature update.

Dari sisi deteksi dan forensik, pendekatan yang lebih tepat adalah memonitor perubahan registry menggunakan telemetry seperti:

• DeviceRegistryEvents untuk melihat re-creation certificate
• certutil -store AuthRoot untuk validasi manual trust store

Insight penting di sini: trust store harus diperlakukan sebagai critical asset, bukan sekadar konfigurasi pasif. Perubahan terhadapnya seharusnya memiliki audit trail yang ketat, sama seperti perubahan pada IAM atau firewall rules.

Microsoft kemudian memperbaiki signature ini di update versi 1.449.430.0 ke atas, yang menunjukkan bahwa ini murni kesalahan deteksi, bukan kompromi aktif. Namun, kejadian ini membuka diskusi lebih luas tentang ketergantungan terhadap automated security controls.

Mitigasi yang relevan untuk praktisi:

• Implementasikan monitoring terhadap perubahan trust store (registry + certificate store)
• Gunakan baseline integrity check untuk root CA penting
• Hindari auto-remediation agresif tanpa validation layer tambahan
• Segmentasikan critical system agar tidak semua endpoint menerima signature update secara simultan (staged rollout)

Secara strategis, ini juga berkaitan dengan konsep supply chain trust. Ketika CA seperti DigiCert mengalami insiden, efeknya tidak hanya pada certificate issuance, tetapi juga pada bagaimana vendor security merespons dan respons tersebut bisa berdampak lebih luas dari insiden awal.

Kesimpulannya: False positive ini bukan sekadar bug, melainkan ilustrasi bahwa dalam ekosistem modern, boundary antara defense dan disruption sangat tipis. Bagi pentester dan security engineer, ini adalah pengingat bahwa kontrol keamanan sendiri harus diuji sebagai bagian dari threat model.

Benediktus Sava – Security Researcher

Baca Juga Artikel Yang Berrkaitan:

Exploit Chains Di Windows

Windows - MSHTML

Microsoft Security Pathcing

Sumber:

Florian Roth - X

Microsoft - MSI

NinjaOne

Authenticated Phishing: Abuse Infrastruktur Google AppSheet - Ethical Hacking Indonesia

Serangan AccountDumpling memperlihatkan celah yang jarang dibahas secara serius dalam security engineering: bukan bug pada sistem, tetapi kegagalan asumsi terhadap trust. Lebih dari 30.000 akun Facebook berhasil dikompromikan bukan melalui spoofing atau malware, tapi lewat email yang secara teknis sah dikirim langsung dari infrastruktur Google melalui AppSheet. Di sini, model pertahanan klasik runtuh karena indikator kepercayaan (SPF, DKIM, DMARC) justru bekerja “terlalu baik”.

Masalah utamanya bukan pada mekanisme autentikasi email itu sendiri, tapi pada interpretasinya. Email authentication hanya menjawab pertanyaan “siapa yang mengirim”, bukan “apakah kontennya aman”. AppSheet, sebagai platform no-code, dirancang untuk mengirim notifikasi otomatis berbasis workflow. Namun dalam konteks ini, attacker memanfaatkannya sebagai phishing relay yang tidak dapat dibedakan dari notifikasi legitimate. Karena email berasal dari domain Google yang valid, sistem filter tidak memiliki alasan teknis untuk memblokirnya. Ini menciptakan kondisi di mana payload berbahaya dibungkus dalam jalur distribusi yang sepenuhnya trusted.

Jika ditelusuri lebih dalam, serangan ini bukan sekadar phishing campaign biasa, tetapi sebuah arsitektur terdistribusi yang menyerupai sistem produksi modern. AppSheet berfungsi sebagai delivery layer dengan reputasi tinggi. Setelah korban berinteraksi, mereka diarahkan ke infrastruktur yang di-host di Netlify atau Vercel, yang masing-masing memiliki peran berbeda. Netlify digunakan untuk halaman phishing statis dengan subdomain unik per korban, sehingga mempersulit blocklisting. Sementara itu, Vercel digunakan untuk flow yang lebih kompleks, termasuk validasi kredensial secara real-time, pengumpulan data bertahap, dan mekanisme anti-analisis seperti obfuscation dan deteksi debugging.

Baca Juga Tentang Penggunaan Netlify(UTA0388) dan Vercel Dalam CyberCrime

Dalam salah satu skenario eksploitasi yang digunakan adalah, seorang admin Facebook Business menerima email peringatan terkait pelanggaran kebijakan. Karena email tersebut lolos semua validasi dan terlihat profesional, korban cenderung langsung mengikuti instruksi. Setelah klik, korban masuk ke halaman yang menyerupai pusat bantuan Facebook. Di titik ini, serangan tidak berhenti pada pengumpulan username dan password. Sistem akan langsung menguji kredensial tersebut ke layanan asli. Jika valid, korban diminta memasukkan kode 2FA, bahkan hingga beberapa kali jika diperlukan. Dalam varian yang lebih canggih, attacker memanfaatkan koneksi WebSocket untuk memonitor interaksi korban secara langsung. Ini memungkinkan attacker bertindak sebagai operator aktif yang bisa menyesuaikan alur phishing secara real-time misalnya meminta ulang input, mengubah tampilan halaman, atau mengeksekusi langkah tambahan untuk memastikan akses benar-benar berhasil diambil alih.

Pendekatan ini mengubah phishing dari aktivitas pasif menjadi sesi interaktif yang hampir menyerupai man-in-the-middle attack, tetapi berbasis social engineering. Tidak hanya kredensial yang diambil, tetapi juga data pemulihan seperti nomor telepon, tanggal lahir, hingga dokumen identitas. Artinya, attacker tidak hanya mendapatkan akses awal, tetapi juga kemampuan untuk mempertahankan kontrol jika korban mencoba melakukan recovery.

Dampaknya melampaui sekadar account takeover. Dalam konteks Facebook Business, satu akun bisa memiliki nilai ekonomi tinggi karena terhubung dengan sistem iklan, audiens, dan identitas brand. Setelah diambil alih, akun tersebut bisa digunakan untuk menjalankan iklan berbahaya, melakukan penipuan, atau bahkan dijual kembali di pasar gelap. Yang lebih menarik, investigasi menunjukkan adanya loop monetisasi di mana akun yang dicuri kemudian “dipulihkan” melalui layanan yang kemungkinan dioperasikan oleh aktor yang sama. Ini menciptakan model bisnis tertutup yang menyerupai supply chain, di mana akses menjadi komoditas yang terus diputar.

Bagi praktisi keamanan, ada beberapa pelajaran penting yang muncul dari kasus ini. Pertama, reliance terhadap reputasi domain sudah tidak cukup. Ketika attacker menggunakan platform seperti Google, Netlify, dan Vercel, sinyal kepercayaan tradisional kehilangan relevansinya. Kedua, phishing telah berevolusi menjadi proses stateful yang melibatkan validasi langsung dan interaksi manusia di belakang layar. Ketiga, identity kini harus dipandang sebagai bagian dari supply chain security, bukan hanya sebagai endpoint authentication.

Mitigasi terhadap serangan seperti ini tidak bisa hanya mengandalkan filtering email. Pendekatan yang lebih efektif adalah menggeser fokus ke level interaksi. Sistem perlu mampu mendeteksi anomali dalam alur login, bukan hanya pada sumber email. Penggunaan metode autentikasi yang tahan phishing seperti passkey atau FIDO2 menjadi semakin penting karena menghilangkan nilai dari kredensial yang dicuri. Selain itu, pembatasan akses ke akun kritikal, misalnya melalui IP allowlisting atau device binding, dapat mengurangi peluang eksploitasi meskipun kredensial sudah bocor.

Bisa kita lihat dan simpulkan yaitu AccountDumpling menunjukkan bahwa attacker tidak selalu perlu menembus sistem. Cukup dengan memanfaatkan cara sistem dirancang untuk dipercaya, mereka bisa mendapatkan hasil yang sama. Ini menandai pergeseran penting dalam threat landscape: dari eksploitasi kerentanan teknis menuju eksploitasi asumsi desain. Dan dalam banyak kasus, yang kedua jauh lebih sulit dideteksi.

Benediktus Sava – Security Researcher

Sumber:

GuardIo

Bedah Copy Fail: Bug Kernel Linux Jadi Akses Root CVE-2026-31431 - Ethical Hacking Indonesia

Kerentanan Local Privilege Escalation biasanya bergantung pada dua hal: race condition yang sempit atau offset kernel yang spesifik. Copy Fail (CVE-2026-31431) mematahkan asumsi itu sepenuhnya. Ini bukan bug timing, bukan juga exploit yang membutuhkan penyesuaian terhadap versi kernel tertentu. Ini adalah logic flaw linear di dalam subsistem crypto Linux, tepatnya pada implementasi algif_aead dalam AF_ALG. Artinya, eksploitasi tidak membutuhkan kondisi khusus cukup user biasa, tanpa privilege, tanpa debugging capability, dan tanpa primitif tambahan. Di banyak environment modern, itu sudah cukup untuk mendapatkan root.

Baca Juga Tentang: Local Privilege Escalation

Masalah utamanya muncul dari desain “in-place operation” yang sebelumnya diperkenalkan, di mana source dan destination buffer diasumsikan bisa berbagi mapping memori. Dalam praktiknya, asumsi ini tidak valid karena keduanya berasal dari mapping berbeda. Kompleksitas tambahan untuk mendukung operasi ini justru membuka celah: data yang seharusnya diisolasi malah diproses dengan cara yang memungkinkan manipulasi terhadap page cache atau buffer kernel. Ketika kernel melakukan copy data associated (AD) dalam konteks AEAD, terdapat inkonsistensi dalam bagaimana pointer dan panjang data divalidasi. Ini menciptakan kondisi di mana user-space bisa memicu write ke area yang tidak semestinya.

Yang membuatnya berbahaya adalah sifatnya yang deterministik. Tidak ada race window yang harus “ditangkap”. Eksekusi berjalan lurus: kirim input crafted ke AF_ALG socket, trigger path yang salah dalam algif_aead, dan hasilnya adalah memory corruption yang bisa dikontrol. Ini menjelaskan kenapa PoC bisa sesederhana script Python ~700 byte dan tetap bekerja lintas distro sejak 2017.

Skenario eksploitasi yang realistis muncul di lingkungan multi-tenant. Bayangkan sebuah CI runner self-hosted yang mengeksekusi pull request dari publik. Attacker cukup mengirim PR berisi payload Python sederhana. Karena runner menjalankan kode sebagai user biasa di host kernel yang sama, exploit dapat dijalankan langsung. Begitu privilege escalation berhasil, attacker memiliki akses root ke mesin runner, yang seringkali menyimpan secrets seperti token deployment, SSH keys, atau credentials cloud. Ini bukan sekadar LPE ini pivot point untuk supply chain attack. Dari satu runner, attacker bisa menyuntikkan malicious code ke pipeline build dan menyebarkannya ke artifact produksi.

Dalam konteks container, dampaknya bahkan lebih luas. Banyak organisasi masih menganggap container sebagai boundary keamanan, padahal kernel tetap shared. Dengan Copy Fail, sebuah pod yang dikompromi dapat melakukan escape ke host. Karena page cache dan subsistem kernel dibagi, exploit ini membuka jalan untuk cross-container compromise. Dalam cluster Kubernetes multi-tenant, ini berarti satu tenant bisa mengakses resource tenant lain, atau bahkan menguasai node secara penuh.

Jika dibandingkan dengan kasus seperti Dirty Pipe, pola eksploitasinya memiliki kemiripan: manipulasi terhadap mekanisme kernel yang berhubungan dengan data flow (pipe atau crypto buffer) untuk menulis ke area yang seharusnya read-only atau terisolasi. Insight penting di sini adalah bahwa kelas bug seperti ini tidak lagi jarang atau mahal untuk ditemukan. Dengan bantuan sistem otomatis seperti yang digunakan oleh peneliti, discovery terhadap logic flaw semacam ini menjadi jauh lebih cepat. Artinya, asumsi lama bahwa kernel bug adalah “rare commodity” sudah tidak relevan.

Dampaknya terhadap threat model cukup signifikan. Sistem yang sebelumnya dianggap aman karena tidak expose network service kini tetap rentan jika attacker mendapatkan foothold lokal sekecil apapun misalnya melalui web RCE, credential leakage, atau misconfigured service. Copy Fail menjadi tahap eskalasi yang hampir pasti berhasil setelah initial access.

Lalukan Pengecekan Linux Kamu: Github - Copy Fail

Mitigasi utamanya tentu patch kernel ke versi yang telah memperbaiki implementasi algif_aead dengan kembali ke pendekatan out-of-place operation. Namun, pendekatan defensif tidak boleh berhenti di patching. Untuk environment dengan risiko tinggi seperti CI/CD, Kubernetes, atau SaaS yang menjalankan kode user, isolasi berbasis VM atau microVM menjadi jauh lebih relevan dibanding sekadar namespace container. Selain itu, pembatasan akses terhadap AF_ALG dapat dipertimbangkan melalui seccomp atau LSM policy, karena tidak semua aplikasi membutuhkan interface crypto kernel secara langsung.

Baca Juga Tentang: CI/CD

Di sisi engineering, kasus ini juga menunjukkan pentingnya validasi terhadap laporan vulnerability. Dengan meningkatnya penggunaan AI dalam vulnerability discovery, jumlah laporan akan naik drastis, tetapi tidak semuanya valid. Organisasi perlu memiliki pipeline untuk reproduksi cepat terhadap PoC agar bisa membedakan noise dan exploit nyata. Tanpa itu, vulnerability seperti Copy Fail bisa terlambat ditangani meskipun exploit-nya trivial.

Kesimpulan yang bisa kita ambil Copy Fail bukan hanya tentang satu bug di kernel. Ini adalah indikator perubahan lanskap: eksploitasi semakin mudah, discovery semakin cepat, dan boundary keamanan tradisional seperti container semakin tidak cukup. Praktisi security perlu mulai mengasumsikan bahwa LPE seperti ini akan terus muncul dan merancang sistem dengan asumsi tersebut, bukan sebagai edge case.

Benediktus Sava – Security Researcher

Sumber:

Copy File

Bugcrowd

Eksploitasi CVE-2026-3854: Git Push ke RCE di GHES - Ethical Hacking Indonesia

CVE-2026-3854 bukan sekadar bug input validation biasa, tetapi representasi nyata bagaimana fitur legitimate seperti git push options dapat berubah menjadi attack surface kritis ketika boundary antara user input dan internal metadata tidak dijaga dengan ketat. Problem utamanya terletak pada improper neutralization terhadap karakter spesial, di mana nilai yang dikirim user saat proses git push langsung dimasukkan ke dalam header internal tanpa sanitasi yang memadai. Karena format metadata internal menggunakan delimiter seperti titik koma (;), attacker dapat memanfaatkan konflik ini untuk melakukan injection dan memanipulasi cara sistem memproses request tersebut.

Baca Juga Tentang: Command Injection - 4 CVE KEV April 2026

Secara teknis, alur normal git push di GitHub Enterprise Server melibatkan beberapa service internal yang saling berkomunikasi menggunakan metadata header. Push options memungkinkan client mengirim key-value tambahan ke server, yang kemudian diteruskan sebagai bagian dari header seperti X-Stat. Masalahnya muncul ketika nilai tersebut tidak di-escape atau divalidasi, sehingga attacker dapat menyisipkan delimiter tambahan untuk “memecah” struktur metadata. Ini memungkinkan injeksi field baru yang akan dianggap sebagai konfigurasi internal yang trusted oleh service downstream. Dalam konteks ini, attacker tidak lagi sekadar mengontrol input mereka mengontrol environment eksekusi.

Baca Juga Tentang: Bagaimana Data User Bisa Mengontrol Internal Service

Eksploitasi menjadi menarik karena tidak berhenti di satu injection saja. Peneliti menunjukkan bahwa dengan chaining beberapa nilai yang disuntikkan, attacker bisa mengubah rails_env menjadi non-production untuk melemahkan sandbox, mengarahkan custom_hooks_dir ke lokasi yang dikontrol, dan memanipulasi repo_pre_receive_hooks untuk mengeksekusi hook berbahaya melalui path traversal. Ini bukan sekadar command injection langsung, tetapi lebih ke arah environment poisoning mengubah konteks eksekusi sehingga sistem sendiri menjalankan payload attacker sebagai bagian dari workflow normal.

Baca Juga Tentang: Environment Manipulation

Skenario eksploitasi realistis bisa terjadi di organisasi yang menggunakan GitHub Enterprise Server secara internal. Seorang attacker yang sudah memiliki akses push ke repository baik melalui akun yang dikompromi atau insider threat dapat melakukan push dengan opsi yang telah dimodifikasi secara khusus. Tanpa interaksi tambahan, server akan memproses push tersebut dan secara tidak sadar menjalankan hook yang telah dimanipulasi. Karena eksekusi terjadi sebagai user git, attacker mendapatkan foothold dengan akses ke filesystem, konfigurasi internal, dan kemungkinan pivot ke service lain dalam lingkungan yang sama. Dalam environment yang menggunakan shared storage node, dampaknya bisa meluas ke repository lain.

Dampak vulnerability ini tidak bisa diabaikan. Dengan CVSS tinggi dan kemampuan remote code execution, attacker berpotensi mengambil alih seluruh instance GHES. Ini termasuk akses read/write ke repository privat, credential internal, hingga pipeline CI/CD yang terintegrasi. Jika dikaitkan dengan konteks supply chain attack, ini menjadi sangat kritikal karena compromise pada Git server berarti attacker bisa menyisipkan backdoor langsung ke source code yang nantinya akan didistribusikan ke production. Ini menggeser vulnerability ini dari sekadar “server exploit” menjadi potensi entry point untuk software supply chain compromise.

Insight penting bagi praktisi adalah bagaimana vulnerability ini menunjukkan kelemahan umum dalam desain sistem terdistribusi: asumsi bahwa internal metadata selalu trusted. Ketika user-controlled data dapat masuk ke jalur komunikasi internal tanpa validasi ketat, boundary antara external input dan internal logic runtuh. Ini adalah pola yang sering muncul di banyak sistem, tidak hanya GitHub terutama pada service yang menggunakan custom protocol atau header untuk komunikasi antar komponen.

Mitigasi utama tentu adalah patching ke versi yang telah diperbaiki, tetapi pendekatan defensif tidak boleh berhenti di situ. Validasi dan sanitasi input harus dilakukan secara konsisten di setiap layer, bukan hanya di entry point. Selain itu, prinsip least privilege harus diterapkan pada akses repository tidak semua user seharusnya memiliki hak push, terutama di environment sensitif. Monitoring juga menjadi krusial: log seperti /var/log/github-audit.log harus dianalisis untuk mendeteksi anomali, misalnya penggunaan karakter delimiter dalam push options yang tidak lazim. Dari sisi arsitektur, menghapus code path yang tidak digunakan di environment tertentu adalah langkah penting dalam defense-in-depth, karena mengurangi kemungkinan abuse meskipun vulnerability serupa muncul kembali.

CVE-2026-3854 memperlihatkan attack surface modern tidak selalu berasal dari fitur yang berbahaya, tetapi justru dari fitur yang dirancang untuk fleksibilitas. Dalam dunia DevOps yang sangat bergantung pada automasi dan integrasi, setiap titik yang menghubungkan user input dengan sistem internal harus dianggap sebagai potensi vektor eksploitasi. Bagi pentester dan security engineer, ini adalah pengingat bahwa eksploitasi tingkat lanjut sering kali bukan tentang menemukan bug baru, tetapi tentang memahami bagaimana sistem mempercayai data dan di mana kepercayaan itu bisa disalahgunakan.

Benediktus Sava – Security Researcher

Sumber:

Github Advisory Database

WIZ IO

Exploit Chain di Windows: Menggabungkan LNK, NTLM, dan RCE - Ethical Hacking Indonesia

CVE-2026-32202 terlihat seperti vulnerability spoofing dengan severity “medium”, tetapi problem sebenarnya jauh lebih dalam: kegagalan desain dalam validasi trust boundary antara resource lokal dan network di Windows Shell. Ini tidak hanya bug parsing, melainkan efek lanjutan dari patch yang tidak lengkap pada CVE sebelumnya (CVE-2026-21510). Dalam konteks sistem operasi modern, ketika komponen seperti Windows Shell diberi kemampuan untuk resolve resource lintas protokol (local path, UNC path, namespace virtual), maka validasi origin menjadi krusial. Di sini, validasi tersebut gagal dan membuka jalur untuk authentication coercion dan spoofing.

Secara teknis, akar masalahnya ada pada bagaimana Windows Shell memproses file shortcut (.lnk) dan namespace object. Ketika sebuah LNK file mengandung referensi ke resource eksternal melalui UNC path seperti \\attacker\share\file, Windows akan mencoba mengakses resource tersebut bahkan tanpa interaksi eksplisit dari user dalam beberapa kondisi (auto-parsing, preview handler, indexing). Proses ini secara implisit memicu autentikasi menggunakan NTLM ke server remote. Karena tidak ada validasi network zone yang ketat, sistem memperlakukan request tersebut sebagai legitimate access attempt. Ini menghasilkan kondisi klasik authentication coercion di mana korban “dipaksa” mengirimkan kredensial tanpa sadar.

Baca Juga Tentang: Bagaimana File Shortcut Windows Bisa Jadi Entry Point Malware

Mekanisme namespace parsing di Windows Shell memungkinkan attacker menyamarkan resource berbahaya sebagai objek yang terlihat trusted, seperti Control Panel item (CPL). Ketika DLL di-load melalui jalur ini, sistem tidak selalu menerapkan proteksi seperti SmartScreen secara konsisten, terutama jika eksekusi terjadi di layer Shell, bukan langsung dari user execution context. Ini menjelaskan kenapa vulnerability ini efektif untuk bypass proteksi berbasis reputasi dan origin.

Skenario eksploitasi realistisnya tidak harus kompleks. Attacker dapat mengirimkan file .lnk melalui email atau platform kolaborasi seperti Teams atau Slack. Bahkan dalam beberapa kasus, file tersebut tidak perlu diklik cukup di-render oleh Windows Explorer (misalnya preview atau indexing), sistem sudah melakukan request ke server attacker. Ketika koneksi ke UNC path terjadi, NTLM authentication akan dikirim secara otomatis. Attacker kemudian dapat melakukan NTLM relay attack ke service internal seperti SMB atau LDAP untuk mendapatkan akses lebih lanjut, atau melakukan offline cracking terhadap hash yang diperoleh. Dalam skenario yang lebih advance, ini bisa digabungkan dengan vulnerability lain untuk mencapai remote code execution.

Baca Juga Tentang: NTLM Relay Attack dan SMB Credential Harvesting

Dampaknya memang diklasifikasikan hanya sebagai “confidentiality low”, tetapi ini misleading jika dilihat dari perspektif attack chain. Credential leakage adalah titik awal yang sangat kuat dalam intrusion. Dengan satu hash NTLM, attacker bisa melakukan lateral movement, privilege escalation, atau bahkan compromise domain jika environment tidak dikonfigurasi dengan baik. Dalam operasi APT seperti yang dilakukan APT28, teknik seperti ini jarang berdiri sendiri biasanya menjadi bagian dari multi-stage attack yang menggabungkan social engineering, exploit, dan post-exploitation.

Baca Juga Tentang: APT28: Teknik Serangan yang Digunakan di Dunia Nyata - CVE-2026-21513

Dari sudut pandang praktisi offensive security, insight penting di sini adalah bagaimana Windows masih memiliki implicit trust terhadap protokol lama seperti SMB dan NTLM. Ini menciptakan attack surface yang sulit dihilangkan sepenuhnya karena backward compatibility. Bagi pentester, ini adalah area yang sangat relevan untuk diuji, terutama dalam environment enterprise yang masih mengandalkan NTLM authentication.

Mitigasi harus dilakukan secara berlapis. Patch dari vendor adalah langkah awal, tetapi tidak cukup. Disabling atau membatasi NTLM authentication, terutama outbound NTLM ke network eksternal, adalah langkah krusial untuk mencegah credential leakage. Selain itu, konfigurasi firewall untuk memblokir koneksi SMB outbound ke internet dapat menghentikan exploitation pada tahap awal. Dari sisi endpoint, monitoring terhadap aktivitas anomali seperti koneksi SMB ke host yang tidak dikenal atau proses explorer.exe yang mengakses resource network harus dianggap sebagai indikator kompromi. Untuk hardening tambahan, organisasi dapat menonaktifkan preview handler untuk file yang tidak trusted dan membatasi eksekusi file .lnk dari sumber eksternal. 

Secara lebih luas, CVE-2026-32202 menunjukkan pola yang semakin sering muncul dalam dunia eksploitasi modern: vulnerability bukan lagi soal satu bug kritis, tetapi kombinasi dari design flaw, legacy protocol abuse, dan patch yang tidak sempurna. Ini mengarah pada paradigma baru dalam defensive security bahwa mengandalkan satu layer proteksi tidak cukup. Validasi harus dilakukan di setiap boundary, dan setiap asumsi “trusted” perlu dipertanyakan ulang.

Benediktus Sava – Security Researcher

Sumber:

Microsoft

CVE

SecurityWeek

Memahami Supply Chain Attack dalam Ekosistem Software Modern (CheckMarX) - Ethical Hacking Indonesia

Bagaimana trust pada pipeline development dapat menjadi entry point paling kritis dalam arsitektur modern. Problem utamanya terletak pada kompromi supply chain melalui komponen yang dianggap “aman” seperti vulnerability scanner (Trivy), GitHub Actions workflow, dan plugin development. Ketika komponen ini disusupi, attacker tidak perlu menyerang production secara langsung mereka cukup menargetkan proses build dan distribusi yang secara implisit dipercaya oleh seluruh sistem.

Secara teknis, attack surface utama di sini adalah GitHub Actions dan integrasi CI/CD. Workflow GitHub Actions biasanya berjalan dengan akses ke secrets seperti GITHUB_TOKEN, API keys, dan environment variables yang digunakan untuk build, deploy, atau scanning. Ketika attacker berhasil memodifikasi workflow atau dependency (seperti plugin dari Open VSX), mereka dapat menyisipkan malicious code yang dieksekusi setiap kali pipeline berjalan. Karena eksekusi terjadi dalam konteks trusted automation, malware tersebut memiliki akses langsung ke secrets tanpa perlu bypass autentikasi tambahan. Ini menjelaskan bagaimana credential harvesting bisa terjadi secara masif tanpa terdeteksi di tahap awal.

Skenario eksploitasi yang realistis dalam kasus ini kemungkinan dimulai dari compromise terhadap dependency seperti Trivy atau plugin yang digunakan dalam workflow. Attacker menyisipkan payload yang melakukan exfiltration terhadap environment variables, misalnya dengan mengirimkan token ke remote server melalui HTTP request terselubung. Setelah mendapatkan GitHub token dengan scope yang cukup, attacker dapat mengakses repository, membaca source code, serta mengidentifikasi file konfigurasi yang berisi credential tambahan seperti akses database MongoDB atau MySQL. Dari sini, eksploitasi berkembang menjadi lateral movement: attacker bisa masuk ke sistem lain yang menggunakan credential tersebut, termasuk container image seperti KICS Docker atau bahkan CLI tools downstream seperti Bitwarden.

Baca Juga Tentang: Bahaya Credential Attack 

Dampak dari pendekatan ini jauh lebih berbahaya dibandingkan breach konvensional karena sifatnya yang cascading. Ketika pipeline terkompromi, semua artefak yang dihasilkan binary, container image, bahkan extension berpotensi membawa payload berbahaya. Ini membuka peluang untuk software supply chain poisoning, di mana user yang menginstall tool resmi justru menjadi korban. Dalam konteks Checkmarx, kebocoran API key, token autentikasi, dan database credential juga memungkinkan attacker melakukan privilege escalation ke sistem internal, bahkan jika repository secara teori tidak menyimpan data pelanggan. Selain itu, publikasi data di dark web menunjukkan adanya monetisasi, sejalan dengan pola operasi grup seperti LAPSUS$ yang lebih fokus pada data theft dan extortion dibanding ransomware.

Baca Juga Tentang: Apa Itu Supply Chain Attack dalam Cyber Security?

Insight penting bagi praktisi adalah bahwa identity dalam pipeline (token, service account, automation credential) kini menjadi target utama attacker. Ini menggeser paradigma dari “exploit vulnerability” menjadi “exploit trust.” Banyak organisasi masih menganggap secrets di CI/CD sebagai komponen internal yang aman, padahal secara praktik, pipeline adalah environment dengan privilege tinggi dan visibilitas rendah. Ketika attacker berhasil masuk ke sana, mereka tidak hanya mencuri data tetapi juga dapat memodifikasi supply chain itu sendiri.

Mitigasi untuk kasus seperti ini tidak cukup dengan mem-patch vulnerability atau membatasi akses repository. Pertama, semua workflow CI/CD harus diperlakukan sebagai code execution environment yang tidak trusted. Validasi integritas dependency (misalnya melalui checksum atau signature verification) menjadi wajib, terutama untuk tool eksternal seperti Trivy atau plugin marketplace. Kedua, gunakan short-lived token dan workload identity daripada long-lived credential untuk mengurangi dampak credential leakage. Ketiga, isolasi environment pipeline sehingga secrets hanya tersedia pada step yang benar-benar membutuhkan, bukan secara global. Keempat, lakukan monitoring terhadap outbound traffic dari pipeline karena exfiltration sering kali terjadi melalui channel ini dan jarang diawasi.

Organisasi perlu mengadopsi pendekatan supply chain security yang lebih matang, seperti implementasi Software Bill of Materials (SBOM), code signing untuk artefak build, dan verifikasi reproducible build. Tanpa itu, sangat sulit membedakan apakah artefak yang dihasilkan masih “bersih” atau sudah terkontaminasi. Insiden ini juga menegaskan bahwa dependency eksternal, bahkan yang open-source dan populer, tetap harus diasumsikan sebagai potential attack vector.

Pada akhirnya, kasus Checkmarx memberitahu bahwa serangan modern tidak lagi berfokus pada perimeter, melainkan pada ekosistem kepercayaan. Ketika attacker berhasil memanipulasi pipeline, mereka tidak hanya mencuri akses mereka mengontrol bagaimana software dibangun dan didistribusikan. Dalam konteks offensive security, ini adalah level kompromi yang memberikan leverage maksimal dengan effort relatif rendah, terutama jika dibandingkan dengan eksploitasi langsung ke production system.

Benediktus Sava – Security Researcher

Sumber:

Checkmarx Security Update

Data Breach di Indonesia: Kenapa Dampaknya Jauh Lebih Berbahaya dari yang Kamu Kira - Ethical Hacking Indonesia

 

Data yang Bocor Itu Sebenarnya Bernilai Tinggi

Tidak semua orang memahami kenapa email atau nomor HP bisa berbahaya jika bocor. Dari perspektif attacker, setiap potongan data punya fungsi spesifik. Email dan password misalnya, bukan hanya untuk satu akun. Karena kebiasaan password reuse masih sangat tinggi di Indonesia, satu kombinasi credential bisa membuka akses ke banyak layanan lain. Attacker tidak perlu “hack” sistem cukup mencoba login ke berbagai platform menggunakan data yang sudah bocor.

Nomor HP punya peran yang lebih krusial. Di Indonesia, banyak layanan masih bergantung pada SMS OTP sebagai lapisan keamanan. Ini menjadikan nomor HP sebagai target utama, baik untuk intercept OTP melalui malware, maupun melalui manipulasi sosial.

Sementara itu, data seperti NIK, nama lengkap, dan alamat memperkuat serangan social engineering. Semakin lengkap data korban, semakin mudah attacker membangun skenario yang terlihat meyakinkan. Ini yang membuat korban sering tidak sadar bahwa mereka sedang diserang.

Dari Data Bocor ke Rekening Kosong: Alur Serangan Nyata

Untuk memahami dampaknya, kamu harus melihat data breach sebagai bagian dari attack chain, bukan kejadian tunggal.

Tahap pertama dimulai ketika data bocor dan masuk ke database attacker, biasanya dalam bentuk combo list. Data ini bisa berasal dari satu atau banyak platform, lalu dikompilasi dan dijual di forum atau marketplace tertentu. 

Tahap berikutnya adalah credential stuffing. Attacker akan mencoba kombinasi email dan password tersebut ke berbagai layanan populer email, marketplace, media sosial, hingga layanan finansial. Karena banyak pengguna menggunakan password yang sama, tingkat keberhasilannya tidak kecil.

Jika attacker berhasil masuk ke email, permainan hampir selesai. Email adalah pusat kontrol identitas digital. Dari sana, attacker bisa melakukan reset password ke akun lain, termasuk mobile banking atau e-wallet. 

Masalahnya tidak berhenti di situ. Ketika OTP dikirim ke nomor korban, attacker bisa menggunakan teknik social engineering untuk mendapatkannya, atau dalam kasus yang lebih kompleks, menggunakan malware yang sudah lebih dulu terpasang di perangkat korban untuk membaca SMS secara diam-diam.

Ditahap ini, akses finansial sudah terbuka. Uang bisa dipindahkan, akun bisa diambil alih, bahkan identitas korban bisa digunakan untuk menipu orang lain. Semua ini berawal dari satu hal yang sering dianggap sepele: data yang bocor.

Kenapa Dampaknya Lebih Parah di Indonesia

Ada faktor lingkungan yang membuat dampak data breach di Indonesia lebih berbahaya dibanding banyak negara lain.

Pertama, tingkat penggunaan password yang sama di banyak platform masih sangat tinggi. Ini memperbesar efektivitas credential stuffing tanpa perlu teknik hacking yang kompleks. 

Kedua, literasi keamanan digital masih rendah. Banyak pengguna belum memahami bagaimana serangan bekerja, sehingga mudah dimanipulasi melalui pesan yang terlihat “resmi” atau mendesak.

Ketiga, WhatsApp menjadi channel komunikasi utama. Ini menciptakan kondisi “high trust environment”, di mana pesan yang masuk cenderung langsung dipercaya, terutama jika menggunakan identitas yang dikenal.

Keempat, masih banyak layanan yang bergantung pada SMS OTP sebagai metode autentikasi utama. Ini membuka peluang untuk berbagai teknik bypass, baik melalui malware maupun manipulasi sosial.

Gabungan dari semua faktor ini menciptakan kondisi yang ideal bagi attacker: target yang banyak, proteksi rendah, dan peluang monetisasi yang tinggi.

Skenario Nyata yang Sering Terjadi

Bayangkan seseorang menggunakan email yang sama untuk banyak layanan, dengan password yang tidak pernah diganti. Suatu hari, salah satu platform mengalami kebocoran data. Data tersebut kemudian masuk ke tangan attacker. Mereka mencoba login ke email korban dan berhasil. Dari sana, attacker melakukan reset password ke akun lain, termasuk akun finansial.

Korban menerima OTP, tapi dalam kondisi panik karena mendapat pesan mencurigakan, mereka justru memberikan kode tersebut atau tidak menyadari bahwa perangkat mereka sudah terinfeksi aplikasi berbahaya. Beberapa menit kemudian, saldo rekening mulai berkurang. Dalam banyak kasus, korban baru sadar setelah semuanya terlambat.

Yang jarang disadari: serangan itu tidak terjadi secara tiba-tiba. Semua sudah dimulai sejak data pertama kali bocor.

Dampak Jangka Panjang yang Tidak Terlihat

Salah satu kesalahan terbesar adalah menganggap dampak data breach hanya terjadi sekali. Faktanya, data yang sudah bocor hampir tidak bisa “ditarik kembali”.

Data tersebut bisa terus beredar, berpindah dari satu attacker ke attacker lain, digunakan ulang dalam berbagai kampanye serangan. Bahkan bertahun-tahun kemudian, data yang sama masih bisa relevan. Lebih jauh lagi, attacker bisa membangun profil korban. Mereka tahu kebiasaan, layanan yang digunakan, bahkan pola interaksi. Ini memungkinkan serangan yang jauh lebih terarah dan sulit dideteksi.

Dalam konteks ini, data breach bukan sekadar insiden melainkan investasi jangka panjang bagi pelaku kejahatan siber.

Mitigasi: Bukan Sekadar  Waspada Tetapi Sistematis

Menghadapi risiko seperti ini, pendekatan yang dibutuhkan bukan sekadar berhati-hati, tapi sistematis.

Menggunakan password manager adalah langkah fundamental. Ini memungkinkan setiap akun memiliki password unik tanpa harus menghafalnya. Tanpa ini, kebiasaan reuse hampir tidak terhindarkan. Menghindari penggunaan password yang sama di berbagai layanan bukan lagi pilihan, tapi keharusan. Satu kebocoran saja bisa membuka banyak pintu sekaligus.

Mengaktifkan autentikasi dua faktor juga penting, tetapi sebaiknya tidak bergantung pada SMS. Aplikasi authenticator memberikan lapisan keamanan yang lebih kuat dibanding OTP berbasis nomor HP. Selain itu, penting untuk memisahkan email berdasarkan fungsi. Email utama untuk layanan kritikal tidak seharusnya digunakan untuk registrasi di platform yang tidak penting. Ini mengurangi blast radius jika terjadi kebocoran.

Terakhir, monitoring menjadi kunci. Mengetahui lebih awal bahwa data kamu sudah bocor memberi waktu untuk melakukan mitigasi sebelum attacker memanfaatkannya.

Kesimpulannya apa?

Jika ada satu hal yang harus diubah dari cara pandang publik di Indonesia, itu adalah persepsi terhadap data breach. Ini bukan sekadar kebocoran informasi, tapi awal dari rantai serangan yang bisa berkembang jauh lebih besar.

Di dunia cybersecurity, attacker jarang bekerja secara instan. Mereka mengumpulkan, menganalisis, dan menunggu momen yang tepat. Data yang terlihat tidak berbahaya hari ini, bisa menjadi senjata utama dalam serangan besok.

Jadi ketika data kamu bocor, pertanyaannya bukan lagi “apa yang terjadi sekarang”, tapi “apa yang bisa terjadi setelah ini.”

Benediktus Sava – Security Researcher

Baca Juga Tentang:

Kebocoran Data POLRI dan Dampaknya terhadap Trust Model dalam Sistem Keamanan

Analisa Kebocoran Data Akademik Indonesia dan Risiko Identity Attack BIMA dan Universitas Negeri malang

England Hockey Selidiki Dugaan Kebocoran Data Setelah Geng Ransomware AiLock Klaim Mencuri 129GB Data