Logon session ve access token: Bir işlemin kimliği ve yetkileri nasıl oluşur?

1. Core Mechanism / Temel mekanizma

Başarılı kimlik doğrulamasından sonra authentication package, LSA içinde bir logon session oluşturur ve token üretimi için bilgi sağlar. Her process bir primary token taşır; istemciyi impersonate eden thread ayrıca bir impersonation token kullanabilir. Bu ders directory üyeliğini değiştirmeyi değil, oluşmuş güvenlik bağlamının erişim denetiminde nasıl seçildiğini inceler.

Arabirimler ve belirtimler

• GetTokenInformation(TokenStatistics): TOKEN_STATISTICS yapısındaki AuthenticationId, TokenId ve TokenType alanlarını döndürür.
• OpenProcessToken: process'in primary token'ına erişim ister.
• OpenThreadToken: impersonating thread'in token'ına erişim ister.
• 4624 TargetLogonId ile 4672 SubjectLogonId, aynı bilgisayardaki session korelasyonunda kullanılabilir.
• 4672 PrivilegeList, hassas privilege'ların yeni logon session'a atandığını bildirir; kullanımı kanıtlamaz.

Session kimliği ile token nesnesini ayır

Logon session, LSA'nın yerel olarak bir Logon ID/LUID ile tanımladığı oturum bağlamıdır. Access token ise kullanıcı ve grup SID'lerini, privilege listesini, token türünü ve erişim denetiminde kullanılan diğer güvenlik bilgilerini taşıyan nesnedir.

TOKEN_STATISTICS.AuthenticationId token'ın temsil ettiği logon session'ı; TokenId ise belirli token nesnesini tanımlar. Bu nedenle aynı AuthenticationId'yi paylaşan iki token'ın TokenId değerleri farklı olabilir. Logon ID'yi token nesnesinin kimliği sanmak korelasyonu bozar.

Etkili kimlik thread bağlamına göre değişebilir

Her process'in primary token'ı vardır. Normal erişim denetiminde process bu güvenlik bağlamıyla hareket eder. Bir sunucu thread'i istemciyi impersonate ediyorsa thread ayrıca bir impersonation token taşır ve o thread'in erişim denetiminde istemci bağlamı kullanılabilir.

Process sahibi bu sırada değişmez. Değişen şey belirli thread'in access check sırasında sunduğu etkin token'dır. Bu ayrım, bir servis process'inin hesabına bakarak içindeki her thread'in yaptığı erişimi aynı kimliğe yazmayı önler.

Sahnede ArchiveSvc process’inin primary token’ı svc.archive hesabına ait. Thread A tunahan adına bir istemci isteğini işlerken Thread B arka plan işini process bağlamıyla sürdürüyor. Örnekte service SID için WRITE, client SID için READ tanımlı. Thread A istemciyi impersonate ederken WRITE isteği reddediliyor; aynı istek Thread B için kabul edilebiliyor. Process hesabı ve directory üyeliği değişmiyor.

Başarılı Revert, thread’in istemci impersonation bağlamını sonlandırır; sonraki yerel işlerde process bağlamı yeniden kullanılır. Revert başarısızsa istemci bağlamı sürer. Eğitim örneği bunu başarılı bir dönüş saymak ya da kaynak kararı üretmek yerine bu sınırda durur.

Token oluşumu ve erişim denetimi

Başarılı authentication sonrasında authentication package bir logon session oluşturur; LSA session için Logon ID atar ve token üretir. Yeni process primary token'ın bir kopyasıyla başlatılabilir. Bir servis istemciyi impersonate ederse thread'e ikinci token bağlanır.

Bir nesne erişiminde sistem önce etkin token'ı belirler. Ardından token'daki SID'ler ve privilege state'i, istenen erişim ve nesnenin güvenlik tanımıyla değerlendirilir. Token'da privilege bulunması ile onun belirli bir işlemde kullanılması aynı olay değildir.

Aynı hostta telemetri bağı kur

