#09 Kerberos Service Account Security: SPN, Kerberoasting Detection dan Hardening

Setelah #08 membahas Kerberos enumeration, sekarang kita masuk ke bagian yang sering bikin administrator Active Directory mengernyit: service account dan Service Principal Name (SPN). Bukan karena SPN itu jahat—justru SPN adalah bagian normal Kerberos—tetapi konfigurasi service account yang sudah bertahun-tahun tidak disentuh bisa berubah menjadi attack path yang menarik.

Artikel ini sengaja melihat topik Kerberoasting dari sisi security assessment dan defense. Kita akan memahami mekanismenya, evidence yang relevan, cara membaca Event ID 4769, mengapa RC4 dan password service account lama perlu mendapat perhatian, serta bagaimana gMSA membantu mengurangi risiko. Contoh hanya untuk lab atau environment yang secara eksplisit diotorisasi.

Konsep Dasar: SPN Itu Apa?

Service Principal Name adalah identifier yang digunakan Kerberos untuk mengaitkan sebuah service instance dengan security principal tertentu. Contoh konseptualnya seperti HTTP/web01.lab.local atau MSSQLSvc/sql01.lab.local:1433.

Ketika client ingin mengakses service yang menggunakan Kerberos, client meminta service ticket kepada Key Distribution Center (KDC). KDC kemudian menerbitkan ticket yang sesuai dengan service principal tersebut.

Normal? Sangat normal.

Masalah muncul ketika sebuah SPN terikat ke user account tradisional yang password-nya lemah, statis, terlalu lama tidak diganti, atau memiliki privilege berlebihan. Dalam kondisi tertentu, service ticket dapat menjadi bahan untuk offline password guessing. Inilah konsep yang dikenal sebagai Kerberoasting.

Poin pentingnya: Kerberoasting bukan bug ajaib pada Kerberos. Risiko utamanya lahir dari kombinasi protocol behavior yang legitimate dengan credential hygiene yang buruk.

Mengapa Service Account Menarik?

Service account sering memiliki karakteristik yang tidak dimiliki user biasa:

• password jarang diganti karena takut aplikasi berhenti;
• password dibuat manual bertahun-tahun lalu;
• account diberi privilege lebih besar dari kebutuhan aktual;
• interactive logon masih diizinkan;
• satu account digunakan banyak service;
• ownership account tidak jelas;
• dokumentasi dependency sudah hilang bersama laptop administrator tiga generasi lalu.

Kalimat klasiknya: “Jangan ganti password itu, nanti aplikasi lama mati.” Kalau kalimat tersebut menjadi kontrol keamanan utama, kita punya pekerjaan rumah.

Lab Aman untuk Memahami Alurnya

Gunakan domain lab terisolasi, misalnya:

Domain Controller : dc01.lab.local
Application Server: app01.lab.local
SQL Server        : sql01.lab.local
Domain            : LAB.LOCAL

Buat beberapa service account dummy dengan privilege minimum dan data yang tidak memiliki nilai produksi. Aktifkan auditing Kerberos pada Domain Controller agar kita dapat melihat Event ID yang muncul.

Tujuan lab bukan mengumpulkan credential. Tujuannya memahami hubungan:

Client
  ↓ meminta service ticket
KDC / Domain Controller
  ↓ menerbitkan ticket
Service Principal
  ↓
Windows Security Log (4769)

Dengan pola ini, Red Team dan Blue Team melihat aktivitas yang sama dari sudut berbeda.

SPN Enumeration untuk Assessment

Dalam assessment yang diotorisasi, langkah awal biasanya adalah membuat inventory SPN dan account pemiliknya. Windows menyediakan utilitas administratif seperti setspn untuk query dan management SPN.

Contoh inventory pada domain lab:

