Canarytokens ve Honeytoken Rehberi: Saldırganı Erken Yakalamak İçin Deception Engineering

Geleneksel güvenlik araçları çoğu zaman saldırganın yaptığı işlemi “kötü” olarak sınıflandırmaya çalışır. Honeytoken yaklaşımı ise daha basit bir soru sorar: Normal bir kullanıcının asla dokunmaması gereken bu sahte varlığa kim erişti? Canarytokens, dosya, URL, API anahtarı, DNS kaydı, bulut kimliği veya yapılandırma dosyası gibi görünen dijital tuzaklarla yüksek doğrulukta erken uyarı üretir.

Honeytoken ve Canarytoken nedir?

Honeytoken, gerçek bir sistemin içine yerleştirilen fakat meşru iş akışında kullanılmayan sahte bir veri veya kimlik bilgisidir. Saldırgan dosya sunucusunu taradığında, parola kasasını karıştırdığında, kaynak kod deposundan anahtar topladığında veya bulut ortamında keşif yaptığında bu cazip görünen varlığa dokunabilir. Token kullanıldığı anda savunma ekibine alarm gider.

Canarytokens, Thinkst tarafından sunulan ücretsiz dijital tripwire altyapısıdır. Klasik honeypot kurmak için ayrı bir sunucu ve yoğun bakım gerekirken Canarytoken çok hafif bir işaretleyici olarak çalışabilir. Örneğin “Yönetici-Parolalari.xlsx” gibi görünen bir belge, sahte AWS erişim anahtarı, Kubeconfig dosyası, DNS tokenı veya web bug kullanılabilir.

Honeytoken’ın değeri, saldırganı engellemesinden çok erken ve düşük gürültülü bir tespit sinyali üretmesidir. Doğru yere yerleştirilmiş bir tokena normal kullanıcı dokunmuyorsa, alarmın araştırma önceliği yüksektir.

Honeypot ile honeytoken arasındaki fark

Özellik	Honeypot	Honeytoken
Kapsam	Sahte sistem veya servis	Sahte veri, kimlik, dosya ya da bağlantı
Kurulum	Ayrı altyapı ve bakım gerektirebilir	Mevcut ortama serpiştirilebilir
Kaynak tüketimi	Orta veya yüksek	Çok düşük
Tespit noktası	Ağ ve servis etkileşimi	Veri erişimi, kimlik kullanımı veya dosya açılması
Risk	Yanlış yapılandırılırsa saldırı yüzeyi oluşturabilir	Çoğunlukla pasif ve sınırlı
Kullanım amacı	Saldırgan davranışını gözlemlemek	Erken uyarı ve yetkisiz erişim tespiti

İki yöntem birbirinin alternatifi değildir. Bir kurum ağ segmentinde honeypot çalıştırırken dosya paylaşımlarında, bulut hesaplarında ve geliştirici depolarında honeytoken kullanabilir. Böylece hem saldırganın davranışı gözlemlenir hem de kritik keşif adımları hızlı biçimde fark edilir.

Nerelere yerleştirilebilir?

1. Dosya sunucuları ve paylaşımlar

Saldırganlar ilk erişimden sonra genellikle paylaşımları listeler ve değerli görünen belgeleri toplar. “Finans”, “Yönetim”, “Yedek”, “VPN” veya “Müşteri” gibi klasörlerde gerçekçi fakat kullanılmayan bir belge tokenı güçlü sinyal üretebilir. Dosya adı cazip olmalı, ancak çalışanların yanlışlıkla açmasını teşvik edecek kadar gündelik bir konumda bulunmamalıdır.

Örnek yerleşim mantığı:

CODE TERMINAL

\\fileserver\Arsiv\Eski-Yonetici-Parolalari.docx
\\fileserver\Finans\2026-Satin-Alma-Butcesi.xlsx
\\fileserver\BT\VPN-Acil-Erisim.pdf

Bu adlar yalnızca tuzak içindir; gerçek parola, kişi veya müşteri verisi kullanılmamalıdır.

2. Kaynak kod depoları ve CI/CD

