SHub Reaper: Brand Spoofing Chain, applescript:// Bypass, dan Wallet Backdoor di macOS - Ethical Hacking Indonesia

SHub Reaper infostealer variant ini merubah cara penyamarannya di setiap stage infection chain: payload di-host di typo-squatted Microsoft domain, dieksekusi dengan membuatnya seolah Apple security update, lalu persist dari direktori palsu Google Software Update. Tiga brand berbeda, satu execution chain. Ini merupakan teknik atau desain sserangan yang dibuat dengan alasan menghindari fitur keamanan atau asumsi keamanan pada target. 

Sebelum ada payload di drop ke target, ada recon layer di sisi web. Halaman delivery mengumpulkan informasi sistem, WebGL data, indikator VPN, browser extension yang terpasang, dan tanda-tanda virtual machine atau security research tool. Script-nya juga mencari password manager 1Password, Bitwarden, LastPass dan cryptocurrency wallet extension seperti MetaMask dan Phantom. Teknik ini sudah sangat umum dilakukan oleh penyerang di masa modern karena menghindari deteksi dini sebelum merancang titi serang yang tepat.

Operator ingin tahu profil target sebelum commit mengirimkan payload yang identifiable. Kalau WebGL menunjukkan VM signature, atau ada extension analysis tool, halaman bisa ganti konten beberapa halaman mengganti konten mereka dengan pesan "Access Denied" dalam bahasa Rusia setelah mendeteksi upaya analisis. Ada juga geofencing, salah satu pengecekan pertama loader adalah melihat apakah keyboard dengan bahasa Rusia terpasang di macOS. Jika ditemukan, malware mengirim event cis_blocked ke server attacker dan keluar tanpa melakukan apapun. Ini adalah pola umum di malware untuk hindari infeksi di wilayah CIS untuk meminimalkan risiko dari penegak hukum setempat.

Initial Access: ClickFix ke applescript:// Pivot

Versi SHub sebelumnya mengarahkan korban untuk paste command ke Terminal. Reaper menggeser proses itu ke Script Editor melalui URL scheme applescript://. Pergeseran ini membantu bypass beberapa proteksi yang Apple tambahkan di macOS Tahoe 26.4 untuk Terminal-based attack chain. Ini poin teknis yang penting. Terminal sudah lebih sering dijadikan target deteksi EDR tools mulai memantau process Terminal, spawned process dari bash, dan outbound connection dari context Terminal. 

Script Editor adalah attack surface yang lebih jarang dimonitor, dan applescript:// URL scheme adalah cara legitimate untuk membuka script di Script Editor secara programatik. Attacker tidak memanfaatkan bug baru mereka menggunakan legitimate API macOS untuk masuk melalui jalur yang lebih sedikit dipantau. Setelah korban klik "Run" di Script Editor, malware menampilkan Apple XProtectRemediator security update sementara command tersembunyi dieksekusi di background. Tahap selanjutnya meminta password macOS dari pengguna dan mengambil credential tersebut selama eksekusi. Korban kemudian melihat fake compatibility error yang dirancang untuk mengurangi kecurigaan, dan mengalihkan perhatian.

Password login itu berharga karena membuka macOS Keychain sistem penyimpanan terenkripsi Apple untuk password, Wi-Fi credential, app token, dan private key. Tanpa login password, database Keychain hanya data terenkripsi, tetapi dengan password tersebut, kontennya bisa didekripsi dan dibaca. 

Collection: Scope Harvesting dan Chromium Wallet Profiling

Setelah eksekusi berhasil dan password diperoleh, collection phase berjalan secara sistematis. SHub menyasar 14 browser berbasis Chromium Chrome, Brave, Edge, Opera, OperaGX, Vivaldi, Arc, Sidekick, Orion, Coccoc, Chrome Canary, Chrome Dev, Chrome Beta, dan Chromium mencuri saved password, cookie, dan autofill data dari setiap profil yang ditemukan. Firefox mendapat perlakuan yang sama untuk credential yang tersimpan. SHub memiliki tabel besar extension ID wallet, dan yang lebih signifikan, setiap wallet diasosiasikan dengan tiga flag per-wallet yang mengontrol apa yang dikumpulkan. Ini jauh lebih advanced dibanding pendekatan "copy extension folder" flat yang digunakan MacSync, dan mengimplikasikan bahwa penulisnya sudah mem-profile bagaimana extension wallet berbeda mempersist secrets dan state mereka.

Di luar wallet dan browser, SHub juga mengambil direktori macOS Keychain, data akun iCloud, Safari cookie dan browsing data, database Apple Notes, dan session file Telegram informasi yang bisa memungkinkan attacker untuk membajak akun tanpa mengetahui password. SHub juga menyalin shell history file (.zsh_history dan .bash_history) dan .gitconfig, yang sering berisi API key atau authentication token yang digunakan developer. 

Untuk exfiltration, file yang dikumpulkan di-stage di /tmp/shub_<random>/, lalu script mengecek apakah direktori melebihi 85MB. Jika iya, Reaper membuat Bash script di /tmp/shub_split.sh untuk membagi archive menjadi chunk ZIP 70MB dan mengupload-nya secara sekuensial ke C2 di hebsbsbzjsjshduxbs[.]xyz/gate/chunk via curl. Chunked upload bukan hanya soal ukuran file upload besar satu kali lebih mudah di-flag oleh DLP atau network monitoring dibanding serangkaian transfer sedang yang terlihat seperti backup traffic biasa, karena dengan mengirim jumlah file berukuran kecil membuat susah untuk di deteksi. 

Wallet Backdoor: Persistence di Level Aplikasi

Di sinilah SHub secara signifikan melampaui kebanyakan macOS infostealer, mayoritas stealer adalah smash-and-grab: eksekusi sekali, ambil semua, selesai. SHub juga melakukan itu, tapi kemudian melangkah lebih jauh. Jika menemukan wallet Electron-based tertentu terinstall, malware diam-diam mengganti file app.asar core logic aplikasi dengan versi yang dimodifikasi dari C2, mematikan process aktif, menimpa file asli, membersihkan signature, dan menandatangani ulang app bundle agar macOS menerima modifikasi tersebut.

Detail implementasi per wallet cukup spesifik: build Exodus dan Atomic Wallet yang dimodifikasi mengeksfiltrasi password dan seed phrase ke wallets-gate[.]io/api/injection setiap kali wallet dibuka; versi backdoored Ledger Wallet dan Ledger Live mematikan TLS check dan menampilkan fake recovery wizard yang mencuri seed phrase; Trezor Suite variants menampilkan fake "critical update" overlay, menangkap phrase tersebut, dan menonaktifkan update untuk mempertahankan build berbahaya.Untuk bypass Gatekeeper, script membersihkan quarantine attribute dengan xattr -cr dan menggunakan ad hoc code signing pada modified application bundle.

Ini adalah persistence yang tidak bergantung pada LaunchAgent atau cron job persistence-nya ada di dalam aplikasi yang korban jalankan sendiri secara rutin. Setiap kali korban membuka wallet, credential keluar. Dan karena app bundle sudah re-signed dengan ad hoc signature, macOS tidak complaint kecuali ada explicit trust pinning ke certificate aslinya.

Persistence dan C2 Backdoor

Sebelum terminasi, AppleScript membuat struktur direktori yang meniru Google Software Update: ~/Library/Application Support/Google/GoogleUpdate.app/Contents/MacOS/. Sebuah bash script bernama GoogleUpdate yang di-decode dari Base64 ditempatkan di direktori ini dan didaftarkan menggunakan LaunchAgent property list bernama com.google.keystone.agent.plist.

Pemilihan namespace ini tidak random. com.google.keystone adalah nama yang sangat dikenal ini adalah Keystone updater milik Google yang ter-install di hampir semua macOS machine yang pernah punya Chrome. Kalau kamu scroll manual melalui ~/Library/LaunchAgents/ tanpa tahu pasti apa yang kamu cari, entry ini tidak terlihat sebagai program yang di rancang dengan fungsi yang bisa merugikan pengguna.

