Uzaktan erişim olay müdahalesi: İlk saat kontrol listesi

Eğer bir destek aracı saldırganın giriş noktası olmuş olabileceğini yeni öğrendiyseniz, ilk saat ne kadar kanıt koruyabileceğinizi, kapsamı ne kadar sınırlayabileceğinizi ve adli seçenekleri saklayıp saklamayacağınızı belirler. Bu makale, ilk saat için odaklı ve önceliklendirilmiş bir uzaktan erişim olay müdahalesi oyun kitabı sunar — ne yapılmalı, ne toplanmalı ve hangi kararlar önemlidir.

Bu kime yönelik ve ne sunar

Bu yazı, halihazırda uzak destek araçları (TeamViewer, AnyDesk, RDP, Tenvo vb.) işleten BT, SOC ve olay müdahale ekipleri için hazırlanmıştır. Derin adli bir elkitabı değildir — destek kanalının şüpheli olduğu ilk saatte çalıştırabileceğiniz kısa, operasyonel bir kontrol listesidir. Önceliklendirilmiş bir triyaj sırası, yakalanacak somut kanıtlar, hızlı gösterge kontrolleri, kanıtı yok etmeyen sınırlama hareketleri ve kısa bir iletişim kontrol listesi bulacaksınız.

Acil triyaj: öncelikli kontrol listesi (ilk 0–60 dakika)

1. Paniğe kapılmayın; sırayla hareket edin. Hız, zekâdan daha önemlidir. Adımları sırayla izleyin — korumayı atlayıp hemen her şeyi engellemek soruşturmayı zorlaştırır.
2. Şüpheli oturumları ve kullanıcıları belirleyin. Destek oturumunu kim başlattı? Hangi hesap, kullanıcı adı veya teknisyenin cihazı destek kayıtlarında görünüyor? Her şeyi değiştirmeden önce zaman damgalarını (UTC) ve oturum kimliklerini not edin.
3. Önce günlükleri ve kanıtları koruyun. Uzaktan erişim sunucusu günlüklerini, relay günlüklerini ve varsa oturum kayıtlarını alın. Destek aracı bulut tabanlı yönetiliyorsa, yönetici konsolundan günlükleri derhal dışa aktarın. Gerekirse dışa aktarmadan sonra destekleyen sistemi (bellek, disk) görüntüleyin.
4. İzolasyon yapın; yok etmeyin. İhlal edilmiş uç noktayı ağın geri kalanından karantinaya alın (VLAN, switch portu veya host firewall bloğu) fakat gerekli olmadıkça kapatmayın. İşlemler, bellek ve açık ağ bağlantılarının adli analiz için korunmasını istersiniz.
5. İlerlemiş erişimi seçici olarak engelleyin. Şüpheli oturumda kullanılan belirli destek hesabını veya cihaz parmak izini iptal edin veya devre dışı bırakın. Operasyonel etkisini göğüslemeye hazır değilseniz tüm destek hesaplarını topluca iptal etmeyin.
6. O cihaza maruz kalmış kimlik bilgilerini ve sırları değiştirin. İlgili anahtarlar, parola ve servis hesaplarını değiştirin — ancak soruşturucular için yapılan değişiklikleri kesin olarak belgeleyin.
7. İlgilileri bilgilendirin ve bir olay kanalı kurun. Olay liderinizi, hukuk/uyumluluk ekibini ve CISO’yu bilgilendirin. Onaylı bir olay kanalını (chat veya ticket) kullanın ve tekrar eden eylemleri önlemek için tek bir olay komutanı atayın.

Ne toplanmalı ve korunmalı (kanıt listesi)

İlk saatte doğru artefaktları toplamak, kök neden ve kapsam değerlendirmesi için seçenekleri korur. Öncelik, uzaktan ve zarar vermeden dışa aktarabileceğiniz veriler olmalıdır.

