Microsoft 365 kesintisi: DDoS mu, kendi değişikliği mi? Güvenlik ekipleri için gerçek risk

Dün öğleden sonra timeline'ım "Microsoft, AWS, Gmail, Claude... her şey çöktü" listeleriyle doldu. Bir kısmı "Microsoft sunucuları neyin düşürdüğünü açıklayınca şaşıracaksınız" gibi cümlelerle bitiyordu. Ben de oturup Microsoft'un açıklamalarını ve güvenilir kaynakları taradım. Bu yazıda doğrulanmış olanı, olası nedenleri ve bir güvenlikçi olarak bu kesintide asıl neyi riskli bulduğumu topladım.

Tek bakışta

• Kesinti 12 Kasım'da ABD Doğu saatiyle 13:00 civarında başladı ve 13 Kasım'da hâlâ tam olarak düzelmemişti.
• Downdetector'da yalnızca ABD'de 130.000'e yakın Outlook ve 45.000'in üzerinde Microsoft 365 raporu görüldü.
• 10'dan fazla servis etkilendi.
• Microsoft, kötü niyetli bir aktivite belirtisi görmediğini söylüyor. Root cause henüz açıklanmadı.

Microsoft'un admin center'daki kayıtları EX1550543 (Exchange Online) ve MO1550821 (genel Microsoft 365).

Sadece Outlook değil

İlk saatlerde herkes Outlook'tan bahsediyordu, fakat etkilenen servislerin listesi çok daha uzun:

• Exchange Online ve Outlook: web ve masaüstü istemcilerde mailbox'lara erişilemedi.
• Teams, Copilot, Planner, To Do: Exchange'e bağlı özellikler aksadı.
• SharePoint ve OneDrive: dosyalar açılıyordu, fakat Exchange'e bağlı özellikler tutarsız çalıştı.
• Defender XDR ve Purview: güvenlik ve uyumluluk araçları da etkilenenler arasında.
• Login, Azure ve Microsoft Store: bazı bölgelerde giriş sorunları ve kullanıcı raporları var, fakat Microsoft bunları ayrıca teyit etmedi.

Benim için listenin en dikkat çekici kısmı Defender XDR ve Purview. Buna aşağıda ayrıca değineceğim.

Neler yaşandı?

1. Önce Amerika bölgesinde mailbox'lara erişim kesildi. Kısa süre sonra Microsoft, sorunun her bölgeyi etkileyebileceğini duyurdu.
2. Microsoft tüm deployment'ları durdurdu, trafiği etkilenen altyapıdan uzaklaştırdı ve sunucuları yeniden başlattı.
3. Yeniden başlatılan sunucular trafik geri geldiğinde tekrar yanıt vermez hale geldi. Bu yüzden toparlanma beklenenden uzun sürdü.
4. Microsoft, kesintinin başladığı saatle örtüşen bir network config değişikliğini geri almaya başladı.
5. Bazı lokasyonlarda geçici trafik sınırlaması uygulandı. 13 Kasım itibarıyla toparlanma kısmiydi ve Microsoft tam bir düzelme süresi vermemişti.

Teknik olarak ne oldu?

Microsoft'un açıklamalarını birleştirince ortaya çıkan zincir şöyle:

1. Kapasite kaybı. Çok sayıda sunucu beklenmedik şekilde kullanılamaz hale geldi ve yük, ayakta kalan sunuculara bindi. Ortada dışarıdan gelen bir trafik patlaması yok.
2. TLS tarafında tıkanma. Etkilenen sunucularda secure connection kurmaktan sorumlu bir process aşırı yüklendi ve istekleri işlemeyi bıraktı.
3. Health check'lerin havuzu küçültmesi. Sunucular otomatik health check'lerden geçemedi ve havuzdan çıkarıldı. Havuz küçüldükçe kalan sunuculara daha fazla yük bindi. Bu, klasik bir cascading failure.
4. Müdahalenin yarattığı yeni yük. Microsoft'a göre yapılan müdahaleler, routing servislerinden backend sunuculara bir çağrı patlaması yarattı. Kötü durumda takılı kalan bazı makineler de config geri alımının yayılmasını engelledi.

Microsoft ayrıca bir grup sunucuda alternatif bir health check yöntemini doğruladığını ve bunu yaygınlaştırdığını açıkladı.

DDoS mu?

Şu ana kadarki veriler DDoS'u desteklemiyor. Bunu üç nedenle söylüyorum:

• Microsoft'un açıklaması. EVP Charles Lamanna, kötü niyetli ya da siber bir aktiviteye dair bir belirti olmadığını söyledi. Bunun Microsoft'un kendi değerlendirmesi olduğunu, bağımsız bir doğrulama olmadığını not etmek gerekiyor.
• Belirtiler farklı. DDoS'ta dışarıdan gelen anormal bir trafik artışı görürsünüz. Burada sunucular kendi içinde çöküyor ve ayağa kalkanlar normal trafik geldiğinde tekrar düşüyor.
• 2023 ile karşılaştırma. Haziran 2023'teki Outlook ve OneDrive kesintisinde Microsoft, Anonymous Sudan'ın layer 7 DDoS saldırısını açıkça doğrulamıştı. Bu kez böyle bir ifade yok.