4624 erişilen bilgisayarda yeni logon session'ı kaydeder. 4672 ise hassas privilege'ların yeni session'a atanması halinde aynı hostta oluşabilir. 4624 TargetLogonId ile 4672 SubjectLogonId eşleştirilerek session bağlamı kurulabilir.

Bu bağ yalnız aynı bilgisayar kapsamında anlamlıdır; LUID ağ genelinde benzersiz kimlik değildir. 4624 sürümüne göre TargetLinkedLogonId ve ElevatedToken alanları bulunmayabilir. 4672'nin varlığı privilege kullanımını veya kötü niyeti kanıtlamaz.

Durum ve veri akışı

1. Authentication package başarılı kimlik doğrulamasından sonra logon session oluşturur.
2. LSA session'a yerel bir Logon ID/LUID atar ve access token üretir.
3. Process primary token bağlamıyla başlatılır.
4. Bir servis thread'i istemciyi impersonate ederse thread'e impersonation token bağlanır.
5. Erişim isteğinde primary veya impersonation token bağlama göre etkin token olarak seçilir.
6. Token SID'leri, privilege state'i, istenen haklar ve nesnenin güvenlik tanımı değerlendirilir.
7. Aynı session'a bağlı token'lar AuthenticationId'yi paylaşabilir, fakat ayrı TokenId değerleri taşır.

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım şudur: Bir process'in hesabını biliyorsam onun içindeki bütün thread'lerin yaptığı erişimin kimliğini de biliyorum.

Technical prerequisites

• Bir servis process'i veya thread'i üzerinde kod çalıştırabilme ya da onun token kullanımını etkileyebilme.
• Thread'in kullanılabilir bir istemci impersonation token'ına erişmesi.
• Impersonation level'ın hedef işlem için yeterli olması.
• Token'daki etkin SID veya privilege'ların ve hedef kaynağın erişim kontrollerinin istenen işleme izin vermesi.
• Uzak kaynağa geçiş gerekiyorsa ayrıca uygun delegation koşullarının sağlanması; yerel impersonation tek başına yeterli sayılmaz.

Exploitation mechanism / İstismar mekanizması

Servis process'inin primary token'ı servis hesabını temsil ederken istemciyi impersonate eden bir thread'in access check'i istemcinin token'ıyla yapılabilir. Process sahibi değişmeden thread'in etkili güvenlik bağlamı değişir. Bu mekanizma directory group membership yazmaz ve yeni bir ayrıcalık üretmez; yalnız eldeki token'ın izin verdiği kapsamda çalışır.

Token kullanımı üyelik değişikliği değildir

Bir impersonation token'ını kullanmak, kullanıcı veya grup nesnesine üye eklemek değildir. Etki mevcut token'daki SID, privilege ve impersonation level ile sınırlıdır.

Uzak bir sisteme erişim gerektiğinde delegation koşulları ayrıca devreye girer. Bu yüzden yerel bir dosyada etkili olan impersonation bağlamını bütün ağa genellemek hatalıdır.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• 4624, erişilen bilgisayarda Audit Logon success kapsamında oluşur; Version 0, 1 veya 2 olabilir.
• 4672, Audit Special Logon success kapsamında hassas privilege atanmış yeni logon session'ı kaydeder; Version 0'dır.
• 4624 TargetLogonId ile 4672 SubjectLogonId yalnız aynı Computer değeri bağlamında eşleştirilmelidir.
• Bu olaylar için nesne SACL'i gerekmez.

Events and relevant fields

• 4624: TargetUserSid, TargetUserName, TargetDomainName, TargetLogonId, LogonType ve AuthenticationPackageName.
• 4624 Version 2: TargetLinkedLogonId ve ElevatedToken; eski sürümlerde bulunmayabilir.
• 4672: SubjectUserSid, SubjectUserName, SubjectDomainName, SubjectLogonId ve PrivilegeList.
• 4672, privilege atamasını gösterir; privilege'ın kullanıldığını göstermez.

Atama ile kullanımı karıştırma

4672 PrivilegeList yeni session'a hassas privilege atandığını söyler. Hangi process'in privilege'ı hangi işlemde kullandığını tek başına söylemez.