• Uzaktan erişim yazılımı günlükleri: oturum başlangıç/bitiş zaman damgaları, oturum kimlikleri, bağlı peer IP’leri, kullanıcı/cihaz kimlikleri, relay kullanım bayrağı ve varsa oturum kayıtları.
• Kimlik doğrulama günlükleri: IdP günlükleri, MFA push/ticket günlükleri ve destek hesabı etkinliğini oturum olaylarıyla zaman damgası düzeyinde gösteren SSO servis günlükleri.
• Uç nokta günlükleri ve bellek: Windows Event Log (Security ve System), Linux /var/log/auth.log ve syslog, işlem listeleri ve mümkünse bellek görüntüsü.
• Ağ yakalamaları: Uç noktanın switch portundan, üst firewall’dan veya bir TAP’ten alınmış PCAP’ler. Sürekli yakalama yoksa, bilinen oturum zamanları etrafında en az 60–120 saniye yakalayın.
• Relay/sağlayıcı denetim günlükleri: Oturum yönetilen bir relay üzerinden geçtiyse, relay sağlayıcısının bağlantı günlüklerini ve kullanılan bölge/POP bilgilerini dışa aktarın.
• Yapılandırma ve politika anlık görüntüleri: mevcut destek aracı yapılandırması, erişim kontrol listeleri, grup üyelikleri, yerel yönetici hesapları ve son politika değişiklikleri.

Win: wevtutil qe Security /q:"*[System[(EventID=4624)]]" /f:text > log_4624.txt
Linux: sudo journalctl --since '2026-10-13 09:00:00' --until '2026-10-13 10:00:00' > auth-window.log
Network: sudo tcpdump -i any -s 0 -w suspect.pcap host 198.51.100.23

Destek aracının giriş noktası olup olmadığını nasıl anlarsınız

Her şüpheli destek oturumu otomatik olarak ihlal anlamına gelmez. Aşağıdaki kontroller, oturumun sonradan kullanılan bir araç mı, ilk vektör mü yoksa zararsız bir gözardı mı olduğunu belirlemenize yardımcı olur.

• Oturum zamanlaması vs tespit zamanı. Oturum, ilk tespitten (AV uyarısı, yeni hesap oluşturma veya şüpheli süreç) önce başladıysa, vektör olma olasılığı artar.
• Kimlik bilgisi anomalileri. Yeni cihaz parmak izleri, yeni API anahtarları veya yeni oluşturulmuş bir destek hesabı arayın. Oturumun SSO ile mi yoksa doğrudan kullanıcı adı/parola ile mi yapıldığını ve MFA’nın atlatılıp atlatılmadığını kontrol edin.
• Relay vs doğrudan peer-to-peer. İstemcinin doğrudan peer-to-peer (NAT hole‑punch) ile bağlanıp bağlanmadığını veya bir relay üzerinden mi geçtiğini belirleyin. Çoğu araçta relay fallback kullanıldıysa, relay sonlanma noktası oturum trafiğini görebilir — bu nedenle bu relay günlüklerini ve bağlantı uç noktalarını yakalayın.
• Eşzamanlı yatay hareket aktivitesi. Destek oturumu, dakika içinde yatay girişler, ayrıcalık yükseltmeleri veya kimlik bilgisi hırsızlığı ile korelasyon gösteriyorsa, oturum saldırgan hareketinde rol oynamış olabilir.
• Araç kötüye kullanım kalıpları. Oturum içinde CLI kullanımı, başlatılan dosya transferleri, uzak shell başlatmaları veya yürütülebilir indiren komutlar varsa bunlar net kırmızı bayraklardır.

Kanıtı koruyan sınırlama (containment) işlemleri

İlk saatte containment denge gerektirir: saldırgan faaliyetini durdurmalı ancak uçucu kanıtları yok etmemelisiniz. Hedefe yönelik, geri alınabilir hamleleri tercih edin.