Peki neden olmuş olabilir? Şu an iki ihtimal konuşuluyor:

1. Network config değişikliği. Microsoft'un geri aldığı değişiklik kesintinin başladığı saatle örtüşüyor. En güçlü ipucu bu, fakat Microsoft henüz bunun neden olduğunu doğrulamadı.
2. Health check bileşeninde bir sorun. Bazı analizler, sunucu sağlığını değerlendiren bileşenin aslında sağlam olan sunucuları hatalı işaretlemiş olabileceğini öne sürüyor. Bu durumda havuz gereksiz yere küçülmüş olur. Bu bir tahmin, Microsoft tarafından doğrulanmadı.

Ne biliyoruz, ne bilmiyoruz?

Viral listelerdeki diğer servislerle ilgili doğrulayan bir kaynak bulamadım. Büyük bir kesintide kullanıcılar sorunun nerede olduğunu bilmediği için Downdetector'da gördükleri her servisi işaretliyor; bu yüzden alakasız servislerde küçük sıçramalar görmek normal.

Güvenlik ekibi için asıl risk: kör kalan pencere

Bir kesinti saldırı olmasa bile, saldırganlar için bir fırsat penceresi açıyor. Bu kesintide bence dört konu öne çıkıyor.

Görünürlük boşluğu. Defender XDR ve Purview de etkilenenler arasında. Güvenlik araçlarınız izledikleri bulutla aynı altyapıda çalışıyorsa, kesinti süresince alert'ler gecikmiş ya da hiç gelmemiş, audit log'lar geç işlenmiş olabilir. Bir saldırgan için gürültünün en yüksek, görünürlüğün en düşük olduğu an tam olarak bu.

Phishing ve vishing. Saldırganlar da Downdetector'u izliyor. Benzer kesintilerden sonra genelde 24-48 saat içinde lookalike domain'ler ve "Microsoft hesabınızı yeniden doğrulayın" başlıklı mailler ortaya çıkıyor. Bunun bir de telefon versiyonu var: "IT'den arıyoruz, kesinti yüzünden şifrenizi sıfırlamamız gerekiyor." Kullanıcılar gerçekten giriş yapamadığı için bu mesajlar her zamankinden daha inandırıcı.

MFA karmaşası. Giriş sorunu yaşayan bir kullanıcı, beklenmedik bir MFA prompt'unu "herhalde sistem toparlanıyor" diye onaylamaya her zamankinden daha yatkın olur.

Shadow IT. Mail çalışmazken iş durmuyor. Dosyalar kişisel Gmail'e, WhatsApp'a ya da rastgele bir dosya paylaşım sitesine gitmiş olabilir.

SOC kontrol listesi

1. Kesinti penceresine geriye dönük threat hunting yapın. Geç düşen Defender alert'lerine, Entra ID sign-in log'larına ve Unified Audit Log'a bakın. Kesinti süresince "sessiz" görünen saatleri özellikle kontrol edin.
2. Kullanıcılara phishing ve vishing uyarısı gönderin. Lookalike domain takibini açın.
3. Helpdesk ve MFA tarafını sıkılaştırın. Şifre ve MFA reset taleplerinde kimlik doğrulamayı sıkı tutun; önümüzdeki günlerde yeni MFA kayıtlarını ve olağandışı başarısız giriş artışlarını izleyin.
4. Out-of-band iletişim kanalı tanımlayın. Teams ve mail aynı anda gidebiliyor; incident sırasında nereden konuşacağınızı önceden bilin.
5. Bağımlılık haritası çıkarın. Güvenlik araçlarınızdan hangisi izlediği bulutla aynı yerde çalışıyor? O bulut düştüğünde hangi görünürlüğü kaybediyorsunuz?
6. Kayıtları takip edin, SLA kredisini unutmayın. Admin center'da EX1550543 ve MO1550821'i izleyin. Microsoft, kurumsal Microsoft 365 aboneliklerinde Exchange Online için aylık %99,9 erişilebilirlik taahhüt ediyor. Bunun altına düşülürse etkilenen servisin aylık ücretinden indirim (service credit) alma hakkınız doğuyor: %99,9'un altında %25, %99'un altında %50, %95'in altında %100. 30 günlük bir ayda %99,9 en fazla 43 dakika kesinti demek; tenant'ı 24 saatten fazla etkilenen bir şirket yaklaşık %96,7'ye, yani %50 kredi seviyesine düşüyor. Bu indirim otomatik gelmiyor; admin'in admin center üzerinden etkilenen kullanıcıları ve süreyi belgeleyerek talep açması gerekiyor. Bireysel ve aile aboneliklerinde bu hak yok.

Microsoft post-incident report'u yayımladığında root cause'u ekleyip bu yazıyı güncelleyeceğim.