Dirty Frag: Root Exploit Linux via Page Cache Corruption, Penerus Copy Fail - Ethical Hacking Indonesia

Dirty Pipe sempat dianggap sebagai salah satu bug Linux kernel paling berbahaya karena memungkinkan overwrite terhadap page cache tanpa hak akses root. Namun munculnya Dirty Frag menunjukkan bahwa class vulnerability tersebut belum benar-benar teratasi dengan sempurna. Yang berubah hanya jalur masuknya.

Dirty Frag bukan sesuatu yang hanya baru tetapi dari Dirty Pipe. Vulnerability ini memperlihatkan bahwa Linux kernel masih memiliki pola logic flaw serupa pada jalur fast-path networking tertentu, khususnya di subsystem XFRM ESP dan RxRPC. Dampaknya jauh lebih serius dibanding sekadar local file corruption karena primitive yang dihasilkan dapat dipakai untuk memperoleh root privilege secara stabil di hampir seluruh distribusi Linux modern.

Yang membuat kasus ini menarik bukan hanya exploitability-nya, tetapi fakta bahwa vulnerability ini bersifat deterministic. Tidak ada race condition. Tidak ada timing attack rumit. Tidak ada kernel panic ketika gagal. Exploit berjalan konsisten karena masalahnya berasal dari kesalahan logika ownership memory pada page cache.

Secara teknis, inti masalah berada pada bagaimana Linux menangani fragment page (frag) dalam struct sk_buff saat proses dekripsi packet di jalur fast-path. Pada kondisi tertentu, kernel melakukan operasi in-place decryption terhadap page yang sebenarnya masih direferensikan oleh user space melalui mekanisme seperti splice(), sendfile(), atau MSG_SPLICE_PAGES.

Masalah muncul karena kernel menganggap page tersebut aman untuk dimodifikasi langsung, padahal ownership-nya bukan eksklusif milik kernel. Akibatnya, proses dekripsi justru menulis ulang data ke page cache yang masih dapat diakses oleh unprivileged process.

Secara sederhana, alurnya terlihat seperti ini:

1. User space membuat page-backed buffer menggunakan mekanisme zero-copy seperti splice()
2. Buffer tersebut masuk ke networking stack
3. Kernel melakukan dekripsi packet langsung pada frag page tanpa Copy-on-Write
4. Data pada page cache berubah
5. User space mendapatkan akses terhadap hasil modifikasi kernelv

Ini menciptakan primitive write terhadap page cache. Pada xfrm-ESP variant, primitive tersebut berupa arbitrary 4-byte STORE yang sangat mirip dengan Copy Fail.

Baca Juga Tentang: Copy Fail - CVE-2026-31431

Masalah fundamentalnya bukan hanya memory corruption biasa, tetapi kegagalan boundary ownership antara kernel dan user-controlled pages.

Yang membuat Dirty Frag berbahaya adalah chaining antar dua vulnerability berbeda untuk menutup blind spot satu sama lain.

Variant pertama berasal dari subsystem IPSec/XFRM (esp4 dan esp6). Exploit ini powerful karena tersedia hampir di seluruh distro Linux modern dan menghasilkan primitive write yang sangat stabil. Namun terdapat satu kendala: attacker memerlukan kemampuan membuat unprivileged user namespace.

Di Ubuntu modern, AppArmor sering memblokir namespace creation bagi user biasa. Ini membuat exploit ESP gagal dijalankan. 

Di titik inilah RxRPC digunakan sebagai fallback path.

RxRPC variant tidak memerlukan namespace privilege sama sekali. Tetapi modul rxrpc.ko justru tidak tersedia di sebagian besar distribusi enterprise seperti RHEL default installation.

Hasil akhirnya :

• Pada distro yang mengizinkan user namespace -- gunakan xfrm-ESP
• Pada Ubuntu yang memblokir namespace tetapi memuat RxRPC -- gunakan RxRPC

Artinya attacker tidak perlu peduli terhadap hardening spesifik distro. Mereka cukup memilih jalur exploit yang tersedia.

Pendekatan ini memperlihatkan pola modern Linux exploitation: bukan lagi single bug exploitation, melainkan exploit orchestration antar subsystem kernel.

Dari perspektif offensive security, ini lebih dekat ke konsep “capability chaining” dibanding eksploitasi tradisional.

Yang lebih mengkhawatirkan adalah lifetime vulnerability ini.