Kaynak kod sızıntılarında saldırganların ilk aradığı öğeler API anahtarları, .env dosyaları, bulut kimlik bilgileri ve pipeline sırlarıdır. Özel bir test deposuna sahte fakat izlenebilir anahtar koymak, depo içeriğinin yetkisiz biçimde kopyalandığını gösterebilir.

CODE TERMINAL

# Bu değer gerçek bir hizmete erişmez; yalnızca kontrollü honeytoken örneğidir.
LEGACY_BACKUP_ACCESS_KEY=AKIA...CANARY...

Gerçek üretim deposuna rastgele sahte anahtar eklemek geliştiricileri yanıltabilir. Token açıklaması, sahipliği ve konumu güvenlik envanterinde tutulmalı; ancak saldırganın kolayca anlayacağı açık “canary” etiketi kullanılmamalıdır.

3. AWS, Azure ve diğer bulut ortamları

Bulut kimlik bilgisi tokenları, çalınan sırların nerede kullanıldığını anlamak için değerlidir. Sahte AWS anahtarı bir parola kasasında, eski yedek dosyasında veya test betiğinde konumlandırılabilir. Anahtar çağrıldığında kaynak IP, zaman ve kullanılan servis gibi bağlam bilgileri alarmı zenginleştirebilir.

Bulut tokenı tasarlarken şu kurallar izlenmelidir:

Sahte kimlik hiçbir gerçek kaynağa erişmemeli.
İzin politikası açık biçimde etkisiz olmalı.
Token tek bir konuma yerleştirilmeli; böylece alarmın kaynağı anlaşılmalı.
Anahtarın sahibi, oluşturulma tarihi ve iptal prosedürü kayıt altına alınmalı.
Yanlış alarm üreten otomatik tarayıcılar için kontrollü istisna süreci tanımlanmalı.

4. Kubernetes ve container altyapısı

Kubeconfig biçimindeki tokenlar, saldırganın cluster erişimi aradığını veya ele geçirilen bir geliştirici cihazındaki yapılandırmaları kullandığını gösterebilir. Token gerçek bir kümeye yönetim erişimi vermemeli; yalnızca kontrol edilen bir endpoint’e erişim denemesi üretmelidir.

Konteyner imajlarının içine token gömmek dikkat gerektirir. İmaj herkese açık bir registry’ye gönderiliyorsa alarm meşru güvenlik tarayıcıları tarafından tetiklenebilir. Daha iyi yaklaşım, dahili registry, ayrıcalıklı pipeline çalışma alanı veya yalnızca yetkili personelin eriştiği operasyon klasörleridir.

5. Active Directory ve kimlik sistemleri

Kullanılmayan ama gerçekçi görünen bir servis hesabı, saldırganın parola püskürtme, kullanıcı keşfi veya ayrıcalıklı hesap avcılığı faaliyetini açığa çıkarabilir. Bu hesapla başarılı oturum açma mümkün olmamalı; başarısız kullanım denemeleri SIEM’e yüksek öncelikli olay olarak taşınmalıdır.

Kimlik tokenlarında parola politikası istisnası oluşturmak veya hesabı gerçek gruplara eklemek risklidir. Görünürlük ile gerçek yetki birbirinden ayrılmalıdır. Hesap açıklamalarında “honeypot” yazmak yerine sahiplik CMDB veya güvenlik kasasında tutulmalıdır.

Deception engineering için yerleşim modeli

Rastgele token dağıtmak yerine saldırganın izleyebileceği yolu modellemek gerekir. MITRE ATT&CK taktikleri, yerleşim noktalarını planlamak için yararlı bir çerçeve sunar.

Saldırgan aşaması	Beklenen davranış	Uygun token
Keşif	Paylaşım ve kullanıcı listeleme	Ağ klasörü, sahte servis hesabı
Kimlik bilgisi erişimi	.env, parola kasası ve yedek arama	API anahtarı, bulut kimliği
Yanal hareket	Uzak bağlantı ve yönetim paylaşımı kullanımı	Ağ paylaşımı, RDP/SSH bağlantı izi
Bulut keşfi	Kubeconfig ve erişim anahtarı arama	Kubeconfig, AWS/Azure tokenı
Veri toplama	Hassas görünen dosyaları açma	Belge, PDF, spreadsheet tokenı
Kalıcılık	Kimlik ve uygulama entegrasyonu arama	Sahte SAML/IdP uygulaması

