ROOTKIT ÇEKİRDEK SIZINTISI: KERNEL ROOTKIT TESPİT VE TEMİZLEME REHBERİ

======================================================================


Rootkit çekirdek sızıntısı, teknik literatürde ayrı bir saldırı adı değildir. Bu ifade, bir rootkit’in işletim sisteminin çekirdeğine, çekirdek sürücülerine veya daha alt önyükleme katmanlarına yerleşerek sistemin görünürlüğünü ve güvenilirliğini bozmasını anlatmak için kullanılır. Rootkit; başka zararlı bileşenleri, dosyaları, süreçleri veya bağlantıları gizleyebilen bir yazılım ya da yetenek kümesidir. Kernel (çekirdek) ise bellek, süreçler, donanım erişimi ve yetkiler üzerinde temel denetimi sağlar. Rootkit bu ayrıcalıklı katmanı etkilediğinde antivirüs ve yönetim araçlarının gördüğü bilgiler eksik veya yanıltıcı olabilir. Bu nedenle tek bir belirti ya da temiz tarama sonucu kesin karar vermek için yeterli değildir.


Bu rehber; rootkit ile kernel arasındaki ilişkiyi, Windows ve Linux sistemlerde savunma odaklı tespit yöntemlerini, güvenli olay müdahalesini ve korunma kontrollerini açıklar. İçerik zararlı yazılım geliştirme, gizlenme veya güvenlik kontrolü atlatma öğretmez.


NOT / UYARI:

Terminoloji notu: “Çekirdek sızıntısı”; veri sızıntısı veya bellek sızıntısı (memory leak) ile aynı kavram değildir. Bu makaledeki teknik karşılığı kernel düzeyinde rootkit yerleşimi veya çekirdek bütünlüğünün ihlalidir.


HIZLI CEVAPLAR

==============


Soru | Kısa cevap

--- | ---

Rootkit nedir? | Başka zararlı faaliyetlerin ve sistem bileşenlerinin görünürlüğünü gizleyebilen yazılım veya yetenek kümesidir.

Kernel rootkit neden tehlikelidir? | İşletim sisteminin ayrıcalıklı katmanında çalışarak güvenlik araçlarının aldığı bilgileri etkileyebilir.

Yavaşlama rootkit kanıtı mıdır? | Hayır. Yavaşlama; donanım, sürücü, güncelleme veya uygulama sorunlarından da kaynaklanabilir.

Antivirüs temiz derse sistem kesin temiz midir? | Hayır. Negatif sonuç yalnızca kullanılan aracın görünürlüğü ve tarama kapsamı içinde anlamlıdır.

Format rootkit’i siler mi? | İşletim sistemi diskindeki kalıcılığı giderebilir; boot veya firmware katmanı ayrıca incelenmelidir.


İÇİNDEKİLER

===========


1. Rootkit nedir?

2. Kernel nedir?

3. Rootkit kernel’e nasıl yerleşir?

4. Rootkit türleri

5. Sisteme bulaşırsa ne olur?

6. Belirtileri nelerdir?

7. Nasıl tespit edilir?

8. Windows tespit adımları

9. Linux tespit adımları

10. Nasıl temizlenir?

11. Korunma yolları

12. Yaygın yanlışlar

13. Editoryal yorum

14. Sık sorulan sorular

15. Sonuç ve güvenli karar özeti

16. İlgili BilişimTürk içerikleri

17. Kaynakça ve yöntem


ROOTKIT NEDİR?

==============


Kısa cevap: Rootkit, bir saldırganın veya başka bir zararlı yazılımın sistemdeki varlığını gizlemek için kullanılan yazılım ve teknikler bütünüdür.