LaunchAgent menjalankan script GoogleUpdate setiap 60 detik. Script ini berfungsi sebagai beacon, mengirim detail sistem ke endpoint /api/bot/heartbeat di C2. Jika server mengembalikan payload "code", script mendekodenya, menulis ke file tersembunyi /tmp/.c.sh, mengeksekusinya dengan privilege user saat ini, lalu menghapus file tersebut.

Pola write-execute-delete di /tmp adalah cara klasik untuk menjalankan arbitrary command tanpa meninggalkan file executable permanen yang bisa di-scan. File .c.sh hanya ada selama eksekusi, dan karena di /tmp yang tidak persistent, bahkan restart pun tidak akan meninggalkan artefak.

Pentester: applescript:// sebagai delivery vector adalah sesuatu yang worth dimasukkan ke dalam macOS social engineering playbook. Terminal-based ClickFix sudah mulai dikenal dan di-flag oleh EDR tools yang lebih baru script Editor via URL scheme adalah pivot yang lebih quiet. Testing endpoint protection terhadap AppleScript execution dari context non-Terminal penting untuk memvalidasi coverage. 

Developer: .gitconfig dan shell history masuk dalam target collection SHub. API key yang pernah di-paste ke terminal atau disimpan di gitconfig adalah exposed. Rotasi credential setelah incident, dan audit file-file tersebut di mesin development yang diduga ter-compromise, harus masuk ke incident response checklist macOS. 

Detection engineer: Ada beberapa sinyal behavioral yang worth dimonitor: unexpected AppleScript atau osascript activity, suspicious outbound traffic setelah Script Editor execution, atau pembuatan LaunchAgent atau file terkait di namespace yang berasosiasi dengan trusted vendor. Secara spesifik, com.google.keystone.agent.plist yang tidak diinstall oleh Chrome atau Google software itu sendiri adalah anomaly yang jelas. Di sisi network, chunked POST ke domain random dengan path /gate/chunk dari context curl yang dijalankan oleh script adalah sinyal yang bisa di-correlate dengan data exfiltration.

Baca Juga Tentang: CryptoStealer Malware Openclaw ClickFix Extention Backdoor

Benediktus Sava – Security Researcher

Sumber: SentinelOne Appleinsider Malwarebytes

MiniPlasma: Regression di cldflt.sys yang Mengembalikan CVE-2020-17103 Menjadi SYSTEM LPE Modern - Ethical Hacking Indonesia

MiniPlasma bukan bug baru tetapi bug yang sudah pernah dilaporkan bertahun-tahun lalu melalui CVE-2020-17103 oleh James Forshaw. Yang berubah sekarang adalah konteks exploitability dari bug tersebut. PoC lama yang sebelumnya dianggap sudah tidak bekerja atau sudah fixed ternyata kembali valid pada Windows modern karena perubahan internal di jalur execution cldflt.sys membuat mitigasi lama hilang efeknya. Bukan bypass patch, windows. PoC lama kembali bisa mempengaruhi kinerja sistem karena root cause awal tidak di tangani dengan baik.

Target utamanya ada di cldflt.sys, Cloud Files Mini Filter Driver milik Windows. Driver ini berada di stack file system filter dan dipakai untuk placeholder file handling pada OneDrive dan Cloud Files API. Begitu placeholder access diproses, cldflt.sys ikut mengatur state object, hydration logic, dan policy enforcement terhadap file yang sebenarnya belum sepenuhnya tersimpan di disk. 

State Internal yang Bermasalah

Masalah utama di sini bukan memory corruption yangg biasa kita temukan pada LPE seperti pada Linux. Tidak ada heap spray besar, tidak ada UAF allocator-heavy seperti win32k era lama. Primitive awalnya lebih dekat ke race-condition logic flaw di sekitar validasi object state. 

HsmOsBlockPlaceholderAccess melakukan pemeriksaan terhadap akses placeholder file dalam kondisi tertentu. Jalur ini bergantung pada state transient object yang berubah cepat ketika file operation, policy update, dan namespace handling berjalan paralel. 

Yang penting di sini: validasi dilakukan terhadap state yang tidak stabil. PoC lama dari Project Zero memanfaatkan timing antara perubahan object/policy state dan jalur access enforcement. Secara teknis Microsoft sepertinya dulu tidak menghilangkan primitive race tersebut. Mereka hanya membuat PoC original gagal secara praktis melalui perubahan perilaku tertentu di Windows 10 akhir 2020.

cldflt.sys digunakan buat LPE karena berada langsung di jalur operasi file biasa Windows. User biasa bisa trigger code path-nya cuma lewat akses file placeholder OneDrive atau Cloud Files. Masalah mulai muncul karena state object placeholder bisa berubah di tengah operation. Contohnya: thread pertama check apakah placeholder boleh diakses, thread lain hydrate file, metadata placeholder berubah, operation pertama lanjut pakai hasil check lama.

Baca Juga Tentang: MDASH Ghost-Lock Defender

Benediktus Sava – Security Researcher

Sumber: Nightmare-eclipse Chromium Microsoft

Grafana GitHub Breach: Dari Credential Leak ke Pencurian Source Code Internal - Ethical Hacking Indonesia

Di banyak environment modern, GitHub menjadi control plane untuk hampir seluruh software lifecycle. Secrets, CI/CD, deployment workflow, infrastructure-as-code, signing pipeline, internal package registry, sampai automation token biasanya ikut terhubung ke sana. Begitu actor memperoleh token dengan scope yang salah, mereka tidak cuma membaca source code. Aktor mulai melihat struktur organisasi engineering secara presisi.

Baca Juga Tentang: Github Action Abuse

Grafana sendiri menyebut attacker memperoleh token yang memberikan akses ke GitHub environment mereka dan memungkinkan download codebase internal. Mereka juga mengatakan forensic analysis berhasil mengidentifikasi sumber kebocoran credential dan token tersebut sudah di-invalidasi.

Incident ini kemungkinan besar bukan exploit langsung terhadap GitHub ataupun Grafana infrastructure. Jalurnya lebih dekat ke credential compromise. Bisa melalui infostealer, leaked token pada workstation developer, CI artifact exposure, shell history, local git credential helper, atau third-party integration yang menyimpan PAT/token secara tidak aman.

Baca Juga Tentang: InfoStealer Malware

Attacker tampaknya tidak perlu mempertahankan persistence panjang di environment. Begitu token valid diperoleh, Git clone saja sudah cukup untuk monetisasi atau menekan pihak Grafana. Itu kasus paling umum yang makin sering muncul pada kelompok data-extortion modern. Mereka tidak selalu mengejar domain admin, ransomware deployment, atau destructive access. Kadang objective utamanya hanya mendapatkan dataset bernilai tinggi dengan friction rendah dan dwell time pendek.

Pada environment engineering modern, source code sendiri adalah target bernilai tinggi. Masalahnya bukan sekadar intellectual property. Codebase internal biasanya berisi:

• architecture map implisit,
• internal hostname,
• deployment topology,
• hardcoded secret yang terlupakan,
• API contract,
• feature flag,
• auth flow,
• debugging endpoint,
• legacy service path,
• build script,
• trust relationship antar sistem.

Bahkan ketika secrets sudah dipisahkan ke vault, code repository tetap memberi attacker visibility besar terhadap attack surface internal. Itu sebabnya akses read-only kadang cukup berbahaya. Di banyak incident GitHub-centric, escalation sebenarnya tidak berasal dari permission awal, tetapi dari secondary discovery setelah repository berhasil diakses. Misalnya:

• CI workflow ternyata menggunakan reusable token dengan scope lebih luas,
• pipeline artifact mengandung credential,
• GitHub Actions log menyimpan environment variable,
• internal package registry memakai static token,
• atau deployment script memiliki fallback credential.

State machine serangannya sederhana tetapi efektif. Credential leak - repository access - internal discovery - secret harvesting - lateral movement. Pada tahap awal, actor bahkan belum perlu menjalankan payload apa pun.