Her kritik saldırı yoluna en az bir tespit noktası koymak iyi bir başlangıçtır. Domain controller, yedek sunucusu, yönetim atlama sunucusu, CI/CD sistemi, dosya sunucusu ve bulut yönetim katmanı ayrı ayrı değerlendirilmelidir.

Canarytoken yaşam döngüsü

Amaç belirleme: Hangi saldırgan davranışını yakalamak istediğinizi yazın. “Bir yerde token olsun” yeterli bir hedef değildir.
Token oluşturma: Uygun token türünü seçin, açıklama ve alarm kanalını tanımlayın.
Tekil yerleşim: Her tokenı yalnızca bir konuma koyun. Aynı tokenın on yerde bulunması olay kaynağını belirsizleştirir.
Envanter kaydı: Token kimliği, konumu, sahibi, oluşturulma tarihi, beklenen tetikleyici ve kaldırma tarihi kaydedilsin.
Kontrollü test: Tokenı güvenlik ekibinin onaylı test cihazından tetikleyin; e-posta, webhook ve SIEM zincirini doğrulayın.
İzleme ve bakım: Dosya taşınmış mı, hesap silinmiş mi, entegrasyon bozulmuş mu düzenli kontrol edin.
İptal ve yenileme: Organizasyon değişikliklerinde eski tokenları kaldırın ve konum bilgisini güncelleyin.

Alarmı SIEM’e taşıma

E-posta alarmı küçük ekiplerde başlangıç için yeterli olabilir; fakat kurumsal kullanımda webhook üzerinden SIEM veya SOAR entegrasyonu tercih edilmelidir. Alarm kaydında en az şu alanlar bulunmalıdır:

token kimliği ve türü,
yerleşim konumu veya varlık etiketi,
tetiklenme zamanı,
kaynak IP ve mümkünse cihaz kimliği,
HTTP user-agent, DNS sorgusu veya ilgili protokol ayrıntısı,
token sahibi ve olay müdahale ekibi,
beklenen otomasyon veya tarayıcı istisnaları.

Örnek normalize edilmiş olay:

CODE TERMINAL

event.kind: alert
event.category: intrusion_detection
rule.name: honeytoken_triggered
canary.token_type: kubeconfig
canary.asset: build-runner-03
source.ip: 203.0.113.25
risk.score: 95
incident.priority: critical

SOAR akışı kaynağın EDR durumunu kontrol edebilir, aynı IP’den gelen diğer alarmları ilişkilendirebilir, kullanıcı oturumlarını sorgulayabilir ve olay kaydı açabilir. Ancak otomatik izolasyon kararı token türüne göre verilmelidir. Örneğin internet tarayıcısının tetiklediği web tokenı ile yalnızca dahili parola kasasında bulunan bulut anahtarının tetiklenmesi aynı ağırlıkta değildir.

Yanlış pozitifleri azaltma

Honeytoken alarmları doğası gereği düşük gürültülü olsa da yanlış pozitif tamamen ortadan kalkmaz. Antivirüs tarayıcıları belgeleri açabilir, veri kaybı önleme ürünleri dosya içeriğini inceleyebilir, e-posta güvenlik ağ geçitleri bağlantıları önceden ziyaret edebilir ve bulut güvenlik tarayıcıları anahtarları test edebilir.

Tokenı üretime koymadan önce kurumun AV, EDR, DLP ve e-posta güvenlik zincirinde test edin.
Kaynak IP’ye göre kör beyaz liste yerine araç kimliği, zaman, protokol ve yerleşim bağlamını birlikte değerlendirin.
Her token için beklenen tarayıcı davranışını belgeleyin.
Tek bir tokenı çok sayıda ortama kopyalamayın.
Alarm oranı aniden artarsa önce otomasyon değişikliklerini, sonra gerçek saldırı ihtimalini araştırın.

Güvenli kullanımda kritik hatalar

Gerçek sır kullanmak

Honeytoken hiçbir zaman gerçek bir API anahtarının kopyası olmamalıdır. Tuzak kimlik bilgisi işlevsel yetki taşımamalı ve üretim verisine erişmemelidir.