xfrm-ESP variant berasal dari commit tahun 2017. Artinya bug tersebut hidup hampir 9 tahun di production kernel tanpa terdeteksi. Bahkan commit yang sama juga menjadi akar dari CVE-2022-27666 beberapa tahun lalu.

Ini menunjukkan sesuatu yang lebih kompleks: fast-path optimization di networking stack Linux memiliki attack surface yang jauh lebih besar dibanding yang selama ini diasumsikan.

Fast-path biasanya dibuat untuk performa tinggi:

• zero-copy networking
• splice optimization
• sendfile acceleration
• page reuse
• no-COW operations

Namun seluruh optimasi ini sangat sensitif terhadap ownership tracking. Sedikit kesalahan validasi reference counter atau COW handling dapat berubah menjadi privilege escalation primitive.

Dirty Frag memperlihatkan bahwa performa dan security isolation sering kali berada dalam konflik langsung di level kernel architecture.

Dalam skenario realistis, exploit ini sangat relevan untuk post-exploitation cloud environment.

Misalnya:

• attacker memperoleh low-privilege shell melalui vulnerable web application
• container escape tidak tersedia
• SELinux/AppArmor aktif
• kernel terbaru dianggap aman

Pada kondisi normal, privilege escalation modern biasanya memerlukan exploit race condition yang tidak stabil.

Dirty Frag mengubah situasi itu.

Karena exploit bersifat deterministic dan tidak membutuhkan race timing, attacker dapat memperoleh root secara konsisten tanpa menghasilkan crash yang menarik perhatian monitoring system.

Pada environment CI/CD atau shared-hosting Linux, dampaknya bahkan lebih serius karena:

• local user dapat memperoleh full root
• namespace isolation dapat dilewati
• credential host dapat dicuri
• container breakout menjadi lebih mudah

Kasus ini juga memperlihatkan kelemahan pendekatan mitigasi parsial.

Sebelumnya banyak administrator memitigasi Copy Fail dengan mem-blacklist algif_aead.

Namun Dirty Frag tetap bekerja walaupun mitigasi tersebut diterapkan karena sink vulnerability berada pada jalur berbeda.

Ini insight penting bagi defender: blacklist berbasis symptom sering kali gagal ketika bug class dasarnya belum benar-benar dipahami.

Selama page cache ownership flaw masih ada di subsystem lain, exploit baru akan terus muncul dengan primitive serupa.

Sampai patch resmi tersedia, mitigasi paling realistis saat ini adalah memblokir module terkait:

""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

printf 'install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
' > /etc/modprobe.d/dirtyfrag.conf

rmmod esp4 esp6 rxrpc

""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

Mitigasi ini memang mengurangi attack surface, tetapi memiliki konsekuensi operasional:

• IPSec tertentu dapat berhenti bekerja
• fitur RxRPC tidak tersedia
• beberapa workload networking mungkin terdampak

Bagi security engineer, prioritas utama saat ini bukan hanya patching, tetapi visibility.

Hal yang perlu dipantau:

• penggunaan splice() abnormal
• namespace creation oleh unprivileged user
• loading module networking tidak biasa
• aktivitas local privilege escalation setelah foothold awal
• proses yang memanfaatkan MSG_SPLICE_PAGES

Dirty Frag kemungkinan bukan vulnerability terakhir dari family ini.

Karena akar masalahnya berada pada interaksi page cache, zero-copy optimization, dan ownership validation, masih sangat mungkin terdapat sink lain di networking stack Linux yang belum ditemukan.

Dan itu yang membuat vulnerability class seperti Dirty Frag jauh lebih penting dibanding sekadar satu CVE individual: ia membuka pola eksploitasi baru terhadap kernel modern.

Benediktus Sava – Security Researcher

Sumber:

Github

Openwall

Copy Fail - Ethical Hacking Indonesia

Analisa Mirai xlabs_v1 dan Eksploitasi ADB Android - Ethical Hacking Indonesia

Botnet Mirai tidak pernah benar-benar mati. Tetapi mengalami evolusi mengikuti permukaan serangan baru yang dianggap normal oleh pengguna rumahan. Pada kasus xlabs_v1, evolusi tersebut terlihat jelas: operator tidak lagi fokus pada DVR murah atau router lawas seperti generasi Mirai awal, tetapi mulai memonetisasi ekosistem Android dan IoT modern yang secara tidak sadar mengekspos Android Debug Bridge (ADB) ke internet melalui TCP/5555.

Baca Juga Tentang: Apa itu Mirai Botnet?