Kalau melihat claim yang beredar, grup yang dikaitkan dengan insiden ini adalah CoinbaseCartel. Attribution semacam ini memang selalu perlu hati-hati karena leak-site actor sering mengklaim korban opportunistically. Tetapi profil operasi mereka cukup cocok dengan pola incident semacam ini.

Mereka masuk kategori data-theft extortion, bukan ransomware tradisional. Artinya objective utama bukan encrypting infrastructure, tetapi memperoleh data yang cukup sensitif untuk dijadikan pressure material. Model seperti ini jauh lebih murah secara operasional dibanding ransomware deployment penuh. Tidak perlu bypass EDR secara agresif, tidak perlu persistence kompleks, tidak perlu encryption orchestration lintas domain. Begitu data berhasil diambil, pressure cycle langsung dimulai.

Baca Juga Tentang: ShinyHunters 

Kelompok seperti ini juga sering memanfaatkan credential yang sebenarnya sudah bocor jauh sebelumnya melalui infostealer ecosystem. Itu bagian yang sering diremehkan developer. Banyak compromise GitHub tidak dimulai dari exploit enterprise infrastructure, tetapi dari browser session, token lokal, atau credential sinkronisasi developer workstation. Satu developer machine yang terinfeksi infostealer beberapa bulan sebelumnya bisa menjadi initial access untuk incident skala perusahaan hari ini.

Terutama karena GitHub PAT dan session token sering hidup cukup lama. Yang cukup penting dari kasus Grafana adalah statement mereka bahwa tidak ada indikasi customer system terdampak. Akses repository tidak otomatis berarti akses production environment. Banyak organisasi memang memisahkan control boundary antara source platform dan runtime infrastructure. Tetapi separation seperti ini hanya aman kalau benar-benar enforced secara ketat. 

Detection engineer biasanya akan melihat beberapa area berikut setelah incident semacam ini:

• anomalous git clone volume,
• access dari ASN atau geography tidak biasa,
• token usage di luar developer pattern normal,
• API enumeration terhadap repository,
• mass archive download,
• workflow inspection,
• GitHub audit log anomalies,
• access terhadap private release artifact.

Bagi pentester, kasus seperti ini mengingatkan bahwa GitHub sekarang sering menjadi entry point reconnaissance paling bernilai dalam enterprise modern. Bukan cuma karena source code. Tetapi karena repository menjadi titik konvergensi atau menjadi titik awal dari tahap mapping ke tahap aksi:

• developer identity,
• automation,
• deployment,
• package management,
• infrastructure definition,
• dan operational secrets.

Begitu actor memahami graph relasi internal dari repository, attack surface perusahaan biasanya mulai terbuka dengan sendirinya. Ada detail lain yang cukup penting bahwa Grafana menyebut attacker mencoba melakukan blackmail agar codebase tidak dipublikasikan. Itu mengindikasikan actor menganggap monetisasi utama berasal dari sensitivitas source code itu sendiri, bukan dari encryption atau operational disruption. Artinya mereka percaya repository tersebut memiliki nilai strategis:

• proprietary logic,
• security-sensitive implementation,
• mungkin juga embedded secret atau deployment reference,
• atau minimal reputational leverage terhadap perusahaan.

Developer sering menganggap source code leak hanya masalah intellectual property. Dalam praktik incident response, efek jangka panjangnya lebih luas. Ketika attacker memiliki visibility penuh terhadap code path internal, mereka bisa:

• mencari auth bypass lebih efisien,
• memahami hidden feature,
• memetakan trust boundary,
• mempersingkat exploit development,
• atau menemukan service yang sebelumnya tidak terekspos publik.

Mitigasi untuk kasus seperti ini sebenarnya bukan sekadar rotate token setelah incident terjadi. Masalah utamanya ada pada lifecycle credential modern yang terlalu long-lived dan terlalu trusted. Beberapa area yang biasanya perlu dibenahi setelah incident seperti ini:

• short-lived GitHub token,
• strict repository scoping,
• hardware-backed MFA untuk developer,
• token binding,
• secret scanning pada commit dan CI log,
• isolated build runner,
• workstation hardening terhadap infostealer,
• dan audit terhadap GitHub Actions permission inheritance.

Yang sering terlambat disadari adalah GitHub organization sekarang praktis setara dengan privileged infrastructure. Kalau attacker memperoleh akses yang cukup dalam ke sana, mereka tidak lagi sekadar membaca code. Mereka mulai membaca cara perusahaan beroperasi secara keseluruhan.

Benediktus Sava – Security Researcher

Sumber: Grafana-X Ransomeware-Live Fortiguard Halcyon Grafana-Com

CVE-2026-42897: XSS di Microsoft Exchange OWA yang Berujung Session Hijacking dan Spoofing Internal - Ethical Hacking Indonesia

CVE-2026-42897 bukan tipe bug Exchange yang menarik karena kompleksitas memory corruption atau RPC parser. Posisi yang cukup terbatas: reflected atau stored XSS di jalur rendering Outlook on the web (OWA). Tetapi konteks tempat JavaScript itu berjalan membuat impact-nya jauh lebih besar dibanding XSS biasa pada aplikasi web generik.

Masalah utamanya ada pada posisi OWA sendiri. Browser korban sudah membawa session Exchange yang valid, token autentikasi aktif, akses mailbox internal, endpoint ECP/EWS yang reachable dari origin yang sama, dan sering kali berada di lingkungan enterprise dengan trust boundary yang longgar antar komponen Microsoft stack.

Begitu JavaScript attacker berhasil dieksekusi di origin OWA, attacker tidak lagi beroperasi sebagai external user. Tetapi berada di dalam konteks authenticated Exchange session milik korban.

Entry Point: Email sebagai Carrier Payload

Attacker mengirim specially crafted email ke target atau email phising yang berisikan payload ke yang sudah di rancang sedemikian rupa, payload kemudian diproses oleh pipeline rendering OWA ketika email dibuka dari browser. Di titik ini ada dua area yang biasanya relevan pada arsitektur Exchange: sanitization layer saat MIME/HTML email diproses, rendering layer OWA frontend. 

Baca Juga Tentang: Mail Attack

Masalah seperti ini umumnya muncul bukan karena HTML mentah langsung lolos namun karena  transformasi antar representasi data tidak konsisten. 

Contoh tipikalnya:

• sanitizer memvalidasi node sebelum canonicalization selesai
• encoding berubah setelah filtering
• atribut dianggap inert tetapi kemudian menjadi executable setelah DOM reconstruction
• HTML email diproses berbeda antara preview pane dan full open mode
• parser backend dan parser browser menghasilkan DOM akhir yang berbeda

Exchange historically punya attack surface yang cukup besar di area ini karena OWA harus menangani email HTML kompleks dari berbagai mail client, legacy MIME structure, inline attachment, calendar object, embedded image, sampai format Outlook proprietary, semua itu memperbesar kemungkinan adanya parser differential.

Baca Juga Tentang: MIME Type

Kenapa XSS di OWA Lebih Berbahaya

CVSS vulnerability ini masuk kategori spoofing, tetapi dari perspektif attacker, primitive yang paling menarik justru session execution di browser internal. Begitu payload berjalan, attacker memperoleh kemampuan untuk melakukan request sebagai user korban ke endpoint Exchange yang berada dalam same-origin policy yang sama.

Itu membuka beberapa jalur:

• akses mailbox via OWA endpoint
• abuse ECP functionality
• enumerasi internal object
• pembacaan email
• pengiriman email internal
• modifikasi rule mailbox
• token theft
• forced action terhadap administrator yang sedang login

Jika target browser ternyata memiliki hak akses atau admin dan helpdesk maka impak yang di hasilkan lebih besar juga karena mempermudah penyerang dalam melakukan movement di browser dan sistem yang di targetkan. OWA sendiri historically bukan frontend ringan sehingga banyak state management berjalan di client side dan browser mempertahankan cukup banyak informasi session. JavaScript arbitrary di origin itu bisa mengakses berbagai artefak yang biasanya tidak terlihat oleh attacker external.

Baca Juga Tentang: Browser Credential Harvesting