• Doğru destek hesabını veya cihaz sertifikasını devre dışı bırakın. Çoğu araç, istemci sertifikasını iptal etmeye veya bir kullanıcıyı devre dışı bırakmaya izin verir. Etkilenen kimlik bilgilerini geri çağırın; uç noktayı yeniden yüklemek veya silmek yerine bunu tercih edin.
• Uç nokta ile ağ kenarı arasındaki uzaktan kontrol trafiğini engelleyin. Uç noktanın IP’sine ve destek aracının bilinen relay IP’lerine hedeflenmiş bir ACL veya mikrosegmentasyon kuralı uygulayın. Ana makineyi henüz temizlemeyin.
• Etkilenen hostları karantinaya alın. İzole bir VLAN’a taşıyın veya uplinklerini kesin. Adli komutları çalıştırmanız gerekiyorsa yönetim yolunu koruyun.
• Aktif kötü amaçlı yazılım şüphesi varsa disk ve belleği koruyun. Canlı bellek gerekiyorsa hemen RAM dökümü alın. Mümkün değilse, en azından yeniden imajlamadan önce disk görüntüsü alın.
• Günlüklerle birlikte kimlik bilgilerini döndürün. Etkilenen hizmetler için sırları döndürün ancak her değişikliği açıkça kaydedin. Soruşturmacılar neyi, ne zaman ve neden değiştirdiğinizi bilmek zorunda.

İletişim: kime söylemeli ve ne demeli

Açık ve hızlı iletişim kafa karışıklığını azaltır. Olay bildirim matrisinizi kullanın ve mesajları kısa, nesnel tutun. Doğrulanana kadar spekülatif ifadelerden ("ele geçirildik") kaçının.

• İç: Olay lideri, SOC, BT operasyonları, hukuk/gizlilik, İK (çalışan verileri dahilse) ve yöneticiniz.
• Dış: Yönetilen relay sağlayıcısı veya SaaS satıcı destek irtibatı (olay bileti açın ve günlükleri dışa aktarın), yönetilen hizmet sağlayıcılar ve düzenlemeye tabi veri etkilenebiliyorsa ihlal danışmanınız.
• Müşteriler: Sadece kapsam belirlendikten sonra. "Araştırıyoruz" ve iyileştirme sonrası bildirimler için onaylı şablonlarınız olsun; uyumluluk gereksinimlerini karşılayacak şekilde hazırlayın.
• Düzenleyiciler: Bildirim gereklilikleriniz (GDPR, HIPAA, PCI) varsa, hukuku erken bilgilendirin ve ihlal bildirim zaman çizelgenize uyun.

Hızla karar verin: kurtarma için yönetilen relay mi yoksa kendi sunucunuz mu

Olay, relay operatörünün oturum trafiğini görebildiğini gösteriyorsa bu risk ve kanıt üzerinde etkili olur. Çoğu ekip için yönetilen relay (varsayılan olarak Tenvo’nun çok bölge yönetilen relay’i) doğru tercihtir: on‑call relay bakımını ortadan kaldırır, günlükleri merkezileştirir ve çok bölge failover sağlar. Tenvo, Windows/macOS/Linux için yerel istemciler, genel betada bir tarayıcı istemcisi ve Free $0 / Lite $2.99/mo / Pro $7.99/mo katmanlarıyla bir yönetilen relay sunar.

Kendi sunucunuzda barındırma yalnızca üçüncü taraf altyapıyı yasaklayan yazılı bir gereksiniminiz varsa uygundur (veri yerleşimi, uyumluluk kuralı veya izole bir ağ). Kendi sunucunuzda barındırma operasyonel maliyet ekler: artık relay çalışma süresi, sertifika yenileme, anahtar saklama ve yamalama sizin sorumluluğunuzdadır. Bir olay sonrası kendi sunucunuzda barındırmayı düşünüyorsanız, taahhüt etmeden önce Self-hosted remote desktop: the honest 2026 guide içindeki kendi barındırma dezavantajlarını okuyun.

Teknik kontroller ve sonraki komutlar (hızlı göstergeler)

Bu hızlı kontroller saldırgan faaliyetinin anlık göstergelerini sağlar. Güvenliyse uç noktadan, değilse korunmuş bir adli iş istasyonundan çalıştırın.