Permasalahan utamanya bukan hanya keberadaan ADB yang terbuka. Banyak vendor Android TV box, STB, smart TV, dan firmware IoT murah mengirim perangkat dengan debugging aktif secara default atau dengan implementasi ADB yang lemah. Dalam praktiknya, perangkat ini sering berada di belakang NAT rumah tangga dengan bandwidth besar seperti fiber 100–500 Mbps. Dari perspektif operator DDoS-for-hire, perangkat seperti ini jauh lebih bernilai dibanding router DSL era lama karena throughput upstream jauh lebih tinggi dan uptime cenderung stabil.

Baca Juga Tentang: Android Debug Bridge

xlabs_v1 memanfaatkan kondisi tersebut secara agresif. Begitu menemukan host dengan TCP/5555 terbuka, operator mengirim payload shell sederhana melalui ADB untuk menurunkan binary bot sesuai arsitektur target. Ini menjelaskan mengapa mereka menyediakan build ARM, MIPS, PowerPC, hingga x86-64. Strategi multi-arsitektur seperti ini merupakan karakteristik khas ekosistem Mirai modern: tujuan utamanya bukan sophistication, tetapi coverage maksimal terhadap fragmentasi perangkat IoT.

Baca Juga Tentang: ELF (Executable and Linkable Format)  Binary

Yang menarik, bot ini tidak didesain sebagai malware multifungsi. Tidak ada credential theft, ransomware, ataupun spyware. Secara operasional, seluruh arsitektur diarahkan untuk satu tujuan komersial: menghasilkan trafik DDoS yang dapat dijual. Dari sisi tradecraft kriminal, keputusan ini masuk akal. Menambahkan fitur pencurian data hanya meningkatkan noise, forensic footprint, dan risiko deteksi tanpa meningkatkan profit utama operator.

Secara teknis, salah satu indikator bahwa operasi ini bersifat komersial adalah adanya bandwidth profiling subsystem. Ketika menerima opcode tertentu dari C2, bot membuka 8.192 koneksi TCP paralel ke server Speedtest terdekat dan mengukur throughput upstream selama sekitar 10 detik. Hasil Mbps kemudian dikirim kembali ke panel operator.

Ini bukan sekadar fitur diagnostik. Ini adalah mekanisme pricing engine. Operator mengelompokkan bot berdasarkan kapasitas bandwidth sehingga Android TV box dengan koneksi fiber 500 Mbps memiliki “nilai sewa” lebih tinggi dibanding perangkat DSL 20 Mbps. Dalam konteks underground DDoS market, ini menunjukkan xlabs_v1 diperlakukan layaknya inventory komersial, bukan sekadar malware eksperimental.

Arsitektur command-and-control mereka juga cukup menarik. Banyak botnet kecil masih menggunakan komunikasi plaintext sederhana tanpa redundansi. xlabs_v1 sedikit lebih matang. Mereka menggunakan OpenNIC-aware DNS resolution sebelum fallback ke resolver sistem biasa. Artinya, ketika domain .lol diblokir resolver ICANN normal, bot masih bisa mendapatkan resolusi melalui root alternatif OpenNIC.

Baca Juga Tentang: DNS (Domain Name System) Abuse

Selain itu, ketika outbound C2 gagal, bot membuka listener fallback pada TCP/26721 dan menambahkan aturan iptables untuk memastikan port tersebut tetap dapat diakses. Secara praktis, ini mengubah korban menjadi semacam reverse-entry node yang bisa diakses operator kapan saja. Ini bukan persistence tradisional seperti systemd service atau cronjob, tetapi persistence berbasis reinfection dan re-entry network path.

Di sinilah implikasi defensifnya menjadi lebih serius. Banyak organisasi menganggap reboot perangkat IoT sudah cukup untuk membersihkan malware volatile. Pada xlabs_v1, asumsi itu tidak selalu efektif. Jika ADB masih terekspos, operator dapat menginfeksi ulang perangkat dalam hitungan menit menggunakan automation script yang sama.

Dari sisi exploit chain, mekanismenya sebenarnya cukup sederhana tetapi efektif karena memanfaatkan miskonfigurasi massal. Skenario realistisnya seperti berikut:

Seorang pengguna rumahan membeli Android TV box murah yang secara default mengaktifkan ADB over TCP. Perangkat tersebut terhubung langsung ke ISP fiber rumahan tanpa firewall inbound yang memadai. Operator botnet melakukan scanning internet untuk TCP/5555 terbuka, kemudian mengirim payload shell melalui ADB yang men-download binary ARM7 ke /data/local/tmp/arm7, mengubah permission menjadi executable, lalu menjalankannya secara background.