Herkesin kullandığı dosyaya yerleştirmek

Çalışanların sık açtığı bir dosya sürekli alarm üretir ve güvenlik ekibinin sinyale güvenini azaltır. Konum cazip ama meşru iş akışının dışında olmalıdır.

Envantersiz token bırakmak

Sahibi bilinmeyen eski tokenlar, altyapı değişiklikleri sırasında kaybolur. Her token bir varlık gibi yönetilmelidir.

Alarmı yalnızca e-postaya göndermek

Kritik bir token gece tetiklendiğinde okunmayan e-posta saatlerce gecikmeye yol açabilir. Nöbet sistemi ve SIEM entegrasyonu kullanılmalıdır.

Tokena aşırı gerçek yetki vermek

Tuzak ne kadar gerçekçi olursa olsun saldırgana yeni bir kabiliyet kazandırmamalıdır. Amaç gözlemlemek ve uyarmaktır; savunma adına yeni saldırı yüzeyi oluşturmamak gerekir.

Tetiklenme anında olay müdahalesi

Bir honeytoken alarmı geldiğinde şu sıra izlenebilir:

Alarmın kontrollü test veya bilinen tarayıcıdan gelmediğini doğrulayın.
Tokenın tam konumunu ve hangi hesapların o konuma erişebildiğini belirleyin.
Kaynak IP, cihaz, kullanıcı ve oturum bilgilerini SIEM/EDR üzerinden zenginleştirin.
Aynı zaman aralığındaki kimlik doğrulama, süreç, DNS ve ağ olaylarını ilişkilendirin.
Şüpheli uç noktayı delil bütünlüğünü koruyarak izole edin.
Gerçek kimlik bilgilerinin de ele geçirilmiş olabileceğini değerlendirip gerekli sırları döndürün.
Saldırganın tokena ulaşmadan önce izlediği yolu çıkarın; başlangıç erişimini ve etkilenen kapsamı belirleyin.
Token yerleşiminin neden işe yaradığını veya neden gürültü ürettiğini olay sonrası değerlendirmeye ekleyin.

Başlangıç için 30 günlük plan

Dönem	Hedef	Çıktı
1-5. gün	Kritik saldırı yollarını belirleme	Varlık ve saldırı yolu listesi
6-10. gün	Token türü ve alarm kanalı seçimi	Pilot tasarım
11-15. gün	5-10 tekil token dağıtımı	Kontrollü yerleşim
16-20. gün	AV/DLP/SIEM testleri	Yanlış pozitif ve entegrasyon kaydı
21-25. gün	Purple team doğrulaması	Tespit süresi ve bağlam kalitesi
26-30. gün	Runbook ve sahiplik	Üretim prosedürü, bakım takvimi

İlk pilot için yüzlerce token gerekmez. İyi seçilmiş beş konum, rastgele dağıtılmış yüz token’dan daha değerlidir. Örneğin bir yedek sunucusu klasörü, bir CI/CD çalışma alanı, bir yönetici atlama sunucusu, bir bulut erişim kasası ve bir dahili dosya paylaşımı dengeli bir başlangıç oluşturabilir.

Sonuç

Canarytokens ve honeytoken yaklaşımı, tespit mühendisliğine güçlü bir “negatif varsayım” ekler: Bu varlığa kimsenin dokunmaması gerekir. Dokunulduğunda sinyalin açıklanabilirliği ve önceliği yüksektir. Başarılı bir deception engineering programı; gerçekçi yerleşim, sıfır gerçek yetki, tekil token kullanımı, merkezi envanter, SIEM entegrasyonu ve düzenli test üzerine kurulmalıdır.

Honeytoken tek başına EDR, SIEM, ağ izleme veya kimlik güvenliğinin yerini almaz. Fakat saldırganın keşif, kimlik bilgisi toplama ve yanal hareket adımlarında görünürlük boşluklarını düşük maliyetle kapatabilir. En doğru başlangıç, kritik saldırı yollarını haritalamak ve her yol üzerine ölçülebilir, sahipliği belli bir erken uyarı noktası yerleştirmektir.

Kaynaklar

TR Siber Ekibi Yazar · TRSiber

Kaynak bağlantısı ← Ana sayfaya dön