C$ Gizemi: Güvenlik Uyarılarının Arkasındaki Görünmez Süreçleri Çözmek

4 Haziran 2026

C$ Gizemi: Güvenlik Uyarılarının Arkasındaki Görünmez Süreçleri Çözmek

1. Giriş: Beklenmedik Bir Güvenlik Alarmı

Sıradan bir SOC (Güvenlik Operasyon Merkezi) mesaisinde, ekranınıza düşen tek bir uyarı tüm önceliklerinizi değiştirebilir: “Uç noktadan idari paylaşıma (C)eris\c​imsag˘​landı.”I˙daripaylas\c​ımlar(C, D,ADMIN), bir saldırganın ağda yanal hareket (lateral movement) yapmak için kullandığı en tipik patikalardır. Ancak ilgili kullanıcıyla görüştüğünüzde aldığınız “Ben sadece bir sunum dosyası açmıştım” yanıtı, bir araştırmacı için hikayenin başladığı yerdir.

Bir adli bilişim uzmanı olarak bu noktada “adli şüphecilik” devreye girmelidir. Kullanıcının teknik olarak “hiçbir şey yapmamış” olması, sistemin arka planında hiçbir şeyin dönmediği anlamına gelmez. Görünmez bir SMB (Server Message Block) bağlantısının izini sürmek, sadece bir alarmı kapatmak değil, bir sürecin soyağacındaki karanlık noktaları aydınlatmaktır.

2. Sürpriz Fail: Masum Görünen Bir Sunum Dosyası mı?

Soruşturmalarımızda sıkça karşılaştığımız bir gerçek vardır: Bir ağ trafiği uyarısının arkasında her zaman siyah ekranlı bir terminalde kod yazan bir saldırgan bulunmaz. Kaynak verilerimize göre, bazen masum bir .pptx (PowerPoint) dosyası, içine gömülmüş harici bir sorgu, eski bir bağlantı veya hatalı bir şablon referansı nedeniyle bu kaosu tetikleyebilir.

Bu durum, dosya içeriğinin doğrudan ağ trafiği oluşturduğu “ezber bozan” bir senaryodur. Kullanıcı dosyayı açtığı anda, Office uygulaması arka planda tanımlanmış olan UNC yoluna erişmeye çalışır.

“Soruşturmanın temel amacı, sadece bir SMB erişiminin gerçekleştiğini doğrulamak değil; bu erişimi somut bir sürece, ebeveyn sürece, dosyaya, betiğe, eklentiye veya doküman davranışına geri haritalandırmaktır.”

Bu mantık çerçevesinde, odak noktamızı olaydan (event), o olayı doğuran kök nedene kaydırıyoruz.

3. Gürültüyü Susturmak: Procmon Filtreleme Sanatı

Bir sistemdeki binlerce anlık olay arasından hedefi vurmak için Microsoft Sysinternals Process Monitor (Procmon) vazgeçilmezdir. Ancak bir uzman uyarısı: Procmon çok hızlı veri üretir ve sistem kaynaklarını tüketebilir. Bu riski yönetmek için “Backing Files” modunu kullanarak veriyi doğrudan diske yazmalı (File > Backing Files) ve şu kritik filtreleri uygulamalısınız:

• Path contains \ : Tüm ağ yollarını yakalamak için.
• Path contains C(veyaD): Hedef paylaşıma odaklanmak için.
• Operation is CreateFile / QueryOpen / QueryDirectory: Dosya erişim ve sorgulama girişimlerini yakalamak için.
• Result is not BUFFER OVERFLOW (Exclude): Gereksiz veri birikmesini önlemek ve gürültüyü azaltmak için.

Teknik İpucu: Analiz sırasında süreç ağacının bütünlüğünü korumak için veriyi mutlaka PML formatında kaydedin. Diğer ekiplerle paylaşırken veya raporlarken ise sadece filtrelenmiş olayları CSV olarak dışa aktarın. PML formatı, sürecin tüm “ebeveyn-çocuk” ilişkisini muhafaza eder.

4. Süreç Ağacı: “Ebeveyn” Süreçlerin İzini Sürmek

Adli bilişimde bir sürecin (PID) ismine bakmak yeterli değildir; o sürecin soyağacını (lineage) sorgulamanız gerekir. Eğer C$ paylaşımına giden yol winword.exe üzerinden geçiyorsa, şu soruları sormak zorundayız:

• Parent PID: Word’ü kim başlattı? Bir kullanıcı mı, yoksa bir zamanlanmış görev (Scheduled Task) mi?
• Command Line: Süreç hangi parametrelerle çalıştı? Arka planda bir script mi tetiklendi?
• Image Path: Süreç meşru bir dizinden mi (C:\Program Files\) yoksa kullanıcının yazma yetkisi olan geçici bir klasörden mi (\Temp\) çalışıyor?

Bir sürecin kim tarafından ve hangi komut satırı parametreleriyle hayata getirildiğini anlamak, “iyi” ile “kötü” arasındaki sınırı çizen yegane unsurdur.

5. Karar Anı: Tehdit mi, Yanlış Yapılandırma mı?

Analiz sonucunda elde ettiğiniz verileri şu dört kategoriden birine yerleştirerek aksiyon planınızı oluşturun:

• Beklenen BT İşlemi: Onaylı yedekleme ajanları, EDR araçları veya merkezi yönetim (SCCM/Intune) yazılımlarının meşru faaliyetleri.
• Kullanıcı Kaynaklı Ama Masum: Kullanıcının dış bağlantı içeren meşru bir dosyayı açmasıyla tetiklenen, kötü niyet barındırmayan SMB erişimleri.
• Yanlış Yapılandırma: Artık var olmayan ağ yollarına referans veren scriptler, kısa yollar veya eski şablonlar.
• Şüpheli veya Bilinmeyen (Eskalasyon): Belirsiz ebeveyn-çocuk ilişkileri, kullanıcı dizinlerinden çalışan betikler veya birden fazla hedefe eş zamanlı erişim girişimleri görüldüğünde derhal SOC/IR ekiplerine eskalasyon yapılmalıdır.

6. Kalıcı Çözüm: Sadece Alarmı Kapatmayın, Kaynağı Kurutun

Soruşturma bittiğinde sadece uyarıyı silmek, sorunun yarın tekrar etmesine davetiye çıkarmaktır. Kök nedene göre şu adımları izleyin:

• Ofis Dokümanları: Dosya içindeki gizli dış bağlantıları, gömülü nesneleri veya eski UNC referanslarını temizleyin. Dosyanın temiz bir kopyasını kaydedin ve erişimin kesildiğini doğrulamak için yeniden test edin.
• Script ve Otomasyon: C$ referanslarını, merkezi dosya paylaşım yolları veya yönetilen API’ler ile güncelleyin.
• Yönetim Araçları: Eğer araç meşru ise ve çok fazla gürültü yapıyorsa, sadece doğrulanmış servis hesapları için istisna (allowlisting) kurallarını güncelleyin.

7. Sonuç: Proaktif Savunma ve Savunulabilir Kanıt Paketi

Soruşturmanızı kapattığınızda, elinizde başka bir uzmanın da aynı sonuca varmasını sağlayacak “savunulabilir bir kanıt paketi” bulunmalıdır. Analiz sonucunuzu şu kalıpla ifade edin:

“[Zaman] itibarıyla, [Kullanıcı] olarak çalışan [PID] numaralı [Süreç İsmi], [UNC Yolu] üzerinde [İşlem] gerçekleştirmeye çalışmıştır. Bu süreç, [Ebeveyn Süreç] tarafından başlatılmıştır ve kök neden [Kök Neden] olarak belirlenmiştir.”

Kapanışta, oluşturduğunuz kanıt paketinde şu temel alanların bulunduğundan emin olun:

1. Vaka ID ve Zaman Damgası
2. Kaynak ve Hedef Uç Nokta / Paylaşım Yolu
3. Loglanmış Kullanıcı
4. Procmon Süreç İsmi ve PID
5. Ebeveyn Süreç ve PID
6. Komut Satırı (Command Line) ve İmaj Yolu (Image Path)
7. İşlem ve Sonuç (Örn: CreateFile / ACCESS DENIED)
8. Sınıflandırma ve İyileştirme Sonucu

Bir dahaki sefere sisteminizde açıklanamayan bir ağ bağlantısı gördüğünüzde, sadece sürece mi bakacaksınız yoksa o sürecin “neden” orada olduğunu mu sorgulayacaksınız? Unutmayın, en karmaşık ihlaller genellikle en “masum” görünen süreçlerin arkasına saklanır.