Begitu aktif, bot akan:

• menyamarkan proses menjadi /bin/bash,
• mematikan proses malware pesaing,
• melakukan registrasi ke C2,
• melaporkan resource sistem,
• menunggu opcode serangan.

Ketika pelanggan DDoS-for-hire memesan serangan terhadap server Minecraft, operator cukup mengirim opcode flood tertentu ke seluruh bot aktif. Karena banyak perangkat korban berada di jaringan fiber rumahan dengan bandwidth besar, total flood traffic yang dihasilkan bisa sangat signifikan.

Baca Juga Tentang: Mekanisme Layer 7 DDoS

Fokus terhadap Minecraft dan game server bukan kebetulan. xlabs_v1 memiliki implementasi flood berbasis RakNet serta varian UDP yang dirancang menyerupai trafik OpenVPN untuk melewati mitigasi DDoS consumer-grade. Ini menunjukkan operator memahami pola filtering umum yang digunakan hosting murah dan proteksi anti-DDoS entry-level.

Secara arsitektural, pendekatan ini lebih dekat ke “application-aware DDoS tooling” dibanding Mirai klasik yang hanya mengandalkan SYN flood generik. Bahkan terdapat raw TCP variant yang menggunakan template HTTP tertentu untuk melewati proteksi Layer-7 sederhana.

Ada detail lain yang cukup penting bagi defender: subsystem pembunuh kompetitor. Bot melakukan enumerasi /proc/, mencari proses lain yang memegang socket aktif, lalu melakukan SIGSTOP dan SIGKILL. Mereka bahkan secara spesifik menargetkan port TCP/24936 yang diasosiasikan dengan rival botnet tertentu.

Ini menunjukkan ekosistem botnet IoT saat ini tidak hanya tentang menyerang korban akhir, tetapi juga perang antar operator malware untuk memperebutkan bandwidth perangkat yang sama. Dalam praktik incident response, hilangnya proses pada port tertentu secara mendadak setelah aktivitas ADB mencurigakan dapat menjadi indikator kompromi xlabs_v1.

Walaupun operator mencoba menerapkan obfuscation menggunakan ChaCha20 string table, implementasinya lemah. Mereka menggunakan nonce reuse dan key reuse yang memungkinkan peneliti melakukan recovery string melalui known-plaintext analysis. Dari sinilah identitas seperti xlabs_v1, Tadashi, hingga authentication token berhasil dipulihkan.

Baca Juga Tentang: Reverse Engineering Malware

Kesalahan desain semacam ini sering terjadi pada malware “mid-tier”. Operator memahami konsep cryptography tetapi gagal menerapkannya dengan benar. Ini juga terlihat dari fakta bahwa development build non-stripped sempat terekspos di staging server publik bersama payload, proxy credentials, dan target list.

Dalam dunia operasi malware profesional, kesalahan operational security seperti ini sangat mahal karena memungkinkan peneliti memetakan keseluruhan infrastruktur hanya dari satu exposed directory listing.

Konteks yang lebih luas dari kasus ini sebenarnya berkaitan dengan industrialisasi DDoS-as-a-Service berbasis IoT. Dulu, botnet IoT identik dengan perangkat murah berbandwidth rendah. Sekarang, perangkat Android dan smart home berbasis fiber menjadi “high-bandwidth commodity nodes”. Perubahan ini membuat kapasitas serangan meningkat drastis tanpa perlu kompromi server enterprise.

Bagi pentester dan security engineer, ada beberapa insight defensif penting dari operasi xlabs_v1:

Pertama, ADB over TCP seharusnya diperlakukan seperti remote shell exposure, bukan sekadar fitur debugging. Banyak organisasi masih menganggap TCP/5555 berisiko rendah dibanding SSH atau RDP, padahal secara praktis ia memberikan remote execution path penuh.

Kedua, monitoring outbound traffic jauh lebih penting dibanding hanya inbound detection. Botnet ini menggunakan komunikasi plaintext TCP/35342 dan melakukan koneksi abnormal besar ke Speedtest infrastructure. Aktivitas seperti ribuan koneksi simultan ke domain speedtest merupakan behavioral IOC yang jauh lebih stabil dibanding hash file.

Ketiga, environment IoT dan Android enterprise perlu visibility terhadap proses ephemeral. xlabs_v1 sengaja menghapus jejak argv dan melakukan masquerade /bin/bash agar lolos inspeksi administratif sederhana. Defender yang hanya mengandalkan ps aux berpotensi melewatkan proses aktif.

