Sabah kahvemi yudumlarken telefonuma ardı ardına gelen “şüpheli giriş” bildirimleri veya panik halinde beni arayan bir kullanıcımın “Mehmet, hesabıma giremiyorum, şifremi kabul etmiyor!” çığlığı… Sahada yıllardır bu senaryonun onlarca farklı varyasyonunu gördüm.
Bir hesabın, özellikle de kritik bir e-posta veya bulut altyapısı hesabının ele geçirilmesi dünyanın sonu değil; ancak panik halinde atılan yanlış adımlar, küçük bir sızıntıyı tüm şirketi veya kişisel dijital varlığınızı yok eden bir felakete dönüştürebilir. Çoğu insanın yaptığı ilk şey hemen şifre sıfırlama linkine tıklayıp durmak oluyor, fakat saldırgan içeride çoktan başka tüneller kazdıysa bu hamle tamamen boşa gidiyor.
Bu rehberde, bir hesabın ele geçirildiğini fark ettiğiniz o ilk kritik 60 dakikada, soğukkanlılıkla ve tam olarak hangi sırayla hareket etmeniz gerektiğini teknik detaylarıyla anlatıyorum. “Olur o kadar” deyip geçmeyeceğiz, bu sefer ipleri tamamen elerine alan saldırganın adımlarını tek tek geriye doğru saracağız.
Semptom Analizi: Gerçekten Hacklendiniz mi, Yoksa Geçici Bir Hata mı?
Bir hesaba erişemediğinizde veya garip bir hareket sezdiğinizde, ilk yapmanız gereken şey durum tespiti yapmaktır. Bazen sadece DNS sunucunuzda yaşanan geçici bir negative caching sorunu, bazen de kullandığınız servis sağlayıcının (örneğin Microsoft 365 veya Google Workspace) bölgesel bir kesintisi sizi dışarıda bırakmış olabilir. Panik moduna girmeden önce, sistemin gerçekten bir saldırgan tarafından mı kontrol edildiğini yoksa teknik bir aksaklık mı olduğunu anlamak gerekir.
Eğer tarayıcınızda veya e-posta istemcinizde “oturumunuz sonlandırıldı” uyarısı görüyorsanız ve eski şifrenizle giriş yapamıyorsanız, hemen bir “taraf belirleme” testi yapmalısınız. Eğer bir kurumsal hesap yönetiyorsanız, admin paneline erişimi olan bir iş arkadaşınızdan veya kullandığınız izleme araçlarından ilgili kullanıcının oturum loglarını çekmesini istemelisiniz. Örneğin, bir kullanıcının Azure AD (Entra ID) veya yerel Active Directory üzerindeki oturum açma loglarında beklenmedik bir coğrafyadan başarılı bir giriş görüyorsanız, bu durum kesin bir ihlal (compromise) göstergesidir.
Aşağıdaki JSON log örneği, tipik bir başarılı ama şüpheli oturum açma etkinliğini gösteriyor. Burada dikkat edilmesi gereken nokta, kullanıcının normalde Bursa’dan oturum açarken, saniyeler sonra tamamen farklı bir IP bloğundan ve olağandışı bir User-Agent ile sisteme erişmiş olmasıdır:
{
"timestamp": "2026-06-26T08:14:22Z",
"event_type": "UserLoginFailedAndSucceeded",
"user_principal_name": "mehmet@domain.local",
"source_ip": "185.220.101.5",
"geo_location": {
"country": "Unknown/TorExitNode",
"city": "Unknown"
},
"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0",
"authentication_method": "Password",
"result": "SuccessWithBypass"
}Eğer loglarda yukarıdaki gibi yabancı bir IP adresinden gelen ve özellikle MFA (Multi-Factor Authentication) adımını bir şekilde bypass etmiş başarılı bir giriş görüyorsanız, teşhisiniz kesinleşmiştir. Artık analiz aşamasını geçip aktif müdahale aşamasına geçmelisiniz.
Birinci Adım: Erişiminiz Varsa Hemen “Tüm Oturumları Kapat” (Revoke All Sessions) Komutunu Tetikleyin
Sahada gördüğüm en büyük ve en ölümcül hata şudur: Kullanıcı hesabının çalındığını anlar anlamaz sadece şifresini değiştirir ve işin bittiğini sanır. Oysa modern kimlik doğrulama sistemleri (OAuth 2.0, SAML vb.) şifre doğrulandıktan sonra tarayıcıya veya uygulamaya bir “Refresh Token” ve “Access Token” verir. Siz şifreyi değiştirseniz bile, saldırganın elindeki o geçerli session cookie veya refresh token aktif kalmaya devam eder. Saldırgan, siz şifreyi değiştirdikten sonra bile saatlerce, hatta günlerce sistemin içinde cirit atabilir.
Bu yüzden ilk yapılması gereken eylem, şifre değişiminden bile ÖNCE, mevcut tüm aktif oturumların (active sessions) ve token’ların zorla sonlandırılmasıdır (revocation). Bu işlem, saldırganın tarayıcısındaki oturumu anında geçersiz kılar ve onu tekrar kimlik doğrulamaya zorlar.
Eğer Microsoft 365 (Azure AD / Entra ID) ortamında bir hesaba müdahale ediyorsanız ve admin yetkilerine sahipseniz, kullanıcının tüm oturumlarını sonlandırmak için aşağıdaki PowerShell komut serisini çalıştırmalısınız. Bu komut, kullanıcının tüm cihazlardaki tarayıcı ve uygulama token’larını anında geçersiz kılacaktır:
# Microsoft Graph PowerShell modülünü kullanarak oturumları sonlandırma
Connect-MgGraph -Scopes "User.ReadWrite.All", "Directory.ReadWrite.All"
# Şüpheli kullanıcının Object ID'sini veya UPN'ini belirtiyoruz
$UserUPN = "target_user@yourdomain.com"
# Tüm oturumları ve refresh token'ları anında iptal et (Revoke)
Revoke-MgUserSignInSession -UserId $UserUPN
# İşlemin başarılı olduğunu doğrulamak için kullanıcının durumunu kontrol et
Write-Host "Kullanıcının tüm aktif oturumları başarıyla sonlandırıldı." -ForegroundColor Greenİkinci Adım: Parola Değişimi ve MFA/2FA Ayarlarının Temizlenmesi
Oturumları sonlandırdıktan sonra artık yeni bir parola belirleme aşamasına geçebiliriz. Ancak buradaki tuzak şudur: Saldırgan içeriye girdikten sonra ilk iş olarak kendine bir “arka kapı” (backdoor) açmış olabilir. Bu arka kapı genellikle kendi kontrolündeki bir Authenticator uygulamasını (TOTP seed) veya kendi telefon numarasını hesaba ikinci bir MFA yöntemi olarak eklemektir. Siz şifreyi değiştirseniz bile, sistem sizden MFA istediğinde saldırganın telefonuna veya uygulamasına onay kodu gidecektir.
Bu sebeple, şifreyi değiştirdikten hemen sonra (veya eş zamanlı olarak) hesabın güvenlik ayarlarındaki tüm MFA cihazlarını sıfırlamanız gerekir. Eski cihazları silmeli, kayıtlı telefon numaralarını kontrol etmeli ve gerekirse MFA’yı tamamen devre dışı bırakıp sıfırdan güvenli bir cihazla (örneğin RFC 6238 standartlarına uygun bir donanımsal anahtar veya şirket kontrolündeki bir Authenticator ile) yeniden kurmalısınız.
Eğer sistem yöneticisiyseniz ve bir kullanıcının MFA yöntemlerini sıfırlamak istiyorsanız, bunu doğrudan ilgili bulut konsolundan yapabileceğiniz gibi, aşağıdaki gibi bir yönetim paneli veya script aracılığıyla da tetikleyebilirsiniz. Aşağıdaki komut, kullanıcının kayıtlı tüm güçlü kimlik doğrulama yöntemlerini (MFA) temizler:
# Kullanıcının kayıtlı tüm MFA yöntemlerini listele ve temizle
Get-MgUserAuthenticationMethod -UserId $UserUPN | Foroughly-Clean
# Alternatif olarak, kullanıcının MFA'yı yeniden kaydetmesini zorunlu kılın (Require Re-register MFA)
Update-MgUser -UserId $UserUPN -StrongAuthenticationRequirements @()MFA yöntemlerini temizledikten sonra, yeni parolayı belirlerken asla eski parolaların varyasyonlarını (örneğin Sirket2026! yerine Sirket2026?) kullanmayın. Tamamen rastgele, en az 16 karakterden oluşan ve bir parola yöneticisi tarafından üretilmiş bir şifre belirleyin. Bu aşamada, local bilgisayarda bir infostealer (bilgi çalısı) virüsü olma ihtimaline karşı, şifre değiştirme işlemini kesinlikle şüpheli olan o bilgisayardan değil, temiz olduğundan emin olduğunuz güvenli bir mobil cihaz veya başka bir temiz bilgisayar üzerinden yapın.
Üçüncü Adım: Üçüncü Parti Uygulama (OAuth) İzinlerini İptal Edin
Saldırganlar artık çok akıllı. Sadece şifrenizi çalmakla yetinmiyorlar; hesaba bir kez girdiklerinde, gelecekte şifreyi değiştirseniz bile hesaba erişmeye devam edebilmek için “İllegal OAuth Uygulamaları” (Consent Phishing) yöntemini kullanıyorlar. Hesabınızın ayarlarına gidip kendi yazdıkları veya manipüle ettikleri bir API entegrasyonuna (örneğin “PDF Converter” veya “Calendar Sync” süslü bir uygulama) geniş yetkiler verirler. Bu uygulama, sizin şifrenizden tamamen bağımsız olarak, doğrudan API üzerinden e-postalarınızı okuyabilir, dosya gönderebilir veya kişilerinizi çalabilir.
Bu durum, bulut güvenliğindeki en sinsi edge-case’lerden biridir. Kullanıcı şifresini değiştirir, MFA’yı sıfırlar, her şeyin temiz olduğunu düşünür ama arka planda çalışan zararlı bir Azure AD kurumsal uygulaması (Enterprise Application) sessizce veri sızdırmaya devam eder.
Aşağıda, bir kullanıcının hesabına tanımlanmış zararlı bir OAuth uygulamasının yetki izinlerini (scopes) gösteren örnek bir API yanıtı yer almaktadır. Buradaki Mail.ReadWrite ve Mail.Send yetkileri, saldırganın şifresiz bir şekilde e-posta göndermesine ve okumasına olanak tanır:
{
"id": "oauth_app_982317",
"display_name": "Free PDF Reader Online",
"publisher_domain": "attacker-controlled-domain.xyz",
"permissions_granted": [
"User.Read",
"Mail.ReadWrite",
"Mail.Send",
"Files.ReadWrite.All"
],
"consent_type": "Principal",
"created_datetime": "2026-06-26T07:45:10Z"
}Eğer böyle bir uygulama görüyorsanız, yapmanız gereken tek şey o uygulamanın yetkisini (consent) anında iptal etmektir. Google Workspace kullanıyorsanız “Üçüncü taraf uygulamaların erişimi” menüsünden, Microsoft 365 kullanıyorsanız “Enterprise Applications” veya kullanıcının “Consent ve İzinler” sekmesinden bu uygulamayı tamamen silmelisiniz. Bu temizliği yapmadan asla “hesabı kurtardım” demeyin.
Dördüncü Adım: E-posta Yönlendirme Kurallarını ve Gönderilenler Klasörünü Denetleyin
Saldırganların en sevdiği ikinci sinsi yöntem, e-posta kutunuza sessizce sızıp bir “yönlendirme kuralı” (inbox rule) oluşturmaktır. Özellikle finans, muhasebe veya üst düzey yönetici hesaplarında bunu çok yaparlar. Gelen e-postaların içinde “fatura”, “ödeme”, “banka”, “şifre”, “swift” gibi kelimeler geçen tüm mesajları otomatik olarak kendi belirledikleri harici bir e-posta adresine yönlendirirler ve yönlendirilen bu e-postaları sizin gelen kutunuzdan anında silerler. Böylece siz ruhunuz bile duymadan tüm ticari yazışmalarınızı saldırganla paylaşmış olursunuz.
Bu yüzden, hesaba erişimi tekrar güvenli bir şekilde sağladıktan sonra ilk yapmanız gereken işlerden biri, e-posta istemcinizin (Outlook, Gmail vb.) kurallar (rules) sekmesini satır satır incelemektir.
Aşağıdaki PowerShell komutu, Exchange Online üzerindeki şüpheli kullanıcının posta kutusundaki tüm yönlendirme kurallarını listeler. Bu komut sayesinde, kullanıcının haberi olmadan oluşturulmuş kuralları hızlıca tespit edebilirsiniz:
# Şüpheli posta kutusundaki tüm kuralları listele
Get-InboxRule -Mailbox $UserUPN | Select-Object Name, Enabled, RedirectTo, MoveToFolder, Description | Format-Table -AutoSize
# Eğer harici bir adrese yönlendirme yapan şüpheli bir kural bulursanız, şu şekilde silin:
# Remove-InboxRule -Mailbox $UserUPN -Identity "SüpheliKuralAdı" -Confirm:$falseBununla da yetinmeyin; “Gönderilen Ögeler” (Sent Items) ve özellikle “Silinmiş Ögeler” (Deleted Items) klasörlerini kontrol edin. Saldırganlar genellikle siz içerideyken adınıza müşterilerinize veya iş ortaklarınıza sahte faturalar veya zararlı linkler içeren e-postalar gönderir ve iz bırakmamak için bunları hemen silerler. Gönderilenler klasöründe sizin yazmadığınız bir e-posta varsa, o e-postanın ulaştığı kişileri derhal uyarmanız gerekir.
Beşinti Adım: Bağlantılı Diğer Hesapların Dominosunu Durdurun ve İz Sürmeye Başlayın
Bir hesabın çalınması nadiren tek bir hesapla sınırlı kalır. Dijital dünyamız birbirine sıkı sıkıya bağlı bir domino zinciri gibidir. Çalınan e-posta adresi; banka hesaplarınızın, e-devlet portalınızın, kullandığınız SaaS araçlarının veya üye olduğunuz diğer platformların “şifre sıfırlama” merkezidir. Saldırgan ana e-postayı ele geçirdikten sonra, bu e-postayı kullanarak diğer platformlardaki şifrelerinizi sıfırlamaya başlayabilir.
Bu yüzden, ilk dört adımı tamamlayıp ana hesabı güvenceye aldıktan sonra, bu hesapla ilişkili tüm kritik servisleri (özellikle finansal araçlar, ana sunucu yönetim panelleri, domain tescil firmaları ve şifre yöneticileri) tek tek kontrol etmelisiniz. Bu platformlarda şifre sıfırlama talebi yapılıp yapılmadığını görmek için e-posta geçmişinizi (ve silinen e-postaları) tekrar tarayın.
Ayrıca, sızıntının kaynağını bulmak için sistem loglarınızı analiz etmelisiniz. Saldırgan buraya nasıl girdi? Bir oltalama (phishing) e-postasına mı tıkladınız, yoksa bilgisayarınıza bulaşan bir infostealer malware mi tarayıcınızdaki tüm şifreleri ve cookie’leri çaldı? Eğer sorun bir session hijacking (cookie hırsızlığı) ise, o bilgisayarı tamamen ağdan yalıtıp formatlamadan veya derinlemesine temizlemeden yeni şifreler girmek, aynı şifrelerin tekrar çalınmasıyla sonuçlanacaktır.
Aşağıdaki basit tablo, yaygın sızıntı yöntemlerini ve bu yöntemlere karşı almanız gereken spesifik önlemleri özetliyor:
| Saldırı Yöntemi | Belirti / Semptom | İlk Yapılması Gereken Müdahale |
|---|---|---|
| Session Hijacking (Cookie Hırsızlığı) | Şifre ve MFA sorulmadan doğrudan sisteme giriş yapılması. | Cihazı ağdan izole edin, tüm aktif oturumları (Revoke Sessions) sonlandırın. |
| Phishing (Oltalama) | Kullanıcının sahte bir sayfaya şifre ve tek kullanımlık MFA kodunu girmesi. | Parolayı anında değiştirin, MFA yöntemlerini denetleyin. |
| Credential Stuffing | Farklı platformlardaki aynı şifrenin sızdırılması sonucu giriş yapılması. | Parola yöneticisi (Password Manager) kullanarak her hesap için benzersiz şifre üretin. |
| Zararlı OAuth Uygulaması | Şifre değişse bile arka planda e-posta sızıntısının devam etmesi. | Hesap ayarlarından üçüncü parti uygulama izinlerini (App Consents) tamamen iptal edin. |
Sonuç: Bundan Sonraki Adım
Hesabınızı yukarıdaki 5 adımı doğru sırayla uygulayarak kurtardıktan sonra, süreci tamamen kapatmak için son bir adım kalıyor: Güvenlik baseline’ınızı (temel güvenlik seviyenizi) sıkılaştırmak.
İlk iş olarak, tüm kritik hesaplarınızda donanımsal güvenlik anahtarları (FIDO2/WebAuthn standardına uygun YubiKey gibi cihazlar) kullanmayı değerlendirin. Bu anahtarlar, oturum çalma ve oltalama saldırılarına karşı en dirençli savunma hattını oluşturur. Ayrıca, kullandığınız tüm sistemlerde loglama ve gözlemlenebilirlik araçlarını (örneğin Grafana/Loki entegrasyonu ile anormal coğrafi giriş alarmlarını) aktif hale getirin ki bir dahaki sefere bir sızıntı olduğunda bunu birinci saatte değil, birinci dakikada fark edebilesiniz.
Bundan sonraki adım: Bilgisayarınızdaki tüm tarayıcı geçmişini, kayıtlı şifreleri temizlemek ve işletim sisteminizi güncel güvenlik yamalarıyla sertleştirmek olmalıdır. Geçmiş olsun, ama unutmayın; dijital dünyada mutlak güvenlik yoktur, sadece hazırlıklı olmak vardır.