Bahkan tanpa cookie exfiltration pun attacker masih bisa melakukan authenticated action langsung melalui XMLHttpRequest atau fetch API karena browser korban sendiri yang mengirim credential. Jadi primitive awalnya sebenarnya bukan “execute arbitrary code” terhadap server Exchange secara langsung. Yang terjadi justru berpotensi: authenticated browser execution, session riding, dan trusted-origin action abuse. Tetapi pada environment enterprise, itu sering menjadi pivot menuju compromise yang lebih besar.

Mitigasi Yang Perlu Untuk dilakukan

Pada environment air-gapped atau server yang tidak dapat mengambil mitigasi otomatis, Microsoft menyediakan Exchange On-Premises Mitigation Tool (EOMT). Secara praktis, tool ini menerapkan konfigurasi mitigasi langsung ke Exchange melalui Exchange Management Shell. Untuk single server, mitigasi dijalankan menggunakan: .\EOMT.ps1 -CVE "CVE-2026-42897" Sedangkan untuk seluruh Exchange server non-Edge dalam organisasi: Get-ExchangeServer | Where-Object { $_.ServerRole -ne "Edge" } | .\EOMT.ps1 -CVE "CVE-2026-42897"

Hubungan dengan Inline Image dan Calendar Rendering

Efek samping mitigasi Microsoft memberi petunjuk cukup jelas mengenai area code path yang disentuh mitigasi. Beberapa fungsi yang rusak setelah mitigasi: inline image rendering, print calendar, dan OWA light mode. Karena ketiganya berkaitan dengan HTML generation dan rendering pipeline lama di OWA.

Artinya mitigasi kemungkinan besar tidak memperbaiki root parser issue secara penuh, tetapi memblok atau men-disable jalur rendering tertentu yang dianggap berisiko. 

Kenapa EEMS Diprioritaskan

Microsoft mendorong penggunaan Exchange Emergency Mitigation Service (EEMS) sebelum patch tersedia penuh. EEMS memungkinkan Microsoft mendorong mitigasi behavioral lebih cepat tanpa menunggu cumulative update penuh. Biasanya model mitigasi seperti ini bekerja dengan: IIS rewrite rule, URL blocking, configuration hardening, component disablement, request filtering bukan memperbaiki parser fundamental. 

Karena itu side effect pada feature rendering menjadi cukup besar. Ada detail lain yang cukup penting: server yang belum update sejak Maret 2023 bahkan tidak bisa menerima mitigasi baru otomatis. Itu berarti sebagian deployment Exchange on-prem kemungkinan sudah terlalu jauh tertinggal dari baseline mitigation framework Microsoft sendiri. Dari perspektif attacker, environment seperti ini: patch cadence kurang di manage, Exchange exposed ke internet dependency legacy tinggi, monitoring modern minim.

Exploit Chain yang Bisa Terjadi

Exploit chain yang berpotensi untuk vulnerability seperti ini biasanya tidak berhenti di mailbox user biasa. Target bernilai tinggi adalah: administrator Exchange, helpdesk, finance, executive assistant, dan shared mailbox operator. 

Begitu attacker mendapatkan eksekusi JavaScript di browser mereka, beberapa jalur post-exploitation terbuka: Mailbox Rule Abuse Attacker membuat forwarding rule tersembunyi atau rule auto-delete untuk persistence ringan, Internal Phishing Karena email dikirim dari account legitimate internal, trust rate jauh lebih tinggi dibanding external spoofing, Credential Relay terhadap Portal Internal Browser korban sering memiliki akses ke aplikasi enterprise lain dengan SSO aktif, ECP Interaction Pada kasus tertentu, endpoint administrasi Exchange dapat diakses dari origin yang sama atau session yang sama. dan jika kondisi terrsebut terpenuhi maka posisi ini bisa memberikan foothold kepada penyerang atau attacker. 

Benediktus Sava – Security Researcher

Sumber: Microsoft Microsoft-Mitigation Helpnetsecurity

Analisa Claw Chain: Eksploitasi Sandbox dan Runtime OpenClaw - Ethical Hacking Indonesia

OpenClaw pada dasarnya dibangun dengan asumsi bahwa agent tetap dapat diberi akses shell, filesystem, scheduler, dan integrasi SaaS selama seluruh operasi itu dibungkus oleh sandbox OpenShell. Masalahnya bukan karena sandbox sama sekali tidak bekerja, tetapi karena boundary yang dipakai ternyata hanya boundary logis berbasis validasi path dan validasi command sebelum runtime benar-benar mengeksekusinya.

Di Claw Chain, empat vulnerability berbeda saling melengkapi sampai akhirnya agent yang awalnya hanya memiliki akses terbatas di dalam sandbox dapat berubah menjadi entitas yang mengontrol runtime host secara persisten.

Entry point paling realistis sebenarnya tidak terlalu kompleks. Attacker cukup memperoleh eksekusi di dalam konteks agent, misalnya melalui plugin berbahaya, workflow automation, atau prompt injection yang berhasil memaksa agent menjalankan command tertentu. Setelah berada di dalam sandbox, attack surface OpenShell mulai terbuka.

CVE-2026-44112 dan CVE-2026-44113 berasal dari problem yang sama: OpenShell memvalidasi path filesystem sebelum operasi read atau write dilakukan, tetapi object filesystem yang dipakai saat validasi bukan object yang benar-benar digunakan ketika syscall final dieksekusi.

validate(path)

...

open(path)

Validation dilakukan terhadap canonical path yang masih dianggap aman dan masih berada di bawah mount root sandbox. Tetapi setelah validation selesai, masih ada gap kecil sebelum file benar-benar dibuka atau ditulis. Di interval itu attacker dapat mengganti target path menggunakan symlink atau manipulasi filesystem lain sehingga operasi final diarahkan ke lokasi di luar sandbox.

Pada CVE-2026-44113 primitive yang dihasilkan adalah arbitrary read. Ini terlihat sederhana sampai melihat bagaimana agent AI biasanya menyimpan state internal. Runtime OpenClaw memegang environment variable, token SaaS, connector credential, session artifact, dan berbagai konfigurasi yang memang dirancang agar dapat diakses agent secara otomatis. Begitu sandbox read boundary dilewati atau aturan logis bisa di lewati, attacker tidak hanya memperoleh file lokal biasa tetapi juga identitas digital yang dipakai agent untuk berinteraksi dengan sistem lain.

Yang membuat primitive ini kuat bukan volume file yang dapat dibaca, tetapi kualitas data yang berada di dalam runtime agent. Banyak deployment agent modern menyimpan token Slack, Discord, Telegram, API LLM, bahkan cloud credential langsung di environment variable atau konfigurasi lokal karena agent memang harus dapat melakukan orchestration lintas layanan tanpa intervensi manusia.

Bug ini berasal dari mismatch antara validator command dengan perilaku shell ketika runtime expansion terjadi. OpenClaw mencoba menerapkan allowlist command, tetapi validasi dilakukan sebelum shell memproses expansion dan substitution.

cat <<EOF

$API_TOKEN

EOF

Validator melihat command yang tampak aman karena secara literal tidak ada command berbahaya. Tetapi ketika shell mulai memproses heredoc, variable expansion tetap berjalan dan isi environment variable diekspose ke output command.

Masalah seperti ini sering muncul ketika developer memperlakukan shell parser sebagai parser satu tahap. Padahal shell memiliki lifecycle parsing bertingkat: lexical parsing, expansion, substitution, baru execution. Filtering yang hanya bekerja di tahap awal tidak benar-benar mengontrol semantic akhir command yang dieksekusi shell.

Baca Juga Tentang: OpenClaw - ClawJacked

Di OpenClaw, primitive disclosure dari heredoc ini sangat cocok dipasangkan dengan filesystem read escape sebelumnya. Satu vulnerability memberi akses ke file sensitif, yang lain memberi akses langsung ke environment runtime. Kombinasinya cukup untuk menguras hampir seluruh identitas yang dipakai agent.

Setelah token dan credential mulai terkumpul, chain bergerak ke CVE-2026-44118.