Bu nedenle 4624/4672 bağı session bağlamı kurar; davranış kanıtı için ilgili process ve kaynak telemetrisi ayrıca gerekir.

Detection logic · XPath

*[System[(EventID=4624 or EventID=4672)]]

Query assumptions

• Bu ifade yalnız olayları seçer; SIEM alan eşlemesi veya alarm değildir.
• Sonraki işlem aynı Computer üzerinde 4624 TargetLogonId ile 4672 SubjectLogonId değerlerini eşleştirmelidir.
• 4624 sürümüne göre TargetLinkedLogonId ve ElevatedToken bulunmayabilir.
• Sorgu gerçek Windows hostunda çalıştırılmadı; veri kümesi, zaman penceresi ve eşik yoktur.

False positives

• SYSTEM logon'ları yoğun 4672 üretir ve tek başına şüpheli değildir.
• Yönetim ve servis hesaplarının rolüne uygun hassas privilege atamaları olağan olabilir.
• Negatif sınır: 4672 bulunmaması token'ın zararsız olduğunu veya privilege'ın daha sonra kullanılmayacağını kanıtlamaz.
• Token kullanımı logon olayından uzun süre sonra gerçekleşebilir.

Hardening

• Hassas privilege atamalarını host rolüne göre en aza indir.
• Servisleri ayrı ve düşük yetkili kimliklerle çalıştır.
• SYSTEM ve onaylı servis hesapları için aynı hostta 4624/4672 tabanı oluştur; bilinmeyen session eşleşmelerini incele.
• User-right değişikliklerini önce pilot hostlarda uygula; servis işlevini ve olay hacmini doğrula, sorun halinde önceki atamaya dön.
• İmpersonation sonucu kadar process bağlamına dönüş sonucunu da kontrol et; başarısız Revert’i başarılı dönüş sayma. 4672 tek başına belirli bir thread’in etkin token’ını göstermez.

Örnekler üzerinde oku / Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing"/>
    <EventID>4672</EventID>
    <Version>0</Version>
    <Channel>Security</Channel>
    <Computer>WS01.iyelabs.example</Computer>
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-5-21-1000-1000-1000-1104</Data>
    <Data Name="SubjectUserName">tunahan</Data>
    <Data Name="SubjectDomainName">IYELABS</Data>
    <Data Name="SubjectLogonId">0x671101</Data>
    <Data Name="PrivilegeList">SeImpersonatePrivilege SeDebugPrivilege</Data>
  </EventData>
</Event>

İki yanlış kanı / Two reality checks

Sanılan: Bir process'in tek bir kimliği vardır; process hesabını bilirsem bütün erişimlerin kimliğini bilirim.

Gerçekte: Process primary token taşır; impersonating thread ayrıca istemci token'ını kullanabilir. Etkili access check bağlama göre değişir ve process sahibi değişmeden thread'in güvenlik bağlamı farklı olabilir.

Sanılan: 4672 görülmesi listelenen privilege'ların kullanıldığını kanıtlar.

Gerçekte: 4672 hassas privilege'ların yeni logon session'a atandığını bildirir. Hangi privilege'ın hangi işlemde kullanıldığı için ek process ve kaynak kanıtı gerekir.

Kaynaklar / Sources

• Microsoft · LSA Logon Sessions
  Giriş ve reference-count paragrafları; logon session oluşumu ve Logon ID bağlamı.
• Microsoft · Access Tokens
  Access token contents; primary ve impersonation token ayrımı.
• Microsoft · TOKEN_STATISTICS
  Members: TokenId, AuthenticationId ve TokenType.
• Microsoft · Impersonation Tokens
  Giriş ve API listesi; impersonating thread'in primary ve impersonation token bağlamı.
• Microsoft · 4624(S) An account was successfully logged on
  Event Description, Versions ve Field Descriptions.
• Microsoft · 4672(S) Special privileges assigned to new logon
  Event XML, Field Descriptions ve privilege ataması semantiği.
• Microsoft · RevertToSelf
  Return value and Remarks: successful termination versus continued client context on failure.