#12 Evil-WinRM Cheat Sheet: Windows Remote Management Security, Detection dan Hardening

WinRM sering mendapat reputasi yang agak dramatis di dunia offensive security. Begitu port 5985 atau 5986 terlihat, orang langsung teringat remote shell dan Evil-WinRM. Padahal Windows Remote Management (WinRM) sendiri bukan vulnerability. Ia adalah mekanisme administrasi resmi Windows yang sangat berguna—dan justru karena berguna, aksesnya perlu dikelola dengan serius.

Artikel #12 dalam Red Team Cheat Sheet Series membahas WinRM dan Evil-WinRM dari dua sisi sekaligus: bagaimana security assessor memahami exposure remote management, dan bagaimana Blue Team memastikan jalur administrasi tersebut tidak berubah menjadi jalan tol menuju server penting.

Semua contoh di artikel ini ditujukan untuk lab, sistem milik sendiri, atau environment yang secara eksplisit termasuk scope security assessment. Credential dan host contoh bersifat fiktif.

Kenapa WinRM Penting?

Administrator membutuhkan cara mengelola Windows Server tanpa selalu membuka Remote Desktop. Di sinilah WinRM dan PowerShell Remoting sangat berguna.

Secara sederhana:

Administrator
     |
     | WinRM / WS-Management
     v
Windows Server
     |
     +--> PowerShell Remoting
     +--> Management Tasks
     +--> Automation

Masalahnya bukan pada kemampuan remote management tersebut. Masalah muncul ketika organisasi memiliki kombinasi seperti:

WinRM dapat dijangkau dari terlalu banyak network segment;
administrative credential digunakan dari workstation biasa;
local administrator password digunakan ulang;
logging PowerShell dan WinRM minim;
privileged account dapat login dari endpoint yang tidak semestinya;
firewall rule terlalu longgar;
HTTPS tidak digunakan ketika arsitektur membutuhkannya.

Satu konfigurasi mungkin tidak langsung menjadi insiden. Tetapi ketika digabungkan dengan credential exposure dari artikel #07 atau attack path dari #06 BloodHound, ceritanya bisa berubah cepat.

WinRM Bukan Evil-WinRM

Ini perlu diluruskan sejak awal.

WinRM adalah implementasi Microsoft untuk WS-Management dan merupakan komponen Windows.

PowerShell Remoting dapat menggunakan WinRM sebagai transport untuk menjalankan sesi administrasi jarak jauh.

Evil-WinRM adalah client pihak ketiga yang populer di kalangan security professional untuk berinteraksi dengan endpoint WinRM dalam assessment.

Jadi menemukan WinRM aktif bukan berarti menemukan Evil-WinRM, apalagi otomatis menemukan vulnerability.

Analoginya: SSH aktif pada Linux bukan berarti server sedang diserang menggunakan SSH client tertentu.

Port 5985 dan 5986

Dua port yang sering diasosiasikan dengan WinRM adalah:

5985/tcp  WinRM HTTP
5986/tcp  WinRM HTTPS

Tetapi port terbuka hanya menjawab satu pertanyaan:

"Apakah service dapat dijangkau dari posisi network saya?"

Ia belum menjawab:

siapa yang boleh authenticate;
metode authentication apa yang digunakan;
apakah account tersebut privileged;
apakah firewall membatasi source;
apakah session tercatat;
apakah endpoint memang perlu dikelola dari segment tersebut.

Karena itu reconnaissance harus diikuti context validation.

Lab yang Aman

Untuk memahami WinRM, kita dapat menggunakan lab sederhana:

ADMIN-WS01   10.10.20.10
WIN-SRV01    10.10.20.20
DC-LAB01     10.10.20.5

ADMIN-WS01 menjadi administrative workstation. WIN-SRV01 adalah member server. DC-LAB01 menyediakan Active Directory lab.

Pisahkan network lab dari production. Gunakan account khusus lab dan snapshot VM sebelum mengubah konfigurasi.

Tujuan lab bukan membuat sebanyak mungkin remote shell. Tujuannya memahami trust boundary: siapa boleh mengelola siapa, dari mana, menggunakan identity apa, dan telemetry apa yang tertinggal.

Tahap 1 — Temukan Exposure WinRM