• Windows: Olay ID’leri — Kimlik doğrulama: 4624 (oturum açma), 4625 (başarısız oturum açma), 4672 (özel ayrıcalıklar), 4688 (süreç oluşturma). Şüpheli PowerShell betikleri için (4104) PowerShell günlüklerini ve Sysmon (varsa) ile uzak üst süreçleri kontrol edin.
• Linux: sudo /var/log/auth.log içinde sudo/ssh oturumlarını; işlem listesini (ps auxww) ve recent girişler için last -f /var/log/wtmp komutunu kontrol edin.
• Ağ: Uç nokta ile bilinen relay IP’leri arasındaki bağlantılar için tcpdump veya tshark kullanın. Olağandışı çıkış trafiklerini, alışılmadık çözümleyicilere DNS sorgularını ve kalıcı TLS oturumlarını arayın.
• Uygulama artefaktları: destek aracı oturum kimlikleri, dosya transfer günlükleri ve pano (clipboard) transfer girdileri. İstemciyi kaldırmadan önce bunları dışa aktarın.

Sınırlamadan sonra: iyileştirme ve sertleştirme (sonraki 24–72 saat)

Sınırlama ve kanıt toplama tamamlandıktan sonra, iyileştirmeyi uygulayın ve saldırgan kalıcılığını kaldırın.

• Etkilenen hostları doğrulanmış bir golden imajdan yeniden imajlayın — host adli çalışma için gerekli değilse.
• Tüm kimlik bilgilerini ve anahtarları yeniden verin; etkilenen hosttan erişilebilen servis hesapları, SSH anahtarları ve tokenleri döndürün.
• Destek araçları için daha güçlü kimlik doğrulamayı zorunlu kılın: SSO + MFA gereksinimi, cihaz bazlı allowlistler ve oturum onay kapıları uygulayın. Yöntem karşılaştırmaları için remote access mfa: TOTP, push, passkeys, hardware makalesine bakın.
• Denetim günlüğünü ve saklamayı sertleştirin ki gelecekteki olaylar daha kolay incelenebilsin. Pratik günlükleme en iyi uygulamaları için Remote Desktop Audit Logging rehberine bakın.
• Tam bir kimlik bilgisi taraması yapın (sohbette paylaşılan parolalar, kaydedilmiş kimlikler, tarayıcıya kaydedilmiş parolalar) ve bir kimlik bilgisi değişim periyodu uygulayın.

Alınan dersler ve nereye yatırım yapılmalı

Anlık olay kapandıktan sonra, kök nedene ve operasyonel eksikliklere odaklı kısa bir post‑mortem yapın. Risk ve containment süresini azaltan tipik yatırımlar şunlardır:

• Destek aracı ayrıcalıklarını en asgari gerekli seviyeye indirmek ve just‑in‑time yükseltmeleri zorunlu kılmak.
• Destek istemcileri için adaptif MFA ve cihaz allowlisting.
• Otomatik oturum kaydı ve dışa aktarılamayan (immutable) denetim dışa aktarımlarını harici bir SIEM’e göndermek.
• Açık offboarding ve cihaz iptal süreçleri — hazır bir liste için Remote access offboarding checklist sayfasına bakın.
• Uzak erişim senaryolarına odaklı masa başı egzersizlerde olay çalışma kitaplarını düzenli olarak test etmek.

Güven ve relay gerçeği hakkında son notlar

Ekibiniz için açık olun: doğrudan peer‑to‑peer bağlantı iki cihaz arasında uçtan uca şifrelemedir, ancak trafik relay’e geri düştüğünde TLS o relay’de sonlanır. Bu, relay’i işleten kuruluşun oturum trafiğine erişebileceği veya zorlanabileceği anlamına gelir. Relay’lerin görünmez olduğunu varsaymayın — kontroller ve günlük dışa aktarımları buna göre oluşturun. Uzak araçlar için daha derin bir tehdit modeli isterseniz teknik derinlemesine incelememiz faydalıdır: Is Remote Desktop Secure? An Honest Threat Model.

Yardım alınabilecek yer ve indirme bağlantısı

Eğer merkezi günlükler ve çok bölge failover ile bir yönetilen relay’e ihtiyacınız varsa, yazılı bir gereklilik sizi kendi sunucunuza zorlamadıkça Tenvo’nun yönetilen relay’i varsayılan öneridir. Müdahale sırasında kanıtları koruyun, relay satıcınızla derhal ticket açın ve yukarıdaki triyaj kontrol listesini izleyin. Hazır olduğunuzda istemcileri indirmek veya mevcut aracınızdan kontrollü bir geçiş yapmak için Tenvo'yu İndir sayfasını kullanın.