Kerentanan ini berada di mekanisme MCP loopback internal. OpenClaw memiliki komunikasi antar komponen runtime yang menggunakan flag seperti "senderIsOwner" untuk menentukan apakah suatu proses memiliki privilege tingkat owner.

Masalah utamanya bukan sekadar missing authorization biasa, tetapi trust boundary yang runtuh di jalur IPC lokal. Runtime mempercayai flag ownership yang dikirim client tanpa benar-benar mengikatnya kembali ke authenticated session yang valid. Secara praktis proses lokal dapat mengatakan: "senderIsOwner = true" dan runtime menerimanya sebagai identitas legitimate.

Di banyak sistem tradisional asumsi seperti ini sering muncul karena komunikasi loopback dianggap internal dan aman. Tetapi pada platform agent AI, attacker memang sudah diposisikan di dalam runtime sejak foothold awal berhasil diperoleh. Jadi seluruh komponen “internal only” otomatis berubah menjadi attack surface.

Begitu owner privilege diperoleh, attacker mulai dapat mengontrol scheduler, gateway configuration, execution environment, dan policy runtime. Pada titik ini sandbox praktis sudah kehilangan fungsi pembatasannya karena orchestrator yang mengelola sandbox sendiri sudah berada di bawah kontrol attacker. Tahap terakhir chain kembali menggunakan CVE-2026-44112, kali ini bukan untuk sekadar write escape tetapi untuk persistence.

Lingkungan agent AI, persistence tidak harus berbentuk malware tradisional atau service binary tambahan. Menulis ke konfigurasi scheduler, plugin manifest, startup workflow, atau execution policy sudah cukup untuk mempertahankan kontrol jangka panjang terhadap agent.

Karena seluruh aktivitas berjalan melalui proses agent legitimate, banyak telemetry keamanan terlihat normal. Process execution berasal dari binary resmi OpenClaw. Network activity berasal dari konektor yang memang biasa dipakai agent. Bahkan command execution sering tampak identik dengan workflow otomatis sehari-hari.

Ini yang membuat Claw Chain cukup berbeda dibanding kompromi aplikasi biasa. Agent AI modern pada dasarnya sudah memiliki akses luas sejak awal. Mereka memegang secret organisasi, memiliki kemampuan automation, dan dipercaya untuk menjalankan task lintas sistem. Ketika boundary internal seperti sandbox dan ownership validation gagal, attacker tidak perlu lagi membangun privilege dari nol. Sebagian besar privilege itu sebenarnya sudah tersedia di dalam runtime agent.

Dari sisi developer, problem terbesar yang terlihat di sini adalah penggunaan validasi berbasis representasi string untuk object yang sebenarnya mutable. Path filesystem bisa berubah setelah validation. Shell command bisa berubah semantic setelah expansion. Identity flag bisa dipalsukan ketika runtime hanya mempercayai metadata dari client.

Semua vulnerability di chain ini berasal dari asumsi bahwa state yang sudah divalidasi akan tetap identik sampai tahap execution berikutnya. Pada runtime yang asynchronous dan heavily automated seperti OpenClaw, asumsi seperti itu sangat rapuh.

Mitigasi paling penting tentu patch seluruh instance OpenClaw ke versi setelah 23 April 2026, tetapi langkah itu sendiri tidak cukup. Operator perlu menganggap seluruh credential yang pernah disentuh runtime agent sudah terekspos dan melakukan rotasi secret secara penuh. Infrastruktur agent juga sebaiknya diperlakukan seperti privileged automation environment, bukan sekadar aplikasi chatbot biasa.

Claw Chain pada akhirnya bukan cuma masalah race condition atau shell expansion. Rantai ini memperlihatkan bagaimana agent AI mulai menjadi execution layer utama di infrastruktur perusahaan, sementara banyak boundary internalnya masih dibangun menggunakan asumsi keamanan aplikasi konvensional.

Baca Juga tentang AI: Microsoft Ollama

Benediktus Sava – Security Researcher

Sumber:

Cyera  Cryptika Paloaltonetwork

Fragnesia (CVE-2026-46300): Kerentanan Page Cache Coruption Pada Linux via XFRM ESP-in-TCP - Ethical Hacking Indonesia

CVE-2026-46300 jalur ESP-in-TCP pada subsistem XFRM Linux kernel. Secara praktek bug ini bukan  memory corruption biasa, karena primitive yang didapat attacker langsung menyentuh page cache file-backed. Masalah utamanya bukan berasal dari parser paket yang gagal validasi atau overflow linear klasik. Root cause-nya lebih ke transisi state internal socket buffer setelah patch DirtyFrag sebelumnya mengubah asumsi ownership terhadap page fragment, karena bug ini memiliki kaitan dengan bug atau celah sebelumnya yang yaitu Dirty Frag. Begitu ownership model bergeser, jalur decrypt XFRM mulai bekerja terhadap memori yang sebenarnya masih mereferensikan page cache file asli.

Jalur Masuk: Namespace dan CAP_NET_ADMIN Palsu

Penyerang tidak punya CAP_NET_ADMIN di host utama, tetapi Linux tetap memberikan capability tersebut di namespace baru. Itu cukup untuk: membuat konfigurasi XFRM/IPsec, mengatur ESP-in-TCP, memasang key material melalui NETLINK_XFRM, dan mengontrol lifecycle socket yang dibutuhkan exploit. Kondisi tersebut membuat kondisi supaya kernel memperlakukan buffer tertentu sebagai traffic ESP valid. 

Aktivitas namespace + konfigurasi XFRM oleh proses non-network-facing userland sebetulnya sudah cukup aneh. Terutama bila host bukan appliance VPN atau node tunnel IPsec. Karena penyerang justru bisa menggunakan fitur isolasi ini untuk mendapatkan hak CAP_NET_ADMIN. 

Meskipun hak ini hanya berlaku di dalam kotak namespace tersebut, bug Fragnesia memungkinkan hak tersebut bocor dan memengaruhi Page Cache milik host utama. Ini adalah anomali besar di mana proses yang seharusnya terisolasi bisa memanipulasi memori global sistem. NETLINK_XFRM adalah saluran komunikasi khusus antara proses di userland dan kernel untuk mengatur aturan IPsec. Aktivitas tersebut tidak mungkin dilakukan oleh kondisi normal sistem karena bukan tidak memiliki fungsi dalam sistem.

Bagaimana Page Cache Bisa Masuk ke Receive Queue

Bagian penting exploit ada di penggunaan splice(), normalnya fungsional sistem receive queue TCP diisi skb yang berasal dari jaringan. Di bug ini justru memasukkan data dari file-backed page ke queue socket, sehingga membuat kernel menyimpan fragment yang masih terhubung ke page cache file asli. Ini penting karena sebagian besar mitigasi memory corruption modern bergantung pada pemisahan ownership memori: network buffer dianggap transient, page cache dianggap persistent, crypto transform diasumsikan bekerja pada buffer private. 

Fragnesia mematahkan asumsi tersebut, patch DirtyFrag sebelumnya ternyata mengubah alur tertentu sehingga fragment hasil splice tidak lagi diperlakukan secara defensif saat state socket berubah menjadi ESP-in-TCP, akibatnya fragment file-backed tersebut ikut melewati jalur decrypt. 

Root Cause: State Transition Socket yang Salah Asumsi

Masalah sebenarnya muncul ketika ESP-in-TCP diaktifkan setelah queue sudah terisi fragment splice, karena kernel menganggap data yang ada di receive queue merupakan payload ESP terenkripsi yang aman untuk diproses in-place padahal buffer tersebut bukan hasil receive jaringan biasa dan masih memegang referensi ke page cache file asli. Di jalur internal XFRM, decrypt dilakukan langsung terhadap fragment tanpa memastikan backing memory aman dimodifikasi. 

