Pernahkah kamu merasa aneh? Scanner bilang sistem bersih, tapi log menunjukkan aktivitas mencurigakan. Ini tanda klasik: attacker sudah masuk via UTA0533 atau teknik serupa, tapi mereka sengaja memakai teknik lama yang dianggap “lusuh”.
Kenapa? Karena banyak tim deteksi hanya mengawasi IOC baru. Mereka lewatkan teknik seperti LDAP enumeration dengan perintah Windows standar, persistence lewat registry run key atau scheduled task biasa, serta lateral movement menggunakan SMB atau PsExec yang sudah ada di sistem.
Karena mereka tahu: IOC lama = kurang dipantau.
Kali ini kita akan bahas cara mendeteksi trik post‑exploit UTA0533 menggunakan YARA rule dan Sigma signature yang benar‑benar bisa dipakai di lapangan – bukan hanya copy‑paste dari GitHub.
—
### LDAP Enumeration: Bukan Hanya “net user”
Sudah dapat akses sebagai user domain (via password spraying atau kerberoasting), langkah selanjutnya attacker biasanya enumeration AD. Tapi mereka **tidak** pakai BloodHound yang langsung menyoroti diri. Alih‑alih, mereka menggunakan perintah native:
“`
dsquery user -limit 0
dsquery * -filter “(objectCategory=person)” -attr sAMAccountName
net user /domain
“`
Semua ini adalah perintah Windows biasa yang admin gunakan setiap hari, sehingga sulit terdeteksi jika hanya melihat command line saja.
Di sinilah deteksi berbasis perilaku diperlukan.
#### Sigma Rule untuk Deteksi Anomali Volume LDAP Query
“`yaml
title: Unusual LDAP Query Volume dari Workstation
id: 99999999-1111-2222-3333-444444444444
status: experimental
description: Mendeteksi jumlah LDAP query yang tidak normal dari satu host yang mungkin menunjukkan enumerasi AD
logsource:
product: windows
category: process_creation
detection:
selection:
Image:
– ‘*\\dsquery.exe'
– ‘*\\net1.exe'
– ‘*\\net.exe'
CommandLine|contains: ‘-filter'
condition: selection and (COUNT(*) by Computer, Image > 10 within 5m)
falsepositives:
– Admin script yang benar‑butuh mass enumerasi
level: high
“`
#### YARA Rule untuk Deteksi Script Enumerasi yang Disimpan
Kadang attacker menyimpan hasil enumerasi ke file untuk dianalisis offline. Inilah yang bisa kita tangkap:
“`yara
rule AD_Enumeration_Script_UTA0533 {
meta:
description = “Mendeteksi script enumerasi AD yang disimpan oleh attacker”
author = “Detection Engineering Team”
reference = “UTA0533 Post-Exploitation Techniques”
date = “2024-01-15”
threat_actor = “UTA0533”
strings:
$dsquery = “dsquery” nocase
$net_user = “net user” nocase
$domain = “/domain” nocase
$output_redirect = “>>” nocase
$temp_path = “%TEMP%” nocase
condition:
(all of ($dsquery, $net_user, $domain) and $output_redirect) or
(all of ($dsquery, $net_user) and $temp_path)
}
“`
—
### Persistence: Yang Tampak Biasa Tapi Tidak Harus Dianggap Biasa
Setelah enumeration, attacker perlu memastikan kembali masuk. Tapi mereka **tidak** menggunakan web shell atau backdoor kompleks. Mereka memakai teknik yang terlihat normal:
– Registry Run Key: `HKCU\Software\Microsoft\Windows\CurrentVersion\Run`
– Scheduled Task dengan nama netral: `OneDriveSyncTask`, `WindowsUpdateChecker`
– WMI Event Subscription yang terlihat seperti monitoring biasa
Di sini, timing dan konteks yang penting, bukan cuma artefaknya.
#### Sigma Rule untuk Deteksi Persistence Mencurigakan
“`yaml
title: Suspicious Scheduled Task Creation dari User Biasa
id: 88888888-7777-6666-5555-444433332222
status: test
description: Mendeteksi pembuatan scheduled task oleh non‑admin user di jam sibuk
logsource:
product: windows
service: security
detection:
selection:
EventID: 4698 # Task creation
TokenElevationType: TokenElevationTypeLimited # Bukan admin
NewProcessName:
– ‘*\\schtasks.exe'
– ‘*\\svchost.exe'
filter:
TaskName:
– ‘*OneDrive*'
– ‘*Update*'
– ‘*System*'
StartTime: '08:00-18:00′ # jam kerja normal
condition: selection and not filter
falsepositives:
– Pengguna yang benar‑benar membuat task pribadi untuk produktivitas
level: medium
“`
#### YARA untuk Deteksi Persistence lewat Registry
“`yara
rule Suspicious_RunKey_Persistence {
meta:
description = “Mendeteksi penambahan nilai di Run key yang mencurigakan”
reference = “MITRE T1547.001”
strings:
$run_key = “HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run” nocase
$suspicious_paths = /\%TEMP%\\[a-zA-Z0-9]{8,}\.(exe|dll|bat|cmd|ps1)/ nocase
$random_name = /[a-zA-Z0-9]{10,}_[0-9]{4}\.(exe|dll)/ nocase
condition:
$run_key at 0 and (
any of ($suspicious_paths) or
any of ($random_name)
)
}
“`
—
### Lateral Movement: Menggunakan Alat yang Sudah Ada di Sistem
Ini bagian paling jahat: mereka **tidak** membawa alat eksternal. Semua yang diperlukan sudah ada di sistem Windows korban.
Teknik yang dipakai:
– **SMB** untuk menyalin file ke admin share (`\\TARGET\ADMIN$\\`)
– **PsExec** (jika ada) atau **WMIC** untuk eksekusi remote
– **PowerShell Remoting** atau **DCOM** untuk teknik yang lebih stealth
Yang membuat ini sulit terdeteksi adalah karena ini adalah **administrative tools yang sah**.
#### Sigma Rule untuk Deteksi Lateral Movement Mencurigakan
“`yaml
title: Potential Lateral Movement via Admin Share Access
id: 77777777-6666-5555-4444-333322221111
status: test
description: Mendeteksi akses ke admin share yang mungkin menunjukkan movimentasi lateral
logsource:
product: windows
service: sysmon
detection:
selection:
EventID: 11 # FileCreate (Sysmon)
TargetFilename:
– ‘*\\ADMIN$\\*'
– ‘*\\C$\\*'
– ‘*\\IPC$*'
Image:
– ‘*\\explorer.exe'
– ‘*\\svchost.exe'
– ‘*\\services.exe'
condition: selection
falsepositives:
– Operasi normal sistem yang mengakses admin share
level: high
“`
#### YARA untuk Deteksi Payload yang Disembunyikan di File Normal
Attacker bisa menyisipkan kode malicious ke dalam file yang terlihat biasa:
“`yara
rule Suspicious_Payload_In_Legitimate_File {
meta:
description = “Mendeteksi shellcode atau payload yang disisipkan ke file sistem”
reference = “MITRE T1027.003”
strings:
$shellcode1 = { FC E8 82 00 00 00 60 89 E5 31 C0 64 8B 50 30 }
$shellcode2 = { 60 8B FC 8B 45 3C 8B 54 05 78 03 E5 56 8B 5A 20 }
$powershell_enc = /-[Ee][Nn][Cc][Oo][Dd][Ee]\\s+[A-Za-z0-9+\/]{100,}/
condition:
uint16(0) == 0x5A4D and # MZ header
(any of ($shellcode*) or $powershell_enc)
}
“`
—
### Korelasi: Kunci Deteksi yang Efektif
Banyak tim gagal karena hanya fokus pada **satu** sinal. Deteksi yang baik membutuhkan **korelasi** antara beberapa tindakan.
#### Contoh Scenario Serangan UTA0533:
1. **T+0**: Akses awal lewat phishing exploit
2. **T+2 jam**: LDAP enumeration dari workstation terinfeksi
3. **T+4 jam**: Pembuatan scheduled task di user profile
4. **T+6 jam**: Akses ke admin share SMB dari host yang sama
5. **T+8 jam**: Eksekusi payload lewat PsExec atau WMI
Jika kita hanya melihat satu tindakan, bisa jadi false positive. Tapi jika kita melihat **urutan ini dalam waktu singkat dari satu host**, itu indikasi kuat compromise.
#### Contoh Korelasi Sederhana di SIEM (Pseudocode):
“`
WHEN (
LDAP query count > 10 dari same host dalam 5menit
AND
Scheduled task dibuat oleh non‑admin user di host yang sama
AND
SMB access ke admin$ share dari host yang sama
) WITHIN 15 MENIT
THEN: GENERATE HIGH SEVERITY ALERT – POTENTIAL UTA0533 POST‑EXPLOIT
“`
—
### FAQ yang Sering Ditanya
**Q: Apakah YARA rule ini bisa langsung dipakai di produksi?**
A: Tidak langsung. Selalu uji dulu di mode monitor selama beberapa hari untuk menilai false positive rate di lingkunganmu sebelum mengaktifkan alert.
**Q: Apa perbedaan utama antara YARA dan Sigma dalam deteksi ini?**
A: YARA bekerja pada level file/memory (mencari pola byte), sedang Sigma bekerja pada level log/event (mencari pola kejadian di sistem/log). Keduanya salengkap.
**Q: Seberapa sering saya harus memperbarui rule ini?**
A: Review tiap bulan atau ketika ada perubahan besar di infrastruktur (misalnya upgrade Windows, perubahan policy Group Policy). Tambahkan pengecualian untuk skrip internal yang benar‑benar perlu melakukan enumerasi.
—
### Kesimpulan: Deteksi Tidak Perlu Kompleks, Tapi Harus Tepat
UTA0533 dan aktor serupa tidak selalu pakai zero‑day atau malware canggih. Mereka sering:
– Menggunakan **living‑off‑the‑land binaries (LOLBAS)**
– Mengandalkan **ketidaksadaran manusia** (admin yang tidak monitoring dengan baik)
– Bekerja dalam **jam kerja normal** untuk tidak mencurigakan
Kunci deteksi bukanlah memiliki alat termahal atau signature terbaru, tetapi:
1. **Memahami normal** di lingkunganmu
2. **Mencari anomali** dalam konteks bisnis
3. **Mengkorelasikan** event yang seolah‑olah tidak berhubungan
Mulai kecil. Fokus pada satu teknik dulu (misalnya: LDAP enumeration). Bangun dari sana.
Deteksi yang baik bukan tentang menemukan semua ancaman. Ini tentang menemukan yang **benar‑benar penting** sebelum mereka mengacau bisnismu.
—
### CTA: Mulai Deteksi yang Lebih Cerdas Hari Ini
Jika kamu siap untuk mulai membangun detection engineering yang benar‑benar efektif, mulai dengan satu teknik dari di atas. Uji di lingkungan lab masing‑masing, lalu rollout ke produksi.
Jangan lupa berbagi temuanmu di komunitas security – karena pertahanan yang baik adalah kerja sama.
**Selamat berburu ancaman!**