NIST (https://csrc.nist.gov/glossary/term/rootkit), rootkit’i sistemin normal işlevini kötü niyetli ve gizli biçimde değiştiren dosya ya da araç koleksiyonu olarak tanımlar. MITRE ATT&CK T1014 (https://attack.mitre.org/techniques/T1014/) ise rootkit’lerin programları, dosyaları, ağ bağlantılarını, hizmetleri, sürücüleri ve başka sistem bileşenlerini gizleyebileceğini belirtir.


Rootkit’i yalnızca “veri çalan bir virüs” olarak düşünmek doğru değildir. Veri çalma, uzaktan erişim veya parola yakalama işini başka bir zararlı bileşen yapabilir; rootkit bu faaliyetin süreç listelerinde, dosya görünümünde, ağ bağlantılarında veya güvenlik araçlarında fark edilmesini zorlaştırır. Zararlı yazılım sınıfları arasındaki farklar için BilişimTürk’ün bilgisayar virüsleri rehberi (https://bilisimturk.com/kategori/guvenlik/bilgisayar-virusleri-nedir-tarihcesi-kuresel-salginlar-yeni-nesil-virusler-ve-cezalar) ve Trojan tehdit istihbaratı raporu (https://bilisimturk.com/kategori/guvenlik/bilisim-tehdit-istihbarati-raporu-trojan-truva-ati-zararli-yazilim-sinifi) tamamlayıcı bilgi sunar.


Rootkit’in etkileyebildiği alan | Olası görünürlük sorunu

--- | ---

Dosyalar ve dizinler | Belirli dosyaların normal araçlarda görünmemesi

Süreçler ve hizmetler | Zararlı sürecin veya hizmetin listelerden saklanması

Ağ bağlantıları | Bağlantı ya da dinleme portunun eksik raporlanması

Sürücüler ve kernel modülleri | Yetkisiz ayrıcalıklı bileşenin gizlenmesi

Güvenlik telemetrisi | Logların, uyarıların veya tarama sonuçlarının bozulması


KERNEL (ÇEKİRDEK) NEDİR?

========================


Kısa cevap: Kernel; bellek, süreçler, donanım, giriş/çıkış ve güvenlik denetimleri gibi temel işletim sistemi işlevlerini yöneten ayrıcalıklı çekirdektir.


Windows’ta uygulamalar çoğunlukla kullanıcı modunda çalışır. İşletim sisteminin temel bileşenleri ve birçok sürücü ise kernel modunda çalışır. Microsoft’un kullanıcı modu ve kernel modu açıklamasına (https://learn.microsoft.com/windows-hardware/drivers/gettingstarted/user-mode-and-kernel-mode) göre kullanıcı süreçleri yalıtılmış adres alanlarına sahiptir; kernel modu kodu işletim sistemiyle ortak ve ayrıcalıklı alanda çalışır.


Bu yüksek yetki düzeyi kernel sürücülerinin donanımla ve korunan işletim sistemi verileriyle çalışmasını sağlar. Aynı nedenle hatalı bir kernel sürücüsü tüm sistemi çökertebilir; kötü niyetli kernel kodu ise kullanıcı modundaki güvenlik aracının aldığı sonuçları etkileyebilir.


• Driver: Windows’ta donanım veya çekirdek işlevleriyle iletişim kuran sürücü bileşenidir.

• Linux Kernel Module: Çalışan Linux kernel’ine gerektiğinde işlev ekleyen yüklenebilir modüldür.

• Ring 0: x86 mimarisindeki en ayrıcalıklı çalışma halkası için kullanılan yaygın ifadedir; bütün işlemci mimarilerinin aynı adlandırmayı kullandığı varsayılmamalıdır.

• Kernel bütünlüğü: Çekirdek kodu ve kritik yapıların yalnızca yetkili, doğrulanmış değişikliklerle korunmasıdır.


ROOTKIT KERNEL’E NASIL YERLEŞİR?

================================


Kısa cevap: Kernel rootkit genellikle daha önce elde edilmiş yönetici/root erişimi, bir kernel açığı, yetkisiz sürücü/modül yükleme veya önyükleme zincirindeki zayıflık üzerinden ayrıcalıklı katmana ulaşır.


Rootkit her zaman ilk bulaşma aracı değildir. Kimlik avı, ele geçirilmiş hesap, güvenlik açığı, kötü niyetli kurulum paketi veya tedarik zinciri sorunu ilk erişimi sağlayabilir. Ardından saldırgan çekirdek düzeyine geçmeye çalışabilir. Savunma ekiplerinin izlemesi gereken başlıca yollar şunlardır:


1. Yetkisiz sürücü veya kernel modülü: İmza ve yükleme politikaları zayıfsa ayrıcalıklı kod çekirdeğe alınabilir.

2. Savunmasız imzalı sürücü: Bir sürücünün imzalı olması güvenlik açığı içermediği anlamına gelmez. Microsoft’un savunmasız sürücü engelleme rehberi (https://learn.microsoft.com/windows/security/application-security/application-control/app-control-for-business/design/microsoft-recommended-driver-block-rules) bu riski ayrı bir kontrol olarak ele alır.

3. Kernel güvenlik açığı: Bellek güvenliği veya yetki denetimi hatası ayrıcalık kazanmak için kötüye kullanılabilir.

4. Önyükleme zinciri: Bootkit, işletim sisteminden önce çalışan bileşenleri hedefler.

5. Firmware/UEFI: Platform firmware’i etkilenirse işletim sistemi dışındaki bir kalıcılık alanı oluşabilir.


Yerleştikten sonra bir rootkit; sistem çağrısı sonuçlarına müdahale, kernel nesnelerini değiştirme, dosya veya süreç görünümünü filtreleme, ağ bağlantılarını gizleme ve güvenlik telemetrisini bozma gibi davranışlar gösterebilir. Bu davranışların teknik ayrıntıları savunma amacı için gerekli seviyede tutulmalıdır.


NOT / UYARI:

Teknik ayrım: Memory injection, DLL injection, Trojan veya uzaktan erişim aracı bulunması tek başına kernel rootkit bulunduğunu göstermez. Teknikler arasındaki ilişki ancak log, sürücü/modül, bellek, boot ve ağ kanıtları birlikte incelendiğinde kurulabilir.


ROOTKIT TÜRLERİ VE KALICILIK KATMANLARI

=======================================


Rootkit’in bulunduğu katman, tespit yöntemini ve “format atmak yeterli mi?” sorusunun yanıtını değiştirir.


Tür | Katman | Yeniden kurulum etkisi | Temel kurtarma yaklaşımı

--- | --- | --- | ---

Kullanıcı modu rootkit | Uygulama ve kitaplıklar | Etkilenen disk güvenilir biçimde yeniden oluşturulursa genellikle kaldırılır. | Temiz imaj, yama ve hesap güvenliği

Kernel modu rootkit | Çekirdek, sürücü veya modül | Kalıcılık yalnızca OS diskindeyse temiz kurulum çoğunlukla etkilidir. | Çevrimdışı inceleme ve bilinen temiz imaj

Bootkit | Bootloader ve önyükleme | Yalnızca sistem bölümünü biçimlendirmek yeterli olmayabilir. | Disk bölümleme ve boot zincirini güvenilir medyayla yeniden oluşturma

Firmware/UEFI rootkit | Anakart veya aygıt firmware’i | İşletim sistemi kurulumu firmware’i değiştirmez. | OEM onaylı firmware kurtarma veya gerektiğinde donanım değerlendirmesi

Hiper yönetici düzeyi | İşletim sisteminin altı | Mimariye ve kalıcılık noktasına bağlıdır. | Platform ve sanallaştırma katmanını ayrı inceleme


MITRE ATT&CK (https://attack.mitre.org/techniques/T1014/), rootkit işlevlerinin kullanıcı veya kernel seviyesinde; hiper yönetici ya da sistem firmware’i gibi daha alt katmanlarda bulunabileceğini belirtir. Microsoft’un UEFI tarama belgesi (https://learn.microsoft.com/defender-endpoint/uefi-scanning-in-defender-for-endpoint) de firmware tabanlı rootkit riskini işletim sistemi katmanından ayrı ele alır.


ROOTKIT SİSTEME BULAŞIRSA NE OLUR?

==================================


Kısa cevap: Sistem çıktılarının güvenilirliği azalabilir; başka zararlı faaliyetler gizlenebilir; hesaplar, dosyalar ve ağ erişimi risk altına girebilir.


• Gizlilik: Kimlik bilgileri, oturum belirteçleri veya hassas dosyalar başka bir zararlı bileşen tarafından ele geçirilebilir.

• Bütünlük: Dosyalar, sürücüler, loglar ve güvenlik ayarları değiştirilebilir.

• Kullanılabilirlik: Sistem çökmesi, kernel panic, mavi ekran, önyükleme sorunu veya performans kaybı oluşabilir.

• Güven kaybı: Sistem kendi durumunu doğru raporlayamayabilir; tek bir “temiz” tarama yeterli güvence sağlamaz.

• Yanal hareket: Kurumsal ortamda ele geçirilen hesap veya yönetim kanalı başka sistemlere erişimde kullanılabilir.


Rootkit varlığı otomatik olarak bütün verilerin çalındığı anlamına gelmez. Ancak kernel veya firmware düzeyinde doğrulanmış bir ihlal, kapsamı tam bilinmeyen yüksek etkili bir olay olarak ele alınmalıdır.


ROOTKIT BELİRTİLERİ NELERDİR?

=============================


Kısa cevap: Kesin bir belirti listesi yoktur. En anlamlı sinyaller; yetkisiz kernel sürücüsü/modülü, boot değişikliği, güvenlik kontrollerinin açıklanamayan biçimde kapanması ve farklı veri kaynaklarının birbiriyle uyuşmamasıdır.


Gözlem | Kanıt gücü | Alternatif açıklama | Doğrulama

--- | --- | --- | ---

Beklenmeyen mavi ekran veya kernel panic | Düşük | Hatalı sürücü, RAM veya disk | Çökme dökümü ve donanım testi

Güvenlik aracının sürekli kapanması | Orta | Politika, lisans veya başka antivirüs | Merkezi konsol ve olay günlükleri

Hostta görünmeyen süreçle eşleşen ağ trafiği | Orta–yüksek | Telemetri gecikmesi, VM veya konteyner | Ağ sensörü ile host görünümünü karşılaştırma

Yetkisiz kernel sürücüsü veya modülü | Yüksek | Meşru üçüncü taraf bileşeni | İmza, hash, tedarikçi ve değişiklik kaydı

Beklenmeyen boot veya Secure Boot değişikliği | Yüksek | BIOS güncellemesi veya yönetici işlemi | Firmware değişiklik kaydı ve güvenilir referans

Çevrimiçi ve çevrimdışı dosya görünümünün tutmaması | Yüksek | Dosya sistemi hatası veya anlık değişiklik | Bilinen temiz ortamdan ikinci inceleme


NOT / UYARI:

Acil durum eşiği: Kurumsal cihazda yetkisiz kernel sürücüsü, boot bileşeni değişikliği veya firmware bütünlüğü bulgusu varsa cihazı normal iş için kullanmayı bırakın ve olay müdahale ekibine bildirin. Kişisel cihazda hassas hesaplara bu cihazdan giriş yapmayın; parolaları güvenilir başka bir cihazdan değiştirin.


ROOTKIT NASIL TESPİT EDİLİR?

============================


Kısa cevap: Rootkit tespiti; host telemetrisi, merkezi loglar, ağ görünümü, imza/baseline kontrolü ve çevrimdışı incelemenin birlikte değerlendirilmesini gerektirir.


İncelenen kernel ele geçirilmişse o kernel üzerinden çalışan araçlar eksik veya yanıltılmış bilgi alabilir. Bu nedenle güçlü bir inceleme tek bir antivirüs sonucuna dayanmaz.


1. Koruma durumunu kaydedin: Antivirüs/EDR, Secure Boot, kernel kod bütünlüğü ve imza politikaları çalışıyor mu?

2. Host telemetrisini inceleyin: Sürücü/modül yükleme, kernel uyarısı ve boot değişikliği var mı?

3. Haricî görünümle karşılaştırın: Ağ sensörü, SIEM veya EDR yönetim konsolu host çıktısıyla uyuşuyor mu?

4. Çevrimdışı doğrulayın: Normal işletim sistemi çalışmıyorken yapılan tarama ne gösteriyor?

5. Olay zaman çizelgesi kurun: Yeni sürücü, koruma değişikliği ve ağ faaliyeti aynı zaman aralığında mı?

6. Kanıtı koruyun: Kurumsal olayda aceleyle dosya silmek veya sistemi tekrar tekrar başlatmak geçici kanıtları yok edebilir.


MITRE ATT&CK T1014 tespit stratejisi (https://attack.mitre.org/techniques/T1014/); anormal kernel sürücüsü/modül yüklenmesi, gizlenmiş hizmetler ve boot bileşeni değişikliklerinin birlikte değerlendirilmesini önerir. Bu sinyaller tek başına teşhis değil, araştırılması gereken hipotezlerdir.


WINDOWS’TA ROOTKIT TESPİTİ

==========================


Kısa cevap: Önce Defender ve Secure Boot durumunu kaydedin; sürücü/boot envanterini alın; merkezi loglarla karşılaştırın; kanıt toplama planından sonra gerekirse Microsoft Defender Offline kullanın.


NOT / UYARI:

Önemli: Aşağıdaki salt okunur komutlar rootkit’i tek başına doğrulamaz. Çalışan Windows kernel’i ele geçirilmişse çıktılar güvenilmez olabilir. Kurumsal veya hukuki önemi olan olayda kurumun olay müdahale prosedürü önceliklidir.


1. Microsoft Defender durumunu kontrol edin

-------------------------------------------


KOD / KOMUT:

Get-MpComputerStatus |

    Select-Object AMRunningMode,

                  AntivirusEnabled,

                  RealTimeProtectionEnabled,

                  BehaviorMonitorEnabled,

                  IsTamperProtected,

                  DefenderSignaturesOutOfDate,

                  AntivirusSignatureLastUpdated


Bu sorgu koruma bileşenlerinin durumunu gösterir; ayar değiştirmez. False değeri tek başına rootkit kanıtı değildir. Kurum politikası, üçüncü taraf antivirüs veya uyumluluk sorunu da aynı sonucu doğurabilir. Microsoft, Tamper Protection ve gerçek zamanlı koruma durumunun Get-MpComputerStatus ile denetlenebileceğini (https://learn.microsoft.com/defender-endpoint/prevent-changes-to-security-settings-with-tamper-protection) belgeler.


2. Secure Boot durumunu görüntüleyin

------------------------------------


KOD / KOMUT:

Confirm-SecureBootUEFI


Yönetici PowerShell’de çalışan bu komut, desteklenen UEFI sisteminde Secure Boot etkinse True, kapalıysa False döndürür. “Desteklenmiyor” veya erişim hatası rootkit kanıtı değildir. Ayrıntılar Microsoft komut belgesinde (https://learn.microsoft.com/powershell/module/secureboot/confirm-securebootuefi) bulunur.


3. Sürücü ve boot envanterini alın

----------------------------------


KOD / KOMUT:

driverquery /si

driverquery /v /fo csv > "%USERPROFILE%\Desktop\driver-inventory.csv"

bcdedit /enum active /v


driverquery, kurulu sürücülerin özelliklerini ve imza görünümünü listeler. bcdedit /enum yalnızca etkin boot girdilerini görüntüler; bu makale boot ayarı değiştiren /set veya /delete komutları vermez. Envanter; kurumun bilinen temiz referansı, sürücü üreticisi, hash, kurulum zamanı ve değişiklik kaydıyla karşılaştırılmalıdır.


4. Microsoft Defender Offline taramasını planlı kullanın

--------------------------------------------------------


Microsoft Defender Offline (https://learn.microsoft.com/defender-endpoint/microsoft-defender-offline), normal Windows kernel’inin dışında güvenilir bir ortamdan tarama yapar. Bu yöntem shell veya boot katmanına müdahale eden bazı tehditleri incelemeye yardımcı olabilir.


KOD / KOMUT:

Start-MpWDOScan


NOT / UYARI:

Uyarı: Bu komut cihazı yeniden başlatır. Açık çalışmaları kaydedin. BitLocker etkinse Microsoft yönergesine göre korumayı geçici askıya alma sürecini değerlendirin ve kurtarma anahtarına erişimi doğrulayın. Kurumsal olayda yeniden başlatma RAM ve bağlantı gibi geçici kanıtları yok edebileceği için önce olay müdahale ekibinden onay alın.


Microsoft belgesine göre özellik x64 Windows 11 ve x86/x64 Windows 10 istemcilerinde kullanılabilir; Windows ARM ve Windows Server SKU’ları için geçerli değildir. WinRE etkin ve Defender birincil antivirüs olmalıdır.


Windows bulgusu | Tek başına anlamı | Sonraki adım

--- | --- | ---

Defender kapalı | Politika, üçüncü taraf AV veya müdahale olabilir. | Merkezi yönetim ve olay kaydını karşılaştırın.

Secure Boot kapalı | Boot koruması azalmıştır; rootkit kanıtı değildir. | Gereksinim ve değişiklik geçmişini doğrulayın.

Bilinmeyen imzalı sürücü | Meşru, savunmasız veya yanlış dağıtılmış olabilir. | Yayıncı, hash, sürüm ve güvenlik bültenini inceleyin.

İmzasız çalışan sürücü | Yüksek önemde güvenlik anomalisidir. | İzolasyon ve bağımsız inceleme yapın.

Offline tarama temiz | Taramanın bildiği tehditler bulunmamıştır. | Diğer kanıtlar sürüyorsa olayı kapatmayın.


LINUX’TA ROOTKIT TESPİTİ

========================


Kısa cevap: Kernel sürümü, yüklenen modüller, taint değeri, imza durumu, Secure Boot/lockdown ve kernel logları birlikte incelenmeli; sonuçlar dağıtım paketleri ve çevrimdışı kanıtla karşılaştırılmalıdır.


Linux dağıtımları Secure Boot, init sistemi, kernel yapılandırması ve modül imza politikası bakımından farklıdır. Aşağıdaki komutlar salt okunur envanter içindir:


KOD / KOMUT:

uname -a

lsmod

cat /proc/modules

cat /proc/sys/kernel/tainted

journalctl -k -b | grep -Ei 'module|signature|taint|lockdown'

mokutil --sb-state

cat /sys/kernel/security/lockdown 2>/dev/null

cat /proc/sys/kernel/modules_disabled

modinfo -F signer [MODÜL_ADI]


mokutil, lockdown dosyası veya imza alanı her dağıtım ve kernel yapılandırmasında bulunmayabilir. Bazı loglar root yetkisi isteyebilir. Komutların ayar değiştirmemesi, üretilen çıktının otomatik olarak güvenilir olduğu anlamına gelmez.


Linux Kernel’in modül imzalama belgesine (https://www.kernel.org/doc/html/next/admin-guide/module-signing.html) göre imza doğrulaması kernel içinde yapılır. CONFIG_MODULE_SIG_FORCE veya module.sig_enforce=1 etkinse yalnızca kernel’in güvendiği anahtarla geçerli biçimde imzalanmış modüller yüklenir. Kernel self-protection rehberi (https://docs.kernel.org/security/self-protection.html), yüksek güven gereken sistemlerde modül yüklemeyi sınırlandırma veya zorunlu imza kullanımını ele alır.


/proc/sys/kernel/tainted değerinin sıfırdan farklı olması otomatik rootkit kanıtı değildir. Resmî tainted-kernel belgesi (https://docs.kernel.org/admin-guide/tainted-kernels.html); özel, ağaç dışı veya imzasız modül, kernel uyarısı ve donanım hatası gibi birçok neden tanımlar.


Daha güçlü Linux doğrulaması

----------------------------


• lsmod ve /proc çıktısını tek başına temiz sistem kanıtı saymayın.

• Modül dosyalarını dağıtımın imzalı paketleri ve bilinen temiz hash’leriyle karşılaştırın.

• Kernel, initramfs, bootloader ve UEFI Secure Boot zincirini birlikte inceleyin.

• Merkezi audit/log sunucusu ve ağ telemetrisiyle host çıktısı arasındaki farkları araştırın.

• Kanıt güçlü ise bilinen temiz medyadan salt okunur disk imajı ve çevrimdışı bütünlük kontrolü yapın.


ROOTKIT NASIL TEMİZLENİR?

=========================


Kısa cevap: Doğrulanmış kernel rootkit olayında yalnızca şüpheli dosyayı silmek yerine cihaz izole edilmeli, kanıt ve kapsam korunmalı, giriş yolu kapatılmalı ve sistem bilinen temiz kaynaktan yeniden kurulmalıdır.


NIST SP 800-61 Rev. 3 (https://csrc.nist.gov/pubs/sp/800/61/r3/final); bütün etkilenen host ve hizmetlerin belirlenmesini, kalıcılık ve giriş noktalarının kaldırılmasını, temiz yedekten geri dönüşü, yamalamayı ve hesap güvenliğini birlikte ele alır. Kapsamı bilinmeyen ileri olaylarda donanım değişimine kadar gidilebileceğini de belirtir.


1. İzole edin: Şüpheli cihazı ağdan ayırın. Kurumsal ortamda cihazı kapatmadan önce olay müdahale ekibiyle görüşün.

2. Kanıtı koruyun: Uyarıları, olay zamanını, merkezi logları ve mümkünse bellek/disk imajını kaydedin.

3. Kapsamı belirleyin: Aynı hesap, sürücü, hash veya ağ göstergesi başka sistemlerde var mı araştırın.

4. Hesapları koruyun: Parola ve oturumları yalnızca güvenilir başka bir cihazdan yenileyin.

5. Giriş yolunu kapatın: Güvenlik açığını yamalayın, riskli sürücüyü güncelleyin/kaldırın ve kötüye kullanılan hesabı kapatın.

6. Temiz kaynaktan kurtarın: Kernel veya boot ihlali doğrulanmışsa onaylı üretici medyası ya da kurumsal altın imaj kullanın.

7. Firmware’i ayrı inceleyin: UEFI/aygıt firmware’i için OEM’in doğrulanmış kurtarma veya reflash sürecini izleyin.

8. Temiz yedeği geri yükleyin: Yalnızca olaydan önce oluşturulmuş ve zararlı içermediği doğrulanmış veriyi kullanın.

9. Yoğun izleme yapın: Yeniden giriş, yanal hareket ve aynı kalıcılık belirtisi için sistemi izleyin.


Doğrulanan katman | Önerilen kurtarma

--- | ---

Kullanıcı modu zararlısı, kernel bulgusu yok | Ürün yönergesine göre karantina/temizleme ve sonrasında doğrulama

Yetkisiz kernel sürücüsü veya modülü | İzolasyon, kapsamlandırma ve temiz yeniden imajlama

Bootkit | Güvenilir medyayla disk bölümleme, boot ve OS yeniden kurulumu

Firmware/UEFI | OEM kurtarma/reflash; güvenilir kurtarma yoksa donanım değerlendirmesi

Kurumsal yanal hareket | Filo çapında avcılık, kimlik sıfırlama ve koordineli eradikasyon


ROOTKIT’LERDEN KORUNMA YOLLARI

==============================


Kısa cevap: Güncel sistem, en az ayrıcalık, güvenli önyükleme, kernel kod bütünlüğü, zorunlu sürücü/modül imzası, merkezi telemetri ve test edilmiş temiz kurtarma planı birlikte kullanılmalıdır.


Windows için

------------


• Windows, uygulamalar, sürücüler ve firmware güncel tutulmalıdır.

• Sürücüler yalnızca üretici, Windows Update veya kurumun onaylı kanalından alınmalıdır.

• Secure Boot ve Trusted Boot (https://learn.microsoft.com/windows/security/operating-system-security/system-security/trusted-boot) desteklenen cihazlarda etkin tutulmalıdır.

• Memory Integrity/HVCI (https://learn.microsoft.com/windows-hardware/drivers/bringup/device-guard-and-credential-guard) sürücü uyumluluğu test edildikten sonra kullanılmalıdır.

• Savunmasız sürücü engelleme listesi ve uygulama allowlist’i kurumsal testten sonra uygulanmalıdır.

• Tamper Protection, davranış izleme ve merkezi EDR uyarıları açık tutulmalıdır.

• Günlük işler standart kullanıcıyla; yönetim işlemleri ayrı, MFA korumalı hesapla yapılmalıdır.


Linux için

----------


• Desteklenen kernel ve dağıtım sürümü kullanılmalıdır.

• Secure Boot, dağıtımın kernel ve modül doğrulama süreciyle birlikte yapılandırılmalıdır.

• Kernel modülleri güvenilen anahtarla imzalanmalı; uygun sistemlerde zorunlu doğrulama kullanılmalıdır.

• Kernel lockdown, IMA/EVM veya dağıtımın sunduğu bütünlük politikaları risk modeline göre değerlendirilmelidir.

• Modül imzalama özel anahtarları üretim hostunda tutulmamalıdır.

• Kernel ve boot logları merkezi ve değiştirilmeye dayanıklı bir sisteme aktarılmalıdır.


Platform ve kurum için

----------------------


• Firmware yalnızca OEM’in doğrulanmış güncelleme mekanizmasıyla güncellenmelidir.

• NIST SP 800-193’ün koruma–tespit–kurtarma yaklaşımı platform seçiminde değerlendirilmelidir.

• MFA, ağ segmentasyonu, uygulama denetimi ve ayrıcalıklı erişim yönetimi birlikte kullanılmalıdır.

• Çevrimdışı/değiştirilemez yedekler düzenli geri yükleme testine tabi tutulmalıdır.

• Olay müdahale planı kernel, boot ve firmware ihlali senaryosunu içermelidir.


Kontrol | Faydası | Sınırı

--- | --- | ---

Yama ve desteklenen sürüm | Bilinen açıkların kullanımını azaltır. | Sıfır gün ve yanlış yapılandırmayı tek başına çözmez.

Secure/Trusted Boot | Yetkisiz boot bileşenlerini sınırlar. | Kernel yüklendikten sonraki bütün saldırıları engellemez.

HVCI/Memory Integrity | Kernel kod bütünlüğünü güçlendirir. | Donanım ve sürücü uyumluluğu gerekir.

Modül/sürücü imzası | Yetkisiz kernel kodu yüklemeyi zorlaştırır. | İmzalı fakat savunmasız sürücü riskini bitirmez.

Merkezi EDR/SIEM | Host dışı görünürlük ve korelasyon sağlar. | Sensör ve log boşlukları olabilir.

Temiz imaj ve yedek | Güvenilir kurtarma yolu sunar. | Enfekte veya test edilmemiş yedek başarısız olabilir.


YAYGIN YANLIŞLAR

================


Yanlış inanış | Doğru değerlendirme

--- | ---

“Bilgisayar yavaşsa rootkit vardır.” | Yavaşlık çok düşük özgüllüklü bir belirtidir.

“Antivirüs temiz dedi, kesin temiz.” | Negatif sonuç yalnızca aracın görünürlüğü ve kapsamı içinde anlamlıdır.

“Format bütün rootkit’leri siler.” | Boot ve firmware kalıcılığı ayrı kurtarma gerektirebilir.

“Secure Boot açıksa rootkit mümkün değildir.” | Secure Boot önemli bir katmandır; tek başına bütün kernel saldırılarını engellemez.

“İmzalı sürücü mutlaka güvenlidir.” | İmza yayıncı ve bütünlük hakkında bilgi verir; güvenlik açığı olmadığını garanti etmez.

“TPM rootkit’i otomatik temizler.” | TPM ölçüm ve anahtar korumasında rol oynar; antivirüs değildir.

“Bulunan her şüpheli sürücüyü hemen silmeliyim.” | Yanlış pozitif sistemin açılmamasına ve kanıt kaybına yol açabilir.


EDİTORYAL YORUM

===============


Rootkit haberleri çoğu zaman “görünmez ve silinemez tehdit” diliyle sunuluyor. Bu yaklaşım korkuyu artırırken doğru müdahaleyi zorlaştırabiliyor. Doğrulanmış teknik gerçek şudur: kernel veya firmware katmanına yerleşen zararlı, işletim sisteminin kendi görünümüne duyulan güveni azaltabilir. Ancak yavaşlama, çökme ya da tek bir bilinmeyen sürücü rootkit teşhisi değildir. Kullanıcı açısından en dengeli yol; şüpheli cihazı hassas işlemlerde kullanmamak, bulguları bağımsız veri kaynaklarıyla doğrulamak ve yüksek güvenli kernel/boot bulgusunda bilinen temiz kaynaktan yeniden kurulum yapmaktır. Firmware şüphesi nadirdir ve üretici desteği ya da uzman adli inceleme olmadan kesinleştirilmemelidir.


— TimurKaan — BilişimTürk Araştırma Ekibi


ROOTKIT HAKKINDA SIK SORULAN SORULAR

====================================


1. Rootkit virüs müdür?

-----------------------


Rootkit, klasik anlamda kendini çoğaltan bir virüs olmak zorunda değildir. Başka zararlıların, saldırgan erişiminin veya kalıcılık bileşenlerinin varlığını gizleyen bir araç ve teknikler kümesidir; günlük dilde zararlı yazılım ailesi içinde anılır.


2. “Rootkit çekirdek sızıntısı” ne demektir?

--------------------------------------------


Yerleşik bir teknik terim değildir. Bu rehberde kernel düzeyinde rootkit yerleşimi veya çekirdek bütünlüğünün ihlali anlamında kullanılır. Bellek sızıntısı (memory leak) ve veri sızıntısıyla karıştırılmamalıdır.


3. Kernel rootkit nasıl anlaşılır?

----------------------------------


Tek bir belirtiyle anlaşılmaz. Yetkisiz kernel sürücüsü veya modülü, boot değişikliği, koruma bileşeninin devre dışı kalması, host ile ağ/EDR görünümü arasındaki farklar ve çevrimdışı bulgular birlikte değerlendirilmelidir.


4. Rootkit bilgisayarı yavaşlatır mı?

-------------------------------------


Yavaşlatabilir; ancak yavaşlık çok yaygın ve özgül olmayan bir belirtidir. Donanım, disk, güncelleme, meşru uygulama veya hatalı sürücü olasılıkları da araştırılmalıdır.


5. Windows Defender rootkit bulabilir mi?

-----------------------------------------


Microsoft Defender Antivirus bilinen tehditleri ve şüpheli davranışları tespit edebilir. Microsoft Defender Offline, normal Windows çekirdeğinin dışından tarama yaparak bazı kalıcı tehditleri yakalama olasılığını artırır. Buna rağmen tek bir temiz sonuç bütün kernel, boot veya firmware olasılıklarını dışlamaz.


6. Microsoft Defender Offline ne zaman kullanılmalı?

----------------------------------------------------


Kalıcı zararlı veya rootkit şüphesinde ve temizliğin çevrimdışı doğrulanması gerektiğinde kullanılabilir. Araç cihazı yeniden başlatır; kurumsal olayda geçici kanıt kaybını önlemek için önce olay müdahale ekibine danışılmalıdır.


7. Rootkit format atınca silinir mi?

------------------------------------


Kalıcılık yalnızca işletim sistemi diskindeyse bütün ilgili bölümleri güvenilir medyayla yeniden oluşturan temiz kurulum etkili olabilir. Bootkit, UEFI veya aygıt firmware’i etkilenmişse yalnızca Windows ya da Linux bölümünü biçimlendirmek yeterli olmayabilir.


8. BIOS veya UEFI rootkit nedir?

--------------------------------


İşletim sistemi yerine veya ona ek olarak platform firmware’inde kalıcılık sağlayan rootkit türüdür. İnceleme ve kurtarma işlemi cihaz modeline ve üreticiye özel olabilir. Her açılış sorunu firmware rootkit kanıtı değildir.


9. Secure Boot rootkit’i engeller mi?

-------------------------------------


Secure Boot, yalnızca güvenilen önyükleme bileşenlerinin yüklenmesini sağlayarak bootkit ve bazı önyükleme saldırılarına karşı riski azaltır. Kernel yüklendikten sonraki bütün açıkları veya savunmasız imzalı sürücüleri tek başına engellemez.


10. TPM rootkit’i temizler mi?

------------------------------


Hayır. TPM; ölçüm, anahtar koruma ve doğrulama zincirlerinde rol alabilir fakat kendi başına zararlı tarayıp silen bir güvenlik ürünü değildir.


11. EDR rootkit’i tespit edebilir mi?

-------------------------------------


EDR; sürücü veya modül yükleme, güvenlik ayarı değişikliği, şüpheli davranış ve merkezi telemetri üzerinden güçlü sinyaller sağlayabilir. Kernel tarafından yanıltılma veya sensör görünürlüğü sınırı nedeniyle EDR bulgusu başka kanıtlarla doğrulanmalıdır.


12. Linux sistemlerde rootkit olur mu?

--------------------------------------


Evet. MITRE ATT&CK T1014; Windows, Linux ve macOS platformlarını kapsar. Linux’ta kullanıcı modu bileşenleri, kernel modülleri, önyükleme zinciri ve firmware katmanları ayrı ayrı incelenmelidir.


13. lsmod veya /proc/modules temiz görünüyorsa sistem temiz midir?

------------------------------------------------------------------


Hayır. Bu çıktılar çalışan kernel tarafından sunulur ve gelişmiş bir tehdit görünümü etkileyebilir. Dağıtım paketleri, imzalar, merkezi loglar, ağ telemetrisi ve çevrimdışı incelemeyle karşılaştırma gerekir.


14. İmzasız kernel modülü kesin rootkit midir?

----------------------------------------------


Hayır; fakat araştırılması gereken bir güvenlik anomalisidir. Özel geliştirme, eski donanım veya yanlış yapılandırma söz konusu olabilir. Modülün kaynağı, hash’i, imza politikası ve değişiklik kaydı incelenmelidir.


15. İmzalı bir sürücü zararlı veya savunmasız olabilir mi?

----------------------------------------------------------


Evet. Dijital imza, yayıncı ve dosya bütünlüğü hakkında kanıt sunar; sürücünün güvenlik açığı içermediğini garanti etmez. Bu nedenle savunmasız sürücü engelleme listeleri ve uygulama denetimi önemlidir.


16. Rootkit şüphesinde interneti kesmeli miyim?

-----------------------------------------------


Çoğu durumda ağ izolasyonu olası komuta-kontrol bağlantısını ve yanal hareketi sınırlar. Kurumsal cihazı kapatmadan önce olay müdahale ekibiyle görüşün; kapatma bellek ve aktif bağlantı kanıtlarını kaybettirebilir.


17. Parolaları şüpheli cihazdan değiştirmek güvenli midir?

----------------------------------------------------------


Hayır. Şüpheli cihaz girişleri izliyor olabilir. Parola değişikliği, oturum kapatma ve MFA yenileme işlemleri güncel ve güvenilir başka bir cihazdan yapılmalıdır.


18. Ücretli bir rootkit temizleme aracı kesin çözüm sağlar mı?

--------------------------------------------------------------


Hayır. Hiçbir tek araç kullanıcı modu, kernel, boot ve firmware katmanlarının tamamı için mutlak güvence vermez. Ürünün resmî desteği, güncelliği, veri işleme politikası ve diğer kanıtlarla nasıl birlikte kullanıldığı değerlendirilmelidir.


SONUÇ: ŞÜPHEDEN KANITA, KANITTAN GÜVENLİ KURTARMAYA

===================================================


Rootkit çekirdek sızıntısı ifadesinin teknik karşılığı, bir rootkit’in kernel veya daha alt güven katmanlarını etkileyerek sistem görünümünü ve bütünlüğünü bozmasıdır. Tehdidi sıradan bir uygulama hatasından ayıran temel sorun, incelenen sistemin kendi ürettiği bilginin güvenilirliğinin azalabilmesidir.


1. Yavaşlık veya tek bir uyarıyı teşhis olarak görmeyin.

2. Host verisini merkezi telemetri ve mümkünse çevrimdışı kanıtla karşılaştırın.

3. Yüksek güvenli kernel veya boot bulgusunda cihazı izole edin ve olay kapsamını belirleyin.

4. Doğrulanmış kernel ihlalinde bilinen temiz imajı; firmware şüphesinde üreticinin kurtarma yolunu kullanın.

5. Parolaları güvenilir cihazdan yenileyin, ilk giriş yolunu kapatın ve geri dönüş belirtilerini izleyin.

6. Secure Boot, HVCI veya modül imzası, en az ayrıcalık, sürücü denetimi, merkezi telemetri ve temiz yedekleri birlikte uygulayın.


Acil kullanım notu: Aktif bir kurumsal olay, kritik altyapı sistemi veya hukuki delil söz konusuysa bu makale kurumun olay müdahale planının ve yetkin adli bilişim uzmanının yerini tutmaz.


İLGİLİ BİLİŞİMTÜRK İÇERİKLERİ

=============================


• Bilgisayar Virüsleri Nedir? Tarihçesi, Salgınlar ve Yeni Nesil Virüsler (https://bilisimturk.com/kategori/guvenlik/bilgisayar-virusleri-nedir-tarihcesi-kuresel-salginlar-yeni-nesil-virusler-ve-cezalar)

• Trojan (Truva Atı) Tehdit İstihbaratı Raporu (https://bilisimturk.com/kategori/guvenlik/bilisim-tehdit-istihbarati-raporu-trojan-truva-ati-zararli-yazilim-sinifi)

• BilişimTürk Güvenlik Makaleleri (https://bilisimturk.com/kategori/guvenlik)


TEKNİK DOĞRULAMA, YAZAR VE KAYNAKÇA

===================================


Yazar: TimurKaan (https://bilisimturk.com/yazar/timurkaan), BilişimTürk Araştırma Ekibi


İlk yayın: 13 Temmuz 2026


Son teknik kaynak kontrolü: 13 Temmuz 2026


Son güncelleme: 13 Temmuz 2026


Planlı gözden geçirme: 13 Ekim 2026 veya önemli kaynak/sürüm değişikliğinde daha erken


Nasıl hazırlandı?

-----------------


Teknik tanımlar NIST ve MITRE ATT&CK; Windows açıklamaları Microsoft Learn; Linux çekirdek güvenliği Linux Kernel belgeleri; olay müdahalesi NIST ve CISA kaynaklarıyla karşılaştırıldı. AI; araştırmayı düzenleme, taslak ve dil desteği için kullanıldı. Çalışan zararlı örnek, kalıcılık kodu veya güvenlik kontrolünü atlatma talimatı eklenmedi. Yayından önce komutlar, bağlantılar, tarihler ve teknik yorumlar yetkin insan tarafından yeniden gözden geçirilmelidir.


Test ve doğrulama kapsamı

-------------------------


Kontrol | Durum | Sınır

--- | --- | ---

Windows salt okunur envanter komutları | Windows 11 üzerinde sözdizimi ve kullanılabilirlik kontrolü | Çıktı cihaz ve ilke yapılandırmasına göre değişir.

Microsoft Defender Offline | Resmî belge ve cmdlet sözdizimi doğrulaması | Yeniden başlatma etkisi nedeniyle canlı olayda çalıştırılmadı.

Linux komutları | Resmî belgelerle statik doğrulama | Dağıtım ve kernel sürümüne göre insan testi gerekir.

Kaynak ve bağlantılar | 13 Temmuz 2026 tarihinde kontrol edildi | Yayın günü yeniden kontrol edilmelidir.

Resmî kaynaklar

---------------

1. NIST CSRC — Rootkit sözlük tanımı (https://csrc.nist.gov/glossary/term/rootkit)

2. MITRE ATT&CK — T1014 Rootkit (https://attack.mitre.org/techniques/T1014/)

3. Microsoft Learn — Rootkits (https://learn.microsoft.com/defender-endpoint/malware/rootkits-malware)

4. Microsoft Learn — Microsoft Defender Offline (https://learn.microsoft.com/defender-endpoint/microsoft-defender-offline)

5. Microsoft Learn — Start-MpWDOScan (https://learn.microsoft.com/powershell/module/defender/start-mpwdoscan)

6. Microsoft Learn — Secure Boot and Trusted Boot (https://learn.microsoft.com/windows/security/operating-system-security/system-security/trusted-boot)

7. Microsoft Learn — Memory Integrity and VBS (https://learn.microsoft.com/windows-hardware/drivers/bringup/device-guard-and-credential-guard)

8. Microsoft Learn — Savunmasız sürücü engelleme kuralları (https://learn.microsoft.com/windows/security/application-security/application-control/app-control-for-business/design/microsoft-recommended-driver-block-rules)

9. Microsoft Learn — UEFI scanning in Defender for Endpoint (https://learn.microsoft.com/defender-endpoint/uefi-scanning-in-defender-for-endpoint)

10. Linux Kernel — Kernel Module Signing Facility (https://www.kernel.org/doc/html/next/admin-guide/module-signing.html)

11. Linux Kernel — Kernel Self-Protection (https://docs.kernel.org/security/self-protection.html)

12. Linux Kernel — Tainted Kernels (https://docs.kernel.org/admin-guide/tainted-kernels.html)

13. NIST SP 800-61 Rev. 3 — Incident Response Recommendations (https://csrc.nist.gov/pubs/sp/800/61/r3/final)

14. NIST SP 800-193 — Platform Firmware Resiliency Guidelines (https://csrc.nist.gov/pubs/sp/800/193/final)

15. CISA — Incident and Vulnerability Response Playbooks (https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf)


Kaynak erişim tarihi: 13 Temmuz 2026. Dış bağlantılar zaman içinde değişebilir.