Di jalur internal XFRM, decrypt dilakukan langsung terhadap fragment tanpa memastikan backing memory aman dimodifikasi. Flow konseptual: file page cache - splice() - TCP receive queue - ESP-in-TCP enabled - XFRM decrypt path - in-place XOR transform - page cache corruption. Masalahnya adalah decrypt path memang dirancang untuk melakukan modifikasi buffer langsung agar supaya proses efisiensi, pada jalur normal itu valid karena skb payload mutable. Begitu fragment berasal dari page cache, model mutability berubah total, dan bug ini terjadi karena networking subsystem, page cache, dan crypto transform (boundary).

Primitive Utama: Controlled XOR ke File-Backed Memory

Primitive exploit Fragnesia cukup clean karena ESP decryption pada dasarnya menghasilkan plaintext = ciphertext XOR keystream. Karena proses exploit bekerja dengan mengontrol: ciphertext key, material XFRM, dan timing aktivasi ESP yang bisa memprediksi hasil akhir XOR pada fragment page cache. Jadi ini bukan arbitrary write penuh seperti memcpy bebas offset. Lebih ke deterministic bit manipulation terhadap cached executable content. Executable ELF sangat sensitif terhadap beberapa byte awal: entry stub, branch instruction, credential check, dan loader path. 

Perubahan kecil bisa mengubah flow eksekusi total, Dalam demonstrasi, target yang dipakai adalah /usr/bin/su. penggunaan file tersebut karena, executable tersebut hampir selalu tersedia, dijalankan setuid root, dan mudah dipicu ulang setelah page cache berubah. Disk file asli tetap utuh, coruption hanya terjadi pada representasi cached di memori kernel. Karena Linux lebih memilih page cache dibanding reload disk langsung, proses baru akan mengeksekusi versi yang sudah dimodifikasi exploit.

Kenapa Primitive Kecil Ini Cukup untuk Root

Fragnesia menargetkan executable privileged, attacker tidak perlu ROP kompleks atau pivot heap besar. Mereka cuma perlu: memodifikasi beberapa instruction, mem-bypass auth branch atau mengganti flow menuju shell spawn sederhana. Begitu binary setuid dieksekusi ulang, privilege escalation terjadi secara natural lewat mekanisme UNIX normal. 

Yang membuatnya menarik adalah exploit chain ini hampir tidak menyentuh userspace memory corruption tradisional. Tidak ada: stack smash, heap feng shui besar, dan use-after-free klasik. Eksploitasi murni bermain di: page ownership, skb fragment lifecycle, dan crypto transform semantics. 

Kenapa Patch DirtyFrag Melahirkan Bug Baru

Fragnesia cukup relevan buat developer kernel karena memperlihatkan pola umum patch regression pada subsistem kompleks. DirtyFrag sebelumnya mencoba memperbaiki corruption flow tertentu dengan mengubah handling fragment dan reference semantics. Tetapi perubahan kecil pada ownership expectation ternyata membuka jalur baru ketika: socket state berubah dinamis, fragment sudah berada di queue, dan subsystem lain mengasumsikan buffer mutable ini tipe bug yang sulit terlihat lewat audit lokal. Karena secara teknis splice logic tampak, XFRM decrypt, skb handling tampak valid.

Masalah baru muncul ketika seluruh lifecycle digabung, itulah sebabnya fuzzing subsystem tunggal sering tidak cukup untuk bug seperti ini.

Langkah Mitigasi

Kalau host tidak membutuhkan IPsec ESP:  printf 'install esp4 /bin/false\ninstall esp6 /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf rmmod esp4 esp6 2>/dev/null. Pendekatan ini efektif karena memotong jalur exploit sebelum XFRM ESP aktif. Kalau IPsec wajib dipakai, pembatasan user namespace lebih relevan: echo "user.max_user_namespaces=0" > /etc/sysctl.d/dirtyfrag.conf sysctl --system. 

Ini tidak memperbaiki bug inti, tetapi memutus kemampuan attacker memperoleh CAP_NET_ADMIN terisolasi. Untuk environment containerized, mitigasi ini perlu dihitung hati-hati karena banyak runtime modern bergantung pada user namespaces dan patch kernel terbaru tetap jadi solusi utama karena root cause ada pada transisi ownership fragment di jalur XFRM.

Baca Juga Tentang: CopyFail DirtyFrag

Benediktus Sava – Security Researcher

Sumber:

RedHat Wiz Canonical CloudLinux

MDASH AI Security Microsoft Menemukan UAF di Kernel Windows - Ethical Hacking Indonesia

Selama bertahun-tahun, static analysis di kernel Windows selalu mentok di titik yang sama: local reasoning. Scanner bisa melihat sinkronisasi yang hilang dalam satu fungsi, bisa melihat dereference setelah free secara linear, tapi mulai gagal ketika lifecycle object tersebar lintas callback, lintas subsystem, atau bahkan lintas file yang ownership-nya implisit.

MDASH mencoba menyelesaikan masalah itu bukan dengan model lebih pintar, tetapi dengan memecah proses audit menjadi sistem reasoning bertingkat.Yang menarik bukan sekadar penggunaan LLM. Banyak vendor sudah melakukan itu. Yang berubah di sini adalah bentuk orchestration-nya.

Microsoft membangun harness yang memperlakukan vulnerability research seperti proses engineering internal: ada auditor, ada debater, ada prover, lalu semuanya bekerja di atas plugin domain-specific yang memahami aturan kernel sebenarnya.

Masalah Utama Scanner Tradisional

Mayoritas scanner gagal pada bug modern karena state corruption sekarang jarang bersifat lokal. Race-condition kernel modern hampir selalu melibatkan: reference counting, deferred cleanup, asynchronous completion, ownership ambiguity, allocator reuse di CPU berbeda, dan kondisi state machine protocol yang tidak linear.

Pada CVE-2026-33827 di tcpip.sys, masalahnya bukan hanya pointer dipakai setelah free tetapi bug muncul karena lifecycle object path routing berubah saat opsi IPv4 SSRR diproses dalam jalur penerimaan paket. Objek kehilangan reference lebih awal, lalu execution flow lain masih menganggap object tersebut valid. Di sistem SMP, window race menjadi cukup besar karena allocator kernel bisa langsung mendaur ulang chunk yang baru dibebaskan sebelum traversal berikutnya selesai menggunakan pointer lama.

Scanner biasa cenderung gagal karena: free terjadi di file berbeda, dereference terjadi di callback, berbeda timing corruption, bergantung scheduler ownership, dan object tidak eksplisit di AST lokal. Dengan MDASH masalah ini bisa di pecahkan menjadi reasoning graph lintas state, bukan sekadar pattern matching syntax seperti pada teknik tradisional atau konvesional. 

Prepare Stage

Tahap prepare terdengar sederhana di dokumentasi Microsoft, tetapi sebenarnya ini fondasi penting. Mereka tidak hanya membangun symbol index namun membangun konteks eksploitasi melalui record atau dokumentasi sebelumnya. Riwayat commit digunakan untuk memetakan area kode yang historically fragile: parser jaringan, lock-heavy subsystem, IRP dispatch chain, allocator-sensitive path, legacy compatibility layer. Ini penting karena bug kernel modern sering muncul di area yang sudah lama mengalami patch churn. Semakin sering suatu subsystem disentuh untuk compatibility atau hardening, semakin tinggi probabilitas invariant internal mulai beribah ke arah yang bisa memicu kerentanan atau bug.

Untuk ethical hacker, hal ini menarik karena secara praktis meniru workflow manusia saat triage target besar: cari subsystem yang historically noisy,  ownership ambiguity, asynchronous cleanup, dan transisi state yang tidak lengkap. MDASH hanya mengotomatisasi proses itu dalam skala besar. 

Auditor dan Debater: Kenapa False Positive Bisa Turun

Static analyzer biasanya menghasilkan noise besar karena semua path dianggap reachable sampai dibuktikan sebaliknya, MDASH memiliki kemampuan untuk menguji hasil dari static analyzer dengan cara agent auditor melakukan dugaan atau hipotesis dan di debat oleh agent debater dengan tujuan untuk mematahkan asumsi atau membuktikan asumsi tersebut yang di hasilkan oleh debater, dan sekara teknis ini merupakan teknik merubah disagreement menjadi signal yang diperhitungkan oleh agent. Jika auditor tetap bertahan setelah proses adversarial internal, confidence score naik. Secara praktis, ini mirip proses code review antar exploit developer. Sistem yang terlalu agresif menghasilkan ribuan laporan tidak berguna. Dalam environment kernel production, noise seperti itu lebih berguna daripada missed bug kecil.

CVE-2026-33827: Race-Condition UAF di tcpip.sys

Temuan CVE dari MDASH ini menunjukan bahwa SSRR sendiri bukan jalur kode yang sering diuji sehingga langsung meningkatkan probabilitas invariant lama tertinggal, sebab MDASH perlu melihat histori dari dokumentasi yang di berikan. Berikut merupakan flow teknis dari CVE ini:

1. Paket IPv4 dengan opsi routing diproses 

2. Path object dibuat/referenced

3. Kondisi tertentu memicu pelepasan reference lebih awal

4. Traversal networking lain masih menyimpan pointer lama

5. CPU lain melakukan allocator reuse

6. Stale pointer dipakai ulang dalam jalur navigasi paket

Yang membuat ini berbahaya bukan UAF tetapi reuse karena dalam kernel networking, reuse allocator sering terjadi sangat cepat karena traffic packet processing bersifat bursty dan highly parallel. Akibatnya attacker tidak selalu perlu kontrol presisi penuh terhadap heap layout. Kadang cukup menciptakan pressure allocator yang membuat object lama tertimpa struktur baru dengan shape yang kompatibel sebagian.

Cross-File Reasoning pada ikeext.dll

CVE-2026-33824 lebih menarik dari sisi ownership semantics, masalah yang terjadi adalah shallow copy melalui memcpy Ketika struktur internal IKEv2 disalin tanpa menduplikasi pointernya, ownership berubah ambigu: subsystem A merasa memiliki buffer, subsystem B merasa hasil copy adalah ownership baru, cleanup berjalan independen, dan allocator menerima dua free untuk chunk sama. Yang penting justru hubungan implicit antar state, di sinilah model reasoning lintas file menjadi relevan. Banyak exploit modern muncul bukan karena fungsi berbahaya tunggal, tetapi karena dua subsystem berbeda memiliki asumsi ownership yang bertentangan. 

Prove Stage

Prove stage ini menjadi bagian yang sangat berbeda dari tools AI lain karena MDASH mencoba membangun trigger aktual. dengan kondisi bahwa sistem harus melakukan tahap memahami constraint parser, memahami format input valid, memahami jalur reachability, dan memahami bagaimana sanitizer mendeteksi corruption. Secara praktek ini sudah mendekati automated exploit triage. 

Bahkan kegagalan yang disebut Microsoft cukup revealing atau memberikan output yang di mana AI menghasilkan format input untuk libFuzzer, padahal harness target menggunakan honggfuzz. Kondisi tersebut memperlihatkan adanya pergeseran pandangan dari cara tools digunakan untuk mencari bug yang sebelumnya tunggal kini mulai menggunakan konteks operasional saat mencari kerentanan. 

Plugin Domain-Specific

Bagian paling penting dari MDASH bukan model frontier saja tetapi plugin internal yang digunakan, kernel Windows penuh aturan implisit: siapa yang boleh free IRP, kapan spinlock harus dilepas ,APC state apa yang valid, object mana yang reference-counted, callback mana yang berjalan di DISPATCH_LEVEL. Ini juga menjelaskan kenapa MDASH bisa mencapai recall tinggi pada tcpip.sys dan clfs.sys. Mereka menginputkan pengetahuan invariant internal langsung ke reasoning pipeline. 

Ini juga memperlihatkan kepada kita bahwa suatu saat yang hebat atau yang jago itu bukan lagi yang paham cara reverse engineering manual tapi yang memiliki pemahaman tentang plugin yang data tersebut bisa di berikan kepada AI tentang sistem yang di targetkan. 

Limitasi MDASH

82% failure di benchmark berasal dari task description yang ambigu yang diuji oleh CyberGym artinya sistem masih membutuhkan anchor awal. Jika target benar-benar undocumented, reasoning graph kemungkinan mulai mengalami ambigu karena model kehilangan arah eksplorasi dan ini menjadi tantangan AI dalam konteks cyber security kepedan karena, dalam cyber security yang hands-on memiliki noise yang sangat singgi sekali sedangkan AI memerlukan data clear untuk membangun konteks yang tepat. 

Dampak terhadap Ethical Hacking

MDASH mengubah cara pekerjaan vulnerability research, Bug sederhana kemungkinan akan habis lebih dulu oleh sistem internal vendor. Jadi bug yang memiliki potensi tersihsah untuk publik bisa memiliki kompleksitas yang sangat tinggi seperti semantic corruption, state desynchronization, logic race, protocol confusion, trust-boundary mismatch. Artinya practical value seorang researcher mulai bergeser ke: memahami invariant internal, membangun plugin reasoning, memahami allocator behavior, memahami lifecycle asynchronous, dan pada akhirnya mengajari AI tentang subsystem tertentu. 

Dalam beberapa tahun ke depan, kemungkinan besar competitive edge bukan lagi siapa punya model terbesar, tetapi siapa punya harness paling matang untuk menghubungkan: LLM, sanitizer, symbolic execution, protocol mutator, historical patch intelligence, ownership reasoning, exploit triage.

MDASH menjadi realisasi terhadap kemampuan AI Model untuk memasuki area cyber security yang kemudian akan terus berkembang kedepan, kondisi ini tidak secara otomatis membuat manusia tergantikan. Karena sangat diperlukan pertanggung jawaban terhadap sebuah tindakan yang dibuat dalam konteks keamanan apalagi di tingkat korporasi akuntabilitas dan pertanggung jawab sangat di perlukan. Pola kedepan yang sangat mungkin terjadi yaitu AI vs AI, kemudian manusia sangat perlu memahami hal-hal mendasar tentang sistem agar memahami apa yang dikerjakan oleh AI itu sendiri. 

Pada realitasnya AI bisa mencari kerentanan tetapi yang memahami sistem keseluruhan apalagi pada tingkat infrastruktu perusahaan adalah manusia, karena sistem yang besar dan kompleks itu perlu sekali fleksibilitas yang tinggi dalam menanganinnya, contoh yang bisa kita ambil bahwa ketika terjadi gangguan pada sistem sebuah perusahaan pada waktu tertentu akan sangat berbeda dengan gangguan pada waktu yang bisa di pahami AI ini juga memberikan gap antara AI yang kaku karena memerlukan pola dan kepastian dokumentasi dengan manusia yang sangat flesibel dan mampu memahami logic secara keseluruhan dalam kondisi tertentu. Jadi AI itu sanagt cepat tetapi potensi buta ketika tidak ada arah itu sangat tinggi dan ini bisa menimbulkan bahaya, sedangkan manusia itu cendrung lambat namun memahami dan perkerjaan bisa di delegasikan kepada siapaun.

Benediktus Sava – Security Researcher

Baca Juga tentang:

GhostLock - Internal Windows

False Positive - Windows Behaviour

Sumber:

Microsoft GeeekWire

PamDOORa: Backdoor PAM Linux dan Jalur Persistensi di Layer Autentikasi - Ethical hacking Indonesia

Sebagian besar implant Linux bermain di layer proses, LD_PRELOAD, service systemd, atau hooking SSH daemon secara langsung. PamDOORa mengambil jalur yang lebih rendah: masuk ke stack PAM dan membiarkan seluruh aplikasi autentikasi memanggil backdoor tersebut secara legitim. Itu mengubah karakter ancamannya secara signifikan, Begitu modul PAM termuat ke dalam alur autentikasi, targetnya bukan lagi SSH saja. 

Yang sebenarnya diambil alih adalah mekanisme validasi identitas sistem. SSH, sudo, console login, hingga beberapa service enterprise berbasis PAM semuanya melewati stack yang sama. Di sini menariknya bukan sekadar persistensi, tetapi posisi eksekusi. PamDOORa berjalan sebelum aplikasi benar-benar menyelesaikan proses autentikasi mereka sendiri.