Dalam assessment yang diotorisasi, discovery dapat dimulai dengan Nmap terhadap host yang sudah masuk scope:

nmap -p 5985,5986 10.10.20.20

Contoh hasil:

PORT     STATE SERVICE
5985/tcp open  wsman
5986/tcp closed wsmans

Jangan langsung menyimpulkan "WinRM insecure".

Catat dulu:

Host        : WIN-SRV01
Source      : assessment VLAN
5985/tcp    : reachable
5986/tcp    : not reachable

Lalu tanyakan: apakah assessment VLAN memang seharusnya dapat mencapai management interface server tersebut?

Pertanyaan itu sering lebih bernilai daripada sekadar nama service.

Tahap 2 — Audit dari Sisi Windows

Pada host yang kita administrasikan, konfigurasi WinRM dapat diperiksa dengan tool bawaan Windows.

winrm enumerate winrm/config/listener

Periksa konfigurasi service:

winrm get winrm/config/service

Dan konfigurasi client:

winrm get winrm/config/client

Tujuan audit bukan mencari satu nilai ajaib bernama secure=true. Kita ingin memahami keseluruhan konfigurasi:

listener apa yang aktif;
interface mana yang menerima koneksi;
authentication mechanism;
firewall scope;
TrustedHosts jika digunakan;
penggunaan HTTPS;
siapa yang memiliki hak remote management.

Tahap 3 — Validasi dengan Tool Native Dulu

Dalam Windows lab, kita dapat memvalidasi apakah endpoint WinRM merespons:

Test-WSMan WIN-SRV01

Untuk environment domain yang memang mengizinkan PowerShell Remoting, administrator dapat menggunakan:

Enter-PSSession -ComputerName WIN-SRV01

Gunakan account test yang memang diberi hak sesuai skenario lab.

Mengapa native tool penting?

Karena sebelum menyalahkan Evil-WinRM, firewall, Kerberos, bulan purnama, atau nasib, kita perlu memastikan layanan dasarnya memang bekerja.

Di Mana Evil-WinRM Masuk?

Dalam authorized assessment, Evil-WinRM berguna ketika assessor perlu memvalidasi bahwa credential test yang sudah disediakan atau diperoleh secara sah dalam scope benar-benar memiliki akses remote management.

Pola koneksi dasar pada lab:

evil-winrm -i 10.10.20.20 -u lab-auditor

Tool kemudian meminta credential secara interaktif sehingga password tidak perlu ditulis terang-terangan di command history.

Prinsip pentingnya: credential harus sudah authorized untuk digunakan. Artikel ini tidak membahas pencurian credential atau teknik memperoleh password.

Jika validasi berhasil, evidence yang kita cari bukan "hore dapat shell", tetapi jawaban terhadap pertanyaan berikut:

account apa yang dapat login;
privilege apa yang dimilikinya;
dari network mana login berhasil;
apakah login seharusnya diperbolehkan;
event apa yang muncul;
apakah SOC melihat aktivitas tersebut.

Cheat Sheet WinRM untuk Assessment

Network exposure

nmap -p 5985,5986 10.10.20.20

Test endpoint dari Windows

Test-WSMan WIN-SRV01

Lihat listener

winrm enumerate winrm/config/listener

Lihat service configuration

winrm get winrm/config/service

Lihat client configuration

winrm get winrm/config/client

Native PowerShell Remoting di lab

Enter-PSSession -ComputerName WIN-SRV01

Validasi Evil-WinRM menggunakan account lab

evil-winrm -i 10.10.20.20 -u lab-auditor

Cheat sheet ini sengaja fokus pada connectivity, configuration, dan access validation. Jangan mengubah assessment menjadi lomba mengetik command sebanyak mungkin.

Authentication: Bagian yang Sering Disederhanakan

WinRM dapat berada dalam beberapa model authentication tergantung desain environment. Pada domain Windows, Kerberos umumnya menjadi pilihan penting karena memberikan mutual authentication dan terintegrasi dengan Active Directory.

NTLM mungkin masih muncul pada environment tertentu, terutama karena compatibility atau desain legacy.

Yang perlu diaudit bukan hanya "authentication berhasil atau gagal", tetapi:

apakah Kerberos dapat digunakan sebagaimana mestinya;
apakah organisasi masih bergantung pada NTLM;
apakah privileged account digunakan pada jalur yang tepat;
apakah penggunaan TrustedHosts terlalu luas;
apakah Basic authentication aktif tanpa kebutuhan yang jelas.

Jangan menyalakan authentication mechanism hanya karena tutorial Internet mengatakan "kalau error, enable ini". Error hilang memang menyenangkan. Attack surface baru biasanya kurang menyenangkan.

TrustedHosts: Jangan Diisi `*` Karena Sedang Kesal

Pada skenario tertentu, administrator menggunakan WinRM di luar model domain/Kerberos dan mengatur TrustedHosts.

Masalah klasiknya adalah troubleshooting berubah menjadi:

TrustedHosts = *

Lalu konfigurasi sementara tersebut hidup bahagia selama tiga tahun.

Audit TrustedHosts secara berkala dan gunakan scope sesempit mungkin jika fitur tersebut benar-benar diperlukan.

Temporary workaround mempunyai bakat luar biasa untuk menjadi permanent architecture.

HTTP Bukan Berarti Password Dikirim Plaintext

Ada miskonsepsi bahwa port 5985 menggunakan HTTP sehingga credential otomatis berjalan sebagai plaintext.

Tidak sesederhana itu.

WinRM authentication dan message protection bergantung pada authentication mechanism dan konfigurasi yang digunakan. HTTPS memberikan TLS transport protection dan sangat relevan pada skenario tertentu, tetapi penilaian keamanan tidak boleh hanya berdasarkan nomor port.

Yang benar adalah melakukan review terhadap:

authentication mechanism;
encryption/message protection;
certificate management untuk HTTPS;
trust model;
network exposure;
identity privilege.

Security architecture jarang bisa dinilai hanya dengan kalimat "HTTP jelek, HTTPS bagus".

Studi Kasus: WinRM Terbuka dari User VLAN

Bayangkan organisasi memiliki struktur:

User VLAN        10.20.10.0/24
Admin VLAN       10.20.50.0/24
Server VLAN      10.20.80.0/24

Secara desain, server seharusnya hanya dikelola dari Admin VLAN.

Tetapi assessment menemukan:

User VLAN -> Server VLAN -> TCP/5985 ALLOWED

Seorang user biasa tidak otomatis dapat login karena masih membutuhkan authorization. Jadi apakah ini langsung critical?

Belum tentu.

Tetapi sekarang gabungkan dengan temuan lain:

credential administrator pernah digunakan pada workstation biasa;
endpoint tersebut terkena credential exposure;
WinRM server dapat dijangkau dari User VLAN;
administrative account memiliki hak remote management.

Sekarang beberapa kelemahan kecil membentuk attack path yang jauh lebih serius.

Inilah alasan artikel #06 BloodHound membahas relationship, #07 membahas credential exposure, dan artikel ini membahas remote management path. Security jarang hidup dalam kotak-kotak terpisah.

Attack → Evidence → Detection → Hardening

Mari kita pakai pola utama Red Team Series.

Attack / Activity

Seseorang mencoba menggunakan WinRM untuk melakukan remote administrative session menggunakan credential yang valid.

Evidence

Blue Team dapat mencari kombinasi telemetry dari:

Windows Security Event Log;
Microsoft-Windows-WinRM operational logs;
PowerShell operational logs;
process creation telemetry;
EDR;
firewall/network flow;
identity authentication logs.

Satu event saja sering tidak cukup. Context membuat perbedaan.

Detection

Beberapa pola yang layak mendapat perhatian:

WinRM connection dari workstation yang bukan administrative endpoint;
privileged account melakukan remote management dari user VLAN;
lonjakan koneksi ke port 5985/5986;
PowerShell remote session pada server yang jarang dikelola secara interaktif;
account melakukan remote session ke banyak host dalam waktu singkat;
remote management di luar maintenance window;
authentication menggunakan mekanisme legacy yang tidak sesuai baseline.

Detection sebaiknya membandingkan aktivitas dengan expected administrative behavior.

Kalau seluruh administrator memang menggunakan WinRM setiap hari, rule "ada WinRM = alert" hanya akan menghasilkan festival false positive.

Hardening

Prioritas hardening antara lain:

batasi TCP 5985/5986 hanya dari management network yang diperlukan;
gunakan dedicated administrative workstation untuk privileged administration;
terapkan least privilege pada account remote management;
gunakan Windows LAPS untuk local administrator password yang unik jika relevan;
kurangi penggunaan NTLM sesuai compatibility assessment;
review TrustedHosts;
gunakan HTTPS ketika architecture dan trust boundary membutuhkannya;
aktifkan PowerShell dan WinRM logging yang relevan;
kirim event penting ke SIEM;
monitor remote administration dari source yang tidak biasa.

Logging yang Layak Diperhatikan

WinRM Operational Log

Periksa channel:

Microsoft-Windows-WinRM/Operational

Channel ini memberikan visibility terhadap aktivitas WinRM.

PowerShell Operational Log

Microsoft-Windows-PowerShell/Operational

Untuk environment yang menggunakan PowerShell secara serius, pertimbangkan logging policy yang sesuai seperti Script Block Logging berdasarkan risk assessment organisasi.

Security Log

Authentication dan process-related telemetry pada Security log dapat dikorelasikan dengan event WinRM dan PowerShell.

Blue Team sebaiknya tidak bergantung pada satu log source. Correlation adalah teman baik kita; satu event tanpa context sering hanya gosip digital.

Network Segmentation: Kontrol yang Sering Paling Efektif

Bayangkan hanya administrative subnet yang boleh mengakses WinRM:

Admin VLAN ---- TCP/5985,5986 ----> Server VLAN
User VLAN  -------- BLOCK --------> Server VLAN
Guest VLAN -------- BLOCK --------> Server VLAN

Sekarang credential exposure pada user workstation masih serius, tetapi attacker tidak otomatis memiliki jalur network langsung ke management interface server.

Inilah konsep attack path interruption.

Kita tidak harus berharap setiap kontrol sempurna. Kita membuat beberapa lapisan sehingga kegagalan satu kontrol tidak langsung membuka seluruh environment.

Privileged Access Workstation

Privileged account sebaiknya tidak diperlakukan seperti account browsing biasa.

Administrative workstation atau Privileged Access Workstation membantu memisahkan aktivitas berisiko tinggi dari email, browsing, aplikasi umum, dan endpoint user sehari-hari.

Tujuannya sederhana:

Normal User Work
      !=
Privileged Administration

Kalau Domain Admin dipakai membuka attachment email lalu account yang sama digunakan mengelola Domain Controller, problem utamanya bukan Evil-WinRM. Problemnya adalah trust architecture.

Windows LAPS dan Local Administrator

Local administrator credential yang sama pada banyak host dapat memperbesar dampak compromise.

Windows LAPS membantu mengelola password local administrator secara otomatis sehingga setiap device dapat memiliki credential unik dan terrotasi.

Ini penting untuk membatasi lateral movement berbasis local administrative credential.

Sekali lagi, kita melihat bahwa mitigasi WinRM bukan sekadar "matikan WinRM".

Kalau organisasi memang membutuhkannya untuk automation dan administration, pertahankan fiturnya—tetapi perbaiki identity, segmentation, credential management, dan monitoring.

Jangan Asal Mematikan WinRM

Security recommendation yang berbunyi "disable semuanya" memang mudah ditulis.

Tetapi production environment punya kebutuhan operasional.

WinRM mungkin digunakan oleh:

configuration management;
server automation;
remote administration;
orchestration;
monitoring;
deployment system.

Hardening yang matang dimulai dengan pertanyaan:

"Siapa membutuhkan WinRM, dari mana, ke host mana, menggunakan identity apa, dan untuk tujuan apa?"

Setelah itu barulah firewall, RBAC, authentication, dan logging dibangun berdasarkan kebutuhan nyata.

Best Practices untuk Red Team

Dalam assessment:

konfirmasi scope sebelum melakukan connection testing;
gunakan test credential jika objective dapat divalidasi dengannya;
hindari menyimpan plaintext password dalam shell history;
dokumentasikan source IP dan target;
catat waktu koneksi;
jangan mengubah konfigurasi target tanpa kebutuhan dan izin;
hindari destructive action;
kumpulkan evidence minimum yang cukup;
lakukan cleanup jika ada artifact yang dibuat selama assessment.

Tujuan assessment adalah membuktikan risiko, bukan membuktikan siapa yang paling kreatif merusak lab production orang lain.

Best Practices untuk Blue Team

Blue Team dapat membuat baseline seperti:

Allowed Source    : Admin VLAN
Allowed Accounts  : Admin role tertentu
Allowed Targets   : Managed Windows Servers
Expected Hours    : Maintenance / business requirement
Expected Protocol : Kerberos where applicable

Kemudian cari deviasi.

Contoh:

Source      : Finance-Laptop-23
Destination : Domain Controller
Port        : 5985
Account     : privileged-admin
Time        : 02:17

Tidak otomatis malicious, tetapi jelas layak ditanyakan.

Detection yang bagus bukan sekadar mengenali tool. Detection yang bagus mengenali behavior yang tidak sesuai trust model.

Dari Evil-WinRM ke Attack Path

Sekarang mari hubungkan artikel #06 sampai #12:

#06 BloodHound
        |
        v
Privilege relationship ditemukan
        |
#07 Credential Exposure
        |
        v
Credential berisiko terungkap
        |
#08 Kerberos Enumeration
        |
#09 Service Account Security
        |
#10 AD CS Security
        |
#11 Name Resolution Security
        |
        v
Identity / credential path
        |
#12 WinRM
        |
        v
Remote Management Path

Ini jauh lebih berguna daripada menghafalkan tujuh tool secara terpisah.

Red Team yang matang mencari relationship. Blue Team yang matang memutus relationship berbahaya sebelum berubah menjadi attack path.

Checklist Audit WinRM

Gunakan checklist berikut pada authorized review:

[ ] Apakah WinRM benar-benar dibutuhkan pada host ini?
[ ] Port 5985/5986 hanya dapat dijangkau dari management network?
[ ] Apakah privileged account dibatasi ke administrative endpoint?
[ ] Authentication mechanism sesuai baseline?
[ ] TrustedHosts memiliki scope minimum?
[ ] Local administrator password unik dan dikelola?
[ ] WinRM Operational log tersedia?
[ ] PowerShell logging sesuai risk profile?
[ ] Event dikirim ke SIEM?
[ ] Remote administration dari source abnormal dideteksi?
[ ] Service account tidak memiliki privilege berlebihan?
[ ] Firewall rule direview secara periodik?

Checklist bukan sertifikat keamanan. Ia hanya memastikan kita tidak melupakan pertanyaan dasar.

Penutup

Evil-WinRM populer karena membuat interaksi dengan WinRM nyaman dalam security assessment. Tetapi tool bukan inti masalahnya.

Pertanyaan yang lebih penting adalah:

siapa yang boleh melakukan remote management;
dari network mana;
menggunakan credential apa;
privilege sebesar apa;
bagaimana aktivitas tersebut dideteksi;
dan bagaimana organisasi memutus attack path jika credential bocor.

Kalau WinRM hanya dapat diakses dari administrative network, privileged identity dikelola dengan baik, local administrator password unik, authentication dikontrol, dan telemetry dipantau, maka remote management dapat tetap menjadi fitur operasional yang berguna tanpa berubah menjadi pintu samping yang terlalu ramah.

Artikel berikutnya, #13 LinPEAS Cheat Sheet, membawa kita keluar dari Active Directory menuju Linux privilege escalation enumeration. Kita akan membahas bagaimana membaca misconfiguration secara sistematis tanpa menjadikan output berwarna-warni sebagai pengganti analisis.

Sumber Resmi

Microsoft Learn — Windows Remote Management: https://learn.microsoft.com/en-us/windows/win32/winrm/portal
Microsoft Learn — Installation and Configuration for Windows Remote Management: https://learn.microsoft.com/en-us/windows/win32/winrm/installation-and-configuration-for-windows-remote-management
Microsoft Learn — PowerShell Remoting: https://learn.microsoft.com/en-us/powershell/scripting/security/remoting/powershell-remoting-faq
Microsoft Learn — about_Remote_Requirements: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_remote_requirements
Microsoft Learn — Windows LAPS Overview: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview
MITRE ATT&CK — Windows Remote Management T1021.006: https://attack.mitre.org/techniques/T1021/006/
Evil-WinRM Project Documentation: https://github.com/Hackplayers/evil-winrm