Mitigasi paling efektif tetap berada di layer exposure reduction. Nonaktifkan ADB over TCP jika tidak diperlukan, blok akses inbound TCP/5555 dari internet, segmentasikan perangkat IoT dari jaringan utama, dan monitor perangkat Android embedded seperti smart TV atau STB sebagaimana endpoint biasa.

Baca Juga Tentang: Threat Hunting

Kasus xlabs_v1 mengingatkan bahwa batas antara “consumer electronics” dan “attack infrastructure” kini semakin tipis. Dalam banyak rumah dan kantor kecil, Android TV box murah sebenarnya sudah memiliki bandwidth yang cukup untuk menjadi node DDoS bernilai tinggi. Operator botnet memahami hal itu jauh lebih cepat dibanding sebagian besar pengguna maupun vendor perangkat.

Benediktus Sava – Security Researcher

Sumber:

Hunt-Io

Android-Com

CloudFlare

MetInfo RCE Chain: Path Traversal ke PHP Code Injection - Ethical Hacking Indonesia

Kerentanan pada MetInfo CMS versi 7.9 hingga 8.1 input tidak disanitasi tetapi secara teknis jauh lebih dalam. Ia menggabungkan tiga elemen yang biasanya dianggap “aman” jika berdiri sendiri: endpoint API (WeChat), mekanisme cache berbasis file, dan parsing string PHP. Ketika ketiganya bertemu dalam satu execution path, hasilnya adalah unauthenticated remote code execution.

Masalah dimulai dari method "weixinreply::wxAdminLogin()" yang memproses request XML dari integrasi WeChat. Dua field, "EventKey" dan "FromUserName", langsung digunakan tanpa validasi ketat. "EventKey" dipakai sebagai parameter "$code" dalam "cache::get()", sementara "FromUserName" disimpan melalui "cache::put()". Secara desain, ini tampak seperti alur caching biasa, tetapi implementasinya membuka celah serius.

Ketika "$code" dapat dikontrol attacker, ia bisa menyisipkan path traversal untuk memanipulasi file yang di-include oleh "cache::get()". Di titik ini, tujuan attacker bukan hanya membaca file, melainkan mengubah state aplikasi. Dengan memaksa hasil tertentu misalnya string "Array" attacker mengarahkan flow ke penulisan file cache baru dengan nama yang bisa diprediksi: "/cache/weixin/Array.php"

Tahap berikutnya adalah inti dari eksploitasi. Nilai "FromUserName" ditulis ke dalam file tersebut dalam konteks string PHP. Di sinilah fitur yang jarang disadari developer menjadi senjata: complex curly syntax dalam PHP memungkinkan evaluasi ekspresi di dalam string. Artinya, input yang tampak seperti teks biasa bisa berubah menjadi kode yang dieksekusi saat file di-include. Ketika file cache itu dipanggil kembali oleh sistem, payload langsung berjalan tanpa hambatan.

Skenario eksploitasi di dunia nyata tidak membutuhkan kondisi yang rumit. Target yang menggunakan plugin WeChat secara default sudah memiliki direktori "/cache/weixin/". Attacker hanya perlu mengirim request XML crafted ke endpoint webhook. Request pertama bertujuan menulis file berisi payload, dan request berikutnya (atau bahkan alur internal yang sama) memicu include file tersebut. Dalam hitungan detik, attacker bisa mendapatkan eksekusi perintah di server, biasanya dilanjutkan dengan drop web shell untuk persistensi.

Dampaknya langsung berada pada level kompromi penuh. Begitu RCE tercapai, batas antara aplikasi dan sistem operasi praktis hilang. Database dapat diakses, konfigurasi dapat diubah, dan sistem bisa dijadikan pivot ke jaringan internal. Dalam konteks yang lebih luas, ini bukan  saja   bug aplikasi, tetapi juga potensi titik masuk untuk serangan supply chain jika CMS digunakan secara luas oleh banyak situs.

Baca Juga Tentang: Remote Code Exceution (RCE)

Yang menarik dari kasus ini adalah bagaimana lapisan cache berubah menjadi attack surface. Banyak sistem menganggap cache sebagai komponen pasif, padahal ketika cache disimpan sebagai file ".php" dan di-include kembali, ia secara efektif menjadi bagian dari runtime execution. Ditambah lagi, endpoint seperti webhook sering diasumsikan “trusted” sehingga jarang mendapat validasi ketat, padahal justru menjadi pintu masuk tanpa autentikasi.

Mitigasi yang efektif harus langsung memutus rantai eksploitasi ini. Validasi input perlu berbasis whitelist dan menolak karakter traversal sejak awal. Lebih penting lagi, mekanisme cache seharusnya tidak pernah menggunakan format executable seperti ".php;" menyimpannya sebagai data (misalnya JSON) sudah cukup untuk kebutuhan caching tanpa membuka risiko eksekusi. Di sisi lain, penggunaan dynamic include berbasis input harus dihindari sepenuhnya. Patch dari vendor memang wajib diterapkan, tetapi tanpa perubahan pola desain seperti ini, risiko serupa akan terus muncul di tempat lain.

Bagi praktisi keamanan, ini contoh jelas bahwa kerentanan kritis sering bukan berasal dari satu bug besar, melainkan dari interaksi beberapa komponen kecil yang masing-masing terlihat “normal”. Ketika boundary antar layer tidak dijaga dengan ketat, sistem akan menciptakan jalur eksekusi yang bahkan tidak disadari oleh developernya sendiri.

Benediktus Sava – Security Researcher

Sumber:

Karmain Security

Eksploitasi CRLF Injection Axios pada Multipart FormData - Ethical Hacking Indonesia

Kerentanan CVE-2026-42037 Axios sebagai isu sanitasi input, tetapi dalam praktiknya membuka primitive yang cukup berbahaya: kemampuan memanipulasi struktur multipart body secara langsung. Ini bukan bypass validasi biasa, melainkan cara untuk mengontrol bagaimana server downstream memahami setiap part dalam request.

Trust Berlebihan pada Metadata File

Dalam banyak arsitektur modern, Node.js sering berperan sebagai proxy layer menerima upload dari user, lalu meneruskan file tersebut ke service lain menggunakan "axios.post()" dengan FormData. Masalah muncul ketika metadata file seperti MIME type "(value.type)" dianggap aman dan langsung digunakan.

Pada implementasi Axios sebelum 1.15.1, nilai type dari objek Blob/File dimasukkan langsung ke header "Content-Type" dalam setiap multipart part, tanpa sanitasi terhadap karakter kontrol seperti "\r\n". Ini menciptakan celah klasik: CRLF injection, tetapi bukan di HTTP header utama melainkan di dalam body multipart itu sendiri.

Perbedaan ini krusial, karena banyak proteksi (termasuk di Node.js v18+) hanya fokus pada header HTTP, bukan struktur internal multipart.

MIME Type ke Header Injection

Secara internal, Axios membangun multipart body dengan format seperti:

--boundary

Content-Disposition: form-data; name="file"; filename="a.jpg"

Content-Type: image/jpeg

<binary data>

Namun karena "value.type" tidak disanitasi, attacker bisa menyisipkan CRLF:

image/jpeg\r\nX-Injected: evil\r\nX-Another: test

Hasil di body:

Content-Type: image/jpeg

X-Injected: evil

X-Another: test

Yang terjadi bukan string injection saja tetapi, header smuggling di level multipart. Parser di server tujuan akan menganggap header tambahan tersebut sebagai bagian sah dari part tersebut.

Menariknya, path lain dalam kode Axios (untuk string value) sudah melakukan sanitasi CRLF. Ini menunjukkan bahwa developer sadar akan risiko ini, tetapi implementasinya tidak konsisten.

Abuse pada Arsitektur Proxy Upload

Skenario realistis yang sering terjadi:

Sebuah aplikasi memiliki fitur upload gambar. File dikirim ke backend Node.js, lalu backend ini meneruskan file ke storage service atau API lain menggunakan Axios.

Attacker mengunggah file dengan MIME type yang dimodifikasi:

image/png\r\nContent-Disposition: form-data; name="role"\r\n\r\nadmin

Ketika Axios membangun multipart request, payload ini akan:

• Menutup header asli
• Menyisipkan field baru (role=admin)
• Mengubah struktur form-data

Jika server downstream tidak memvalidasi dengan ketat, maka:

• Field tambahan bisa diterima sebagai input valid
• Validasi berbasis Content-Type bisa dilewati
• Bahkan memungkinkan manipulasi parameter tanpa terlihat di layer aplikasi awal

Ini menjadi sangat berbahaya jika backend downstream menggunakan parsing multipart untuk menentukan logika bisnis (misalnya role assignment, metadata processing, atau routing file).

Boundary Confusion

Yang membuat vulnerability ini menarik adalah sifatnya sebagai boundary confusion attack.

Biasanya, developer berpikir bahwa:

• HTTP header ---- dilindungi
• Body --- data mentah

Namun multipart adalah hybrid: ia memiliki struktur seperti header di dalam body. Dan di sinilah blind spot muncul.

Beberapa insight penting untuk praktisi:

• Banyak WAF tidak menginspeksi per-part headers secara mendalam
• Parser multipart di berbagai framework memiliki perilaku berbeda (permissive vs strict)
• Injection seperti ini bisa digunakan untuk desync antara proxy dan backend

Dengan kata lain, ini bisa menjadi bagian dari attack chain yang lebih besar, seperti:

• request smuggling (layer aplikasi)
• validation bypass
• bahkan exploit chaining ke vulnerability parsing lain

Filter Bypass ke Data Manipulation

Dampak langsung mungkin terlihat “hanya” integrity issue, tapi dalam sistem nyata bisa berkembang:

Pertama, attacker bisa melewati filter upload berbasis MIME type. Jika server hanya memeriksa Content-Type dari part, maka header yang dimanipulasi bisa membuat file berbahaya terlihat legitimate.

Kedua, attacker bisa menyisipkan field tambahan dalam multipart body. Ini membuka kemungkinan manipulasi parameter yang tidak dikontrol oleh aplikasi awal.

Ketiga, dalam sistem yang kompleks (microservices atau API chaining), ini bisa menyebabkan data misrouting di mana service downstream memproses data dengan konteks yang salah.

Dalam konteks lebih luas, ini relevan dengan:

• API gateway trust issue
• data integrity attack
• supply chain input manipulation

Karena Axios digunakan sangat luas, blast radius vulnerability ini cukup besar, terutama pada service yang berperan sebagai relay.

Patch resmi di versi 1.15.1 menambahkan sanitasi terhadap "value.type", menghapus karakter CRLF sebelum digunakan. Ini langkah penting, tetapi bukan satu-satunya.

Pendekatan defensif yang lebih kuat mencakup:

• Validasi MIME type di sisi server, bukan hanya meneruskan dari client
• Jangan mempercayai metadata file dari user (termasuk filename dan type)
• Gunakan parser multipart yang strict dan menolak header anomali
• Implementasi allowlist untuk Content-Type yang diizinkan
• Logging terhadap anomali multipart structure (misalnya header tambahan dalam part)

Ini menunjukkan bagaimana library yang sangat umum seperti Axios bisa menjadi bagian dari attack surface ketika digunakan dalam konteks yang salah. Bukan karena library-nya “buruk”, tetapi karena asumsi trust terhadap input tidak ditegakkan dengan benar.

CRLF injection di multipart bukan teknik baru, tetapi implementasi seperti ini menghidupkan kembali teknik lama dalam konteks modern khususnya di arsitektur berbasis API dan microservices.

Bagi pentester, ini adalah peluang untuk mengeksplorasi area yang sering diabaikan: struktur internal request, bukan hanya endpoint.
Bagi developer, ini pengingat bahwa setiap data yang berasal dari user bahkan yang terlihat sepele seperti MIME type harus diperlakukan sebagai input tidak terpercaya.

Benediktus Sava – Security Researcher

Sumber:

NIST-NVD

Github Advisory Database

Weaver E-cology RCE: Abuse Debug Dubbo API Tanpa Auth - Ethical Hacking Indonesia

Kerentanan CVE-2026-22679 di Weaver E-cology 10.0 sebuah endpoint tanpa autentikasi yang mengarah ke remote code execution. Namun jika dilihat dari sudut pandang arsitektur, ini bukan bug biasa, melainkan kegagalan boundary antara komponen internal (RPC debug interface) dan exposure eksternal (HTTP layer). Dalam banyak kasus modern, justru kesalahan seperti inilah yang menghasilkan kompromi paling fatal.

Masalah dimulai dari endpoint "/papi/esearch/data/devops/dubboApi/debug/method". Endpoint ini pada dasarnya adalah generic invoker untuk Dubbo RPC, yang memungkinkan pemanggilan method secara dinamis hanya berdasarkan nama interface dan method. Secara internal, fitur ini sangat powerful untuk debugging atau troubleshooting. Tetapi ketika endpoint ini tidak dilindungi autentikasi dan tidak memiliki validasi input, ia berubah menjadi mekanisme eksekusi jarak jauh yang sepenuhnya dikontrol attacker.

Baca Juga Tentang: RCE (Remote Code Execution) - Study Kasus

Secara teknis, alur eksploitasinya cukup jelas. Request HTTP POST dengan payload JSON diterima oleh server, lalu langsung diteruskan ke layer Dubbo tanpa filtering berarti. Framework Dubbo kemudian melakukan resolusi interface menggunakan reflection, mencari method yang sesuai, dan mengeksekusinya dengan parameter yang diberikan. Di sinilah titik kritisnya: attacker bebas menentukan interfaceName dan methodName, sehingga bisa mengarahkan eksekusi ke helper internal yang memang dirancang untuk menjalankan perintah sistem. Pada implementasi tertentu, ini berujung pada pemanggilan Runtime.exec(), yang berarti perintah OS dijalankan langsung oleh server.

Baca Juga Tentang: Command Injection - KEV

Yang membuat vulnerability ini sangat berbahaya adalah sifatnya yang single-step exploitation. Tidak ada kebutuhan untuk bypass autentikasi, tidak perlu chaining dengan vulnerability lain, dan tidak membutuhkan kondisi khusus. Selama endpoint tersebut dapat diakses, attacker bisa langsung mengeksekusi command. Dalam praktiknya, eksploitasi bisa dimulai dari scanning massal terhadap endpoint ini, kemudian dilanjutkan dengan payload sederhana untuk mendapatkan shell. Misalnya, attacker cukup mengirim perintah untuk mengunduh dan menjalankan script dari server eksternal, lalu membuka reverse shell ke mesin mereka.

Dari sisi dampak, ini bukan hanya soal akses ke satu server. Weaver E-cology biasanya terintegrasi dengan berbagai komponen penting dalam organisasi database, sistem HR, workflow internal, hingga penyimpanan dokumen. Begitu attacker mendapatkan eksekusi command, mereka berada dalam posisi ideal untuk melakukan pivot ke sistem lain. Kredensial bisa diambil dari file konfigurasi, koneksi database bisa dieksploitasi, dan akses ke dokumen internal bisa dimanfaatkan untuk eksfiltrasi data sensitif.

Baca Juga Tentang: Pivot - Lateral Movement - Local Privilege

Dalam konteks yang lebih luas, vulnerability ini sangat relevan dengan pola supply chain attack dan identity compromise. Sistem seperti E-cology sering digunakan sebagai pusat operasional organisasi. Mengompromikannya berarti attacker tidak hanya mendapatkan akses data, tetapi juga kemampuan untuk memanipulasi proses bisnis misalnya menyisipkan dokumen berbahaya dalam workflow atau memodifikasi data internal tanpa terdeteksi. Ini adalah jenis akses yang sangat bernilai dalam skenario APT.

Hal yang menarik dari kasus ini adalah bahwa akar masalahnya bukan pada teknologi Dubbo itu sendiri, namun lebih pada cara penggunaannya. RPC framework seperti Dubbo memang dirancang untuk fleksibilitas tinggi, termasuk dynamic invocation. Namun fleksibilitas ini menjadi risiko ketika tidak dibatasi oleh kontrol keamanan yang ketat. Debug endpoint yang seharusnya hanya tersedia di lingkungan development justru terekspos ke internet, tanpa autentikasi dan tanpa pembatasan method. Ini menunjukkan adanya asumsi yang salah dalam desain: bahwa komponen internal tidak akan pernah diakses oleh pihak luar.

Mitigasi tentu dimulai dari patch resmi yang menghapus endpoint tersebut. Tetapi pendekatan defensif tidak boleh berhenti di sana. Sistem harus dipandang sebagai kumpulan attack surface, termasuk endpoint yang “tidak seharusnya digunakan publik”. Pembatasan akses melalui network segmentation, filtering pada reverse proxy, dan penerapan prinsip least privilege pada service account menjadi langkah penting. Selain itu, monitoring juga perlu difokuskan pada perilaku abnormal, seperti proses shell yang dipicu oleh aplikasi Java atau request mencurigakan ke endpoint RPC.

Vulnerability ini cukup jelas: setiap interface yang memberikan kemampuan eksekusi dinamis baik itu RPC, scripting engine, atau debug tool harus dianggap sebagai komponen berisiko tinggi. Ketika interface tersebut terekspos tanpa kontrol, ia tidak lagi sekadar fitur debugging, melainkan berubah menjadi execution primitive bagi attacker. Dan dalam lingkungan enterprise, satu primitive seperti ini sudah cukup untuk membuka jalan menuju kompromi total.

Benediktus Sava – Security Researcher

Sumber:

NIST

Vegaio

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