Kenapa PAM Menjadi Target yang Sangat Efisien PAM pada Linux pada dasarnya adalah dispatcher autentikasi modular. Aplikasi seperti sshd tidak selalu memvalidasi password secara mandiri. Mereka menyerahkan proses itu ke stack PAM melalui call seperti: pam_authenticate() pam_acct_mgmt() pam_open_session(). Urutan modul ditentukan melalui file di: /etc/pam.d/ common-auth system-auth PamDOORa memanfaatkan sifat chaining ini.

Bukan dengan mengganti pam_unix.so, implant menambahkan modul baru seperti pam_linux.so lalu menyisipkannya menggunakan flag sufficient. berikut adalah flow dari modul pam: sshd - pamStack - (pam_linuxso - (impalnt) - pamunix.so - modul normal yang lain)

Karena menggunakan sufficient, modul berbahaya bisa menghentikan chain lebih awal ketika kondisi tertentu terpenuhi. Artinya autentikasi valid tidak perlu pernah mencapai pam_unix.so. Banyak implementasi backdoor lama melakukan patch langsung ke OpenSSH atau libc. Problemnya, perubahan seperti itu relatif mudah ditemukan melalui:

• package verification
• checksum mismatch
• RPM/DPKG integrity
• EDR process telemetry

PamDOORa menghindari area tersebut dan memilih layer middleware autentikasi yang lebih jarang dipantau secara ketat. PamDOOR sulit di lacak atau ditemukan karena network-awareness. yaitu modul yang melakukan pengecekan password dan juga melakukan inspeksi metadata koneksi melalui /proc/[pid]/fd.

Baca Juga Tentang: Linux Internals Shell

Terdapat routine seperti procFindConnectionSocket yang kemungkinan melakukan traversal file descriptor untuk mencari socket aktif milik proses autentikasi, dengan tujuan validasi source connection validasi port TCP tertentu validasi jenis socket/protocol. kemudian adanya implikasi bahwa scanner otomatis atau analyst yang mencoba brute-force trigger password tidak akan pernah melihat perilaku abnormal jika koneksi tidak memenuhi kondisi socket tersebut. backdoor pam ini berada pada jalur berbeda dari scanner biasa, cara ini lebih senyap ketimbang harus implant SSH tradisional yang meninggalkan conditional branch jelas di flow autentikasi utama.

pam juga memiliki akses kredensial cleartext sebelum lifecycle atau siklus autentikasi selesai. Begitu user memasukkan password ke SSH, PAM menerima credential sebelum: hashing internal, session setup, logging aplikasi, beberapa kontrol audit jadi pam membuka jalur baru. jadi secara teknis ini merupakan intersepsi, yang membedakan pam dari keylogging. Jadi implant tinggal mengambil parameter autentikasi lalu meneruskannya kembali agar login terlihat normal. Berikut Flow dari Pam:

User login - sshd menerima credential - pam_authenticate() - pam_linux.so membaca  username/password - credential disimpan - flow diteruskan ke modul asli. 

Dari sudut pandang admin dan juga user biasa, tidak ada anomali yang berbeda dari logic sistem yang ada. Karena password diambil sebelum logging aplikasi, banyak solusi detection berbasis SSH telemetry kehilangan visibility ketika kondisi seperti ini terjadi. 

Data-data yang di ambil kemudian di simpan di dir yang minim pengawasan /temp menggunakan XOR runtime key. Untuk menghindari deteksi pam membuat nama dan timestamp yang dinamis agar supaya noise bercampur atau tidak terlihat tidak nomal pada sistem. Di server enterprise, /tmp sering penuh file sementara dari: package manager, container runtime, service daemon cache aplikasi, sehingga Credential dump kecil dengan nama pseudo-random sulit terdeteksi di dir /temp. 

Baca Juga Tentang: Malware Obfuscation

Pam manipulasi wtmp, utmp, btmp, dan lastlog File-file tersebut adalah database biner yang dipakai utilitas seperti: last, who, w, lastb. Jika implant memodifikasi record langsung di level struktur, maka tool forensik standar akan tetap menampilkan output yang terlihat konsisten. Sebagian besar investigasi awal Linux masih sangat bergantung pada timeline login. Jika timeline tersebut sudah dikorupsi sejak awal, maka: kapan akses pertama terjadi, akun mana yang dipakai, IP mana yang terlibat, kapan privilege escalation dilakukan, sehingga memicu inkonsistensi integritas data yang ditemukan oleh forensik. 

Implat yang dipakai oleh backdoor pam juga menggunakan PAM_IGNORE, Dalam beberapa implementasi PAM, return code seperti PAM_IGNORE memungkinkan modul keluar tanpa memicu failure handling tertentu. Efeknya: noise logging lebih kecil minim autentikasi gagal mencurigakan chain PAM tetap terlihat normal. 

Sebagian besar EDR Linux masih sangat process-centric, yang kuat mendeteksi: process injection, privilege escalation aneh, syscall abnormal malware userland, sedangkan Pam berada di jalur yang memang dipercaya atau trusted way sebagai tempat normalnya sebuah sistem berjalan. Proses sepeerti sshd memanggil PAM kemudian PAM membuat .so lalu kredensial di proses merupakan prilaku normal pada sistem. Akibatnya visibility detection menjadi sulit atau abu-abu kecuali defender memiliki: File Integrity Monitoring, baseline hash modul PAM, audit perubahan /etc/pam.d/, audit loading shared object, remote immutable logging. kalau tidak  implant bisa bertahan lama tanpa menyentuh indikator noisy seperti persistence service atau reverse shell konvensional.

Baca Juga Tentang: Kredensial Attack SSH

Bagi developer dan sysadmin, indikator paling penting justru bukan network IOC saja, Yang lebih relevan: perubahan urutan modul PAM, munculnya .so asing, penggunaan flag sufficient yang tidak biasa, perubahan timestamp pada /etc/pam.d/, shared object baru di path security module. dan juga penting untuk melakukanaudit terhadap path /usr/lib64/security/, /lib/security/, /etc/pam.d/. 

Baca Juga Tentang: Persistence Linux

Untuk detection engineer, masalah utamanya adalah local log tidak lagi bisa dipercaya penuh setelah implant aktif. Jika wtmp dan btmp dapat dimanipulasi, maka autentikasi harus dikorelasikan dengan: NetFlow, firewall log, bastion telemetry, SIEM eksternal, auditd remote forwarding, MFA juga membantu, tetapi konteksnya perlu tepat. Karena implant berada sebelum validasi selesai, password tetap bocor walaupun MFA aktif. MFA hanya membatasi reuse credential secara langsung. Kalau attacker sudah mendapatkan: SSH private key, session hijack, sudo token akses, internal tambahan maka password hanyalah salah satu bagian kompromi.

PamDOOR memiliki design yang berfokus pada: persistensi jangka panjang, stealth operasional, anti-forensik, kontrol akses berbasis kondisi jaringan. Linux server sekarang menyimpan: workload cloud,  container orchestration, secret management, CI/CD pipeline, credential infrastructure, jadi kalau terjadi serangan maka Attacker tidak lagi perlu menarget endpoint desktop secara eksklusif tetapi menguasai satu node Linux dengan implant autentikasi seperti ini memberi akses yang lebih strategis dibanding kompromi workstation biasa.

Melalui PamDOOR ini adanya fragmentasi identitas di berbagai komunitas bawah tanah, di mana tim peneliti Flare mengidentifikasi setidaknya lima persona berbeda yang beroperasi dengan tingkat keahlian yang kontras. Sosok paling menonjol ditemukan di forum Rehub (berbahasa Rusia), yang menjual PamDOORa dan dinilai memiliki kredibilitas teknis tinggi karena penguasaan mendalam pada internal Linux, berbeda jauh dengan persona di forum seperti SpyHackerz yang berfokus pada RAT tingkat menengah, atau di NulledBB yang lebih condong ke arah penipuan dan jual beli data bocor.

Benediktus Sava – Security Researcher

Sumber:

Cyberark

Flare