setspn -Q */*

Untuk account tertentu:

setspn -L LAB\svc_sql

Yang dicari bukan sekadar jumlah SPN. Kita ingin menjawab:

• SPN ini terikat ke computer account atau user account?
• siapa owner service account?
• kapan password terakhir diganti?
• apakah account memiliki privilege sensitif?
• apakah interactive logon diperlukan?
• apakah service masih digunakan?
• apakah account dapat dimigrasikan ke managed service account?

Enumeration yang baik menghasilkan inventory risiko, bukan hanya output terminal sepanjang novel.

Memahami Kerberoasting Tanpa Menjadikannya Resep Serangan

Secara konseptual, authenticated domain user dapat meminta service ticket untuk service tertentu. Sebagian material cryptographic pada ticket tersebut bergantung pada credential service account. Attacker dapat mencoba password candidate secara offline terhadap material tersebut.

Karena proses guessing dilakukan offline, Domain Controller tidak melihat setiap percobaan password. Yang terlihat di domain adalah aktivitas permintaan ticket sebelum proses offline tersebut.

Ini menjelaskan mengapa defense tidak boleh hanya mengandalkan account lockout.

Attack path sederhananya:

Domain Account
      ↓
SPN Discovery
      ↓
Service Ticket Request
      ↓
Offline Password Guessing
      ↓
Service Account Credential
      ↓
Privilege / Access milik account

Jika service account hanya memiliki privilege minimal, dampaknya terbatas. Jika account tersebut anggota group administratif, cerita berubah drastis.

Cheat Sheet Audit Service Account

Berikut cheat sheet yang aman untuk inventory dan defensive review.

# Query SPN di environment yang diotorisasi
setspn -Q */*

# Lihat SPN milik account tertentu
setspn -L LAB\svc_sql

# Cari duplicate SPN
setspn -X

Untuk sisi operasional, checklist audit jauh lebih penting:

[ ] Identifikasi semua user-based service account
[ ] Catat SPN dan service owner
[ ] Review privilege/group membership
[ ] Review password age
[ ] Pastikan password panjang dan random
[ ] Evaluasi migrasi ke gMSA
[ ] Batasi interactive logon
[ ] Review encryption type Kerberos
[ ] Monitor Event ID 4769
[ ] Dokumentasikan dependency sebelum perubahan

Event ID 4769: Sahabat Blue Team

Pada Domain Controller, Event ID 4769 — A Kerberos service ticket was requested merupakan salah satu telemetry utama untuk memahami penggunaan service ticket.

Jangan membuat rule sederhana seperti:

Event 4769 muncul = Kerberoasting.

Itu akan membuat SIEM sibuk berteriak sepanjang hari karena permintaan service ticket adalah aktivitas normal di domain.

Detection harus melihat konteks dan pola.

Beberapa signal yang layak dianalisis:

• satu account meminta ticket untuk banyak SPN dalam periode singkat;
• account atau workstation yang biasanya tidak melakukan aktivitas tersebut tiba-tiba menghasilkan pola enumeration;
• request terhadap service account bernilai tinggi;
• penggunaan encryption type legacy yang tidak sesuai baseline;
• aktivitas terjadi dari endpoint yang tidak lazim;
• pola ticket request diikuti aktivitas autentikasi atau privilege yang anomali.

Baseline sangat penting. Domain Controller yang ramai memang menghasilkan banyak ticket. Detection tanpa baseline seperti alarm mobil yang berbunyi setiap ada motor lewat—akhirnya semua orang memilih mengabaikannya.

RC4: Kenapa Masih Dibicarakan?

Environment Active Directory lama sering masih memiliki dependency terhadap RC4. Dari perspektif Kerberos security modern, organisasi sebaiknya mengaudit penggunaan encryption type legacy dan bergerak menuju AES ketika compatibility memungkinkan.

Microsoft menyediakan guidance untuk mendeteksi dan meremediasi penggunaan RC4 pada Kerberos. Event 4768 dan 4769 dapat membantu administrator melihat encryption type yang digunakan dan mengidentifikasi account atau perangkat yang masih bergantung pada RC4.

Jangan langsung mematikan RC4 tanpa inventory. Sistem legacy punya bakat unik untuk baru memperkenalkan dirinya ketika production sudah error.

Workflow yang lebih aman:

Audit
  ↓
Identify dependency
  ↓
Test compatibility
  ↓
Remediate account/device
  ↓
Monitor
  ↓
Enforce stronger configuration

gMSA: Service Account yang Tidak Minta Password di Sticky Note

Group Managed Service Account (gMSA) dirancang untuk membantu menjalankan service dengan password yang dikelola secara otomatis oleh Active Directory.

Keuntungannya antara lain:

• password kompleks dan dikelola otomatis;
• rotasi password tidak bergantung pada administrator mengingat kalender;
• mengurangi kebutuhan menyimpan password service secara manual;
• dapat digunakan oleh host yang memang diberi hak mengambil managed password;
• lebih cocok untuk banyak workload Windows dibanding user account statis.

Tentu gMSA bukan tombol “secure everything”. Scope host yang dapat menggunakan account, privilege, delegation, dan service configuration tetap harus direview.

Tetapi dibanding svc_legacy dengan password yang terakhir diganti ketika orang masih ramai membeli DVD, gMSA biasanya langkah maju yang cukup besar.

Studi Kasus: svc_report yang Terlupakan

Bayangkan tim assessment menemukan account:

Account : svc_report
SPN     : HTTP/report01.lab.local
Password age : sangat lama
Group   : Local Administrators pada report01

Aplikasi reporting masih berjalan sehingga tidak ada yang berani menyentuh account tersebut.

Dari perspektif risiko, masalahnya bukan hanya password age.

Attack path potensial adalah:

Compromised domain user
        ↓
Service account exposure
        ↓
Credential compromise
        ↓
Local admin pada report01
        ↓
Access ke data/reporting infrastructure

Evidence

Assessment mendokumentasikan SPN, account ownership, password age, group membership, host dependency, dan telemetry Kerberos yang relevan—tanpa memasukkan password atau secret ke laporan.

Detection

Blue Team membuat baseline Event 4769, memonitor request abnormal terhadap SPN sensitif, menghubungkan source host dengan identity telemetry, serta mencari perubahan perilaku setelah service ticket request.

Hardening

Tim aplikasi menguji migrasi svc_report ke gMSA, mengurangi local privilege, membatasi logon rights, mendokumentasikan dependency, dan memastikan Kerberos menggunakan encryption type modern yang kompatibel.

Satu temuan akhirnya memperbaiki identity hygiene, bukan sekadar menghasilkan screenshot tool.

Attack → Evidence → Detection → Hardening

Attack

Adversary yang sudah memiliki authenticated domain access dapat mencari service principal dan menargetkan service account yang credential-nya berpotensi lemah.

Evidence

Evidence yang berguna meliputi:

• SPN mapping;
• service-account ownership;
• password age;
• privilege/group membership;
• Event ID 4769;
• source workstation;
• encryption type;
• subsequent authentication behavior.

Detection

Detection sebaiknya menggabungkan beberapa signal, bukan satu Event ID saja. Prioritaskan account bernilai tinggi dan pola request yang berbeda dari baseline.

Hardening

• gunakan gMSA bila workload mendukung;
• gunakan password service account yang panjang, random, dan unik jika gMSA belum memungkinkan;
• rotasi credential secara terencana;
• terapkan least privilege;
• hapus service account yang sudah tidak digunakan;
• batasi interactive logon;
• audit SPN secara berkala;
• kurangi dependency terhadap RC4;
• monitor Kerberos service-ticket activity;
• dokumentasikan owner dan dependency setiap service account.

Jangan Simpan Credential di Laporan

Ini terdengar sepele tetapi sering dilupakan.

Security report bukan password manager.

Jika assessment membuktikan sebuah credential lemah atau exposed, evidence harus cukup untuk membuktikan risiko tanpa menyebarkan secret ke PDF, ticket system, email, atau screenshot yang kemudian hidup abadi di shared folder.

Gunakan masking, reference ID, dan secure evidence repository sesuai Rules of Engagement.

Best Practices untuk Red Team

Pertama, mulai dari inventory dan privilege context. Jangan menganggap semua SPN sama menariknya.

Kedua, minimalkan impact. Tujuan assessment adalah membuktikan risiko, bukan membuat service account terkunci atau aplikasi berhenti.

Ketiga, catat source host dan waktu aktivitas agar Blue Team dapat melakukan correlation.

Keempat, koordinasikan validation dengan defender jika engagement menggunakan model Purple Team. Kerberoasting adalah topik bagus untuk menguji apakah identity telemetry benar-benar dipakai, bukan sekadar dikumpulkan.

Kelima, setelah menemukan service account lemah, jangan berhenti pada rekomendasi “ganti password”. Cari akar masalah: ownership, lifecycle, privilege, dependency, dan architecture.

Best Practices untuk Blue Team

Buat inventory service account dan SPN sebagai bagian identity governance. Prioritaskan user-based service account yang memiliki privilege tinggi atau password lama.

Centralize Domain Controller security logs. Event 4769 menjadi jauh lebih berguna ketika dapat dikorelasikan dengan endpoint, network, identity, dan privilege telemetry.

Audit encryption type. Legacy protocol support sering bertahan karena tidak ada yang tahu siapa yang masih menggunakannya.

Gunakan gMSA secara bertahap. Mulai dari workload yang paling mudah dimigrasikan dan dokumentasikan compatibility issue.

Terakhir, treat service account seperti machine identity penting, bukan “user account yang kebetulan tidak punya manusia”.

Hubungan dengan Artikel Sebelumnya

Kalau mengikuti seri dari awal, puzzle-nya mulai tersambung.

#06 BloodHound menunjukkan bagaimana relationship dan privilege membentuk attack path.

#07 Windows Credential Exposure membahas mengapa credential yang bocor dapat memperluas akses.

#08 Kerbrute melihat Kerberos enumeration dan detection.

Sekarang #09 menunjukkan bagaimana service account dan SPN menjadi bagian identity attack surface.

Jadi jangan melihat tiap tool sebagai pulau terpisah. Red Team assessment yang matang justru menghubungkan evidence antar-layer.

Penutup

Kerberoasting menarik bukan karena command-nya keren, tetapi karena ia memperlihatkan satu pelajaran klasik cybersecurity: protocol yang legitimate dapat menjadi berisiko ketika identity hygiene buruk.

SPN bukan vulnerability. Service account bukan vulnerability. Kerberos juga bukan musuh.

Yang menjadi masalah adalah password statis, privilege berlebihan, account tanpa owner, encryption legacy, monitoring yang lemah, dan dependency yang tidak pernah direview.

Kalau setelah membaca artikel ini Anda mulai bertanya “service account kita ada berapa, siapa owner-nya, dan kapan terakhir direview?”, berarti tujuan artikel tercapai.

Artikel berikutnya adalah #10 Certipy Cheat Sheet — Audit Active Directory Certificate Services (AD CS). Kita akan melihat mengapa certificate infrastructure juga merupakan bagian penting dari Active Directory attack surface, sekaligus bagaimana defender mengaudit dan mengeraskannya.

Sumber Resmi

• Microsoft Learn — Service Principal Names: https://learn.microsoft.com/en-us/windows/win32/ad/service-principal-names
• Microsoft Learn — Event 4769: https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4769
• Microsoft Learn — Detect and remediate RC4 usage in Kerberos: https://learn.microsoft.com/en-us/windows-server/security/kerberos/detect-remediate-rc4-kerberos
• Microsoft Learn — Group Managed Service Accounts overview: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-managed-service-accounts/group-managed-service-accounts/group-managed-service-accounts-overview
• MITRE ATT&CK T1558.003 — Kerberoasting: https://attack.mitre.org/techniques/T1558/003/
• Microsoft Learn — setspn: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/setspn