Microsoft 365 Kesintisini Fırsata Çeviren Kimlik Avı: Mesajlarınız Tutuldu E-postaları (EX1550543)

Merhaba

12 Kasım 2026’da yaşanan Microsoft 365 kesintisinin hemen ardından, kesintiyi bahane olarak kullanan bir kimlik avı (phishing) kampanyası ortaya çıktı. Microsoft Threat Intelligence, 14 Kasım 2026 tarihli paylaşımında, Microsoft 365 servis sağlığı bildirimlerini taklit eden ve gerçek Exchange Online olayına (EX1550543) atıf yapan e-postaları gözlemlediğini duyurdu.

Bu yazıda önce paylaşılan bilgileri kaynaklarıyla karşılaştırarak doğruladım. Ardından kampanyanın nasıl çalıştığını, kendi tenant’ınızda nasıl avlayabileceğinizi (hunting) ve bağlantıya tıklayan kullanıcılar için nasıl bir yol izlemeniz gerektiğini topladım.

Kısa Özet

• Kampanya gerçek: Microsoft Threat Intelligence’ın resmi X hesabı (@MsftSecIntel) 14 Kasım 2026’da duyurdu, birden fazla haber kaynağı aynı ayrıntıları aktardı.
• Tema: Kesinti sırasında mesajlarınız tutuldu, 24 saat içinde silinecek, geri yüklemek için tıklayın. Bu iddia sahte.
• Altyapı: üç gönderen alan adı, alıcıya özel SendGrid tıklama izleme bağlantıları ve reallifeaccounting[.]com adresine yönlendirme.
• Microsoft’un değerlendirmesi: faaliyet kimlik bilgisi hırsızlığıyla uyumlu, ancak kimlik bilgisi toplama ve kötü amaçlı yazılım dağıtımı doğrulanmadı.
• Kesintinin kendisi bu kampanyayla ilişkilendirilmiyor. Microsoft, olayla ilgili güncellemelerinde kötü niyetli faaliyete dair kanıt olmadığını belirtti.

Doğrulama: Neyi Doğruladım, Neyi Doğrulayamadım

Paylaşılan metni, Microsoft’un duyurusu ve bağımsız haber/olay takip kaynaklarıyla satır satır karşılaştırdım. Sonuçlar aşağıdaki tabloda.

Gerçek Olay: 12 Kasım 2026 Microsoft 365 Kesintisi

Kimlik avı e-postalarının inandırıcılığı, kesintinin gerçek olmasından geliyor. Olay Exchange Online ile başladı, Exchange Online’a bağımlı Outlook, Teams, SharePoint Online, Copilot, Intune ve Defender gibi hizmetlere yayıldı. Aşağıdaki saatler, Microsoft yönetim merkezi kayıtlarını aktaran kaynaklardan derlendi ve kaynaklar arasında küçük farklar olabilir. UTC (Coordinated Universal Time, Eş Güdümlü Evrensel Zaman) saatlerinin yanına TSİ (Türkiye Saati, UTC+3) karşılığını ekledim.

Burada kritik nokta şu: kimlik avı kampanyası kesintinin nedeni değil, sonucudur. Saldırganlar, kullanıcıların posta alamadım endişesini kullanıyor.

Kampanya Nasıl Çalışıyor?

1. Kullanıcı kesinti sırasında gerçekten posta alamamış olabilir. Mesajlarınız tutuldu fikri bu yüzden kolay inandırıcı olur.
2. E-posta, Microsoft 365 servis sağlığı bildirimi gibi görünür. Gönderen adı, kuruma özel bir önek ile Outage Notification veya Service Health ifadesinden oluşur. Bu kişiselleştirme, gerçek kesinti bildirimleriyle dolu bir gelen kutusunda mesajı daha zor ayırt edilir hale getirir.
3. Konu satırı Outage - XXXXXX kalıbındadır (altı karakterli bir kod).
4. Gövdede (4) messages held gibi bir sayı, deleted within 24 hours şeklinde zaman baskısı ve sarı bir RESTORE MESSAGES düğmesi bulunur.
5. Düğme, alıcıya özel bir SendGrid tıklama izleme bağlantısına gider. SendGrid meşru bir e-posta gönderim platformudur, burada kötüye kullanılıyor.
6. Bağlantı reallifeaccounting[.]com alan adına, örnek olarak /themelist0.html yoluna yönlendirir.
7. Sonraki adım Microsoft tarafından doğrulanmadı. Faaliyet kimlik bilgisi hırsızlığıyla uyumlu, ancak kimlik bilgisi toplama ve kötü amaçlı yazılım dağıtımı teyit edilmedi.

Gösterge Özeti

Alan adları aşağıda tıklanmayı önlemek için köşeli parantezle (defang) yazılmıştır. Bu adreslere normal bir tarayıcıdan gitmeyin.

E-postayı Nasıl Tanırsınız?

Microsoft Threat Intelligence’ın paylaştığı örnek ekran görüntüsü aşağıda.

Microsoft Threat Intelligence paylaşımındaki örnek e-posta.

Örneğe bakıldığında aşağıdaki işaretler öne çıkıyor. Bu tablo, görüntü üzerinden yaptığım gözlemleri içerir.

Yöneticiler İçin Tespit ve Avlanma (Hunting)

Microsoft, şüpheli mesajları bulmak için Microsoft Defender for Office 365 Threat Explorer’ı, gömülü URL’leri (Uniform Resource Locator) ve kullanıcı tıklamalarını incelemek için Microsoft Defender XDR (Extended Detection and Response) advanced hunting üzerinde EmailEvents, EmailUrlInfo ve UrlClickEvents tablolarını kullanmayı öneriyor. Aşağıdaki Kusto Query Language (KQL) sorguları bu yaklaşımın örnekleridir.

1. Gönderen alan adı veya konu kalıbına göre mesajlar

let kampanyaAlanAdlari = dynamic(["moments-notice.com", "planetmaison.com", "newbooker.com"]);
EmailEvents
| where Timestamp > ago(7d)
| where SenderFromDomain in~ (kampanyaAlanAdlari)
    or SenderMailFromDomain in~ (kampanyaAlanAdlari)
    or Subject matches regex @"(?i)^Outage\s*[^A-Za-z0-9\s]\s*[A-Za-z0-9]{6}$"
| project Timestamp, NetworkMessageId, SenderDisplayName, SenderFromAddress,
    Subject, RecipientEmailAddress, DeliveryAction, DeliveryLocation, ThreatTypes
| order by Timestamp desc

Konu kalıbındaki altı karakterli kodun hangi karakterlerden oluştuğu paylaşılmadı, ben harf ve rakam varsaydım. Gerekirse düzenleyin.

2. Mesajlardaki SendGrid bağlantıları

let kampanyaAlanAdlari = dynamic(["moments-notice.com", "planetmaison.com", "newbooker.com"]);
EmailEvents
| where Timestamp > ago(7d)
| where SenderFromDomain in~ (kampanyaAlanAdlari)
| join kind=inner (
    EmailUrlInfo
    | where Timestamp > ago(7d)
    | where UrlDomain endswith "sendgrid.net"
  ) on NetworkMessageId
| project Timestamp, NetworkMessageId, RecipientEmailAddress, SenderFromDomain,
    Subject, Url, UrlDomain

Mesajdaki bağlantı SendGrid üzerinden yönlendirildiği için reallifeaccounting[.]com adresi EmailUrlInfo içinde görünmeyebilir. Son hedefi tıklama kayıtlarında ve proxy ya da DNS (Domain Name System) günlüklerinde aramak daha güvenilirdir.

3. Kimler tıkladı?

let kampanyaMesajlari = EmailEvents
| where Timestamp > ago(7d)
| where SenderFromDomain in~ (dynamic(["moments-notice.com", "planetmaison.com", "newbooker.com"]))
| project NetworkMessageId, RecipientEmailAddress, Subject;
UrlClickEvents
| where Timestamp > ago(7d)
| where Url has "reallifeaccounting.com"
    or UrlChain has "reallifeaccounting.com"
    or NetworkMessageId in ((kampanyaMesajlari | project NetworkMessageId))
| project Timestamp, AccountUpn, Url, UrlChain, ActionType, IsClickedThrough,
    NetworkMessageId, IPAddress
| order by Timestamp desc

UrlClickEvents verisi, ancak Safe Links tıklama takibi açıksa oluşur. Kayıt yoksa tıklama olmadığı anlamına gelmez. Proxy, güvenlik duvarı ve DNS günlüklerini de kontrol edin.

Threat Explorer tarafında aynı filtreleri (gönderen alan adı, konu) kullanıp mesajları tüm posta kutularından taşıyabilir ya da silebilirsiniz. Silme işleminden önce etkilenen kullanıcı listesini mutlaka dışa aktarın.

Kullanıcı Tıkladıysa: Müdahale Adımları

1. Etkilenen kullanıcıları belirleyin. Yukarıdaki üçüncü sorgu, proxy ve DNS günlükleri.
2. Parolayı sıfırlayın ve oturumları iptal edin. Microsoft Entra ID tarafında kullanıcının oturumlarını iptal edin. PowerShell ile örnek: Revoke-MgUserSignInSession -UserId kullanici@alanadi.com.
3. Oturum açma günlüklerini inceleyin. Alışılmadık konum ve IP adresleri, yeni kayıtlı MFA (Multi-Factor Authentication, çok faktörlü kimlik doğrulama) yöntemleri ve yeni cihaz kayıtlarına bakın.
4. Posta kutusunda kalıcılık arayın. Gelen kutusu kuralları ve yönlendirme: Get-InboxRule -Mailbox kullanici@alanadi.com ve Get-Mailbox kullanici@alanadi.com | Format-List ForwardingSmtpAddress, DeliverToMailboxAndForward.
5. OAuth (Open Authorization) uygulama onaylarını kontrol edin. Kullanıcının yakın zamanda verdiği şüpheli uygulama izinlerini kaldırın.
6. Gönderen alan adlarını ve reallifeaccounting[.]com adresini engelleyin. Tenant Allow/Block List ve ağ katmanındaki (proxy, DNS filtreleme) kuralları kullanın.
7. Veri girilip girilmediğini netleştirin. Microsoft kimlik bilgisi toplamayı doğrulamadığı için, kullanıcıdan sayfaya bilgi girip girmediğini öğrenin. Emin olunamıyorsa girmiş gibi davranın.

Önleme ve Sertleştirme

Kullanıcılara Gönderilebilecek Kısa Bilgilendirme

Sonuç

Bu olay, büyük bulut kesintilerinin ardından gelen kimlik avı dalgasının güncel bir örneği. Kampanyanın teknik olarak sıra dışı bir yanı yok. Etkisini veren şey zamanlama: kullanıcılar gerçekten posta alamadı ve bir açıklama arıyor. Microsoft’un kimlik bilgisi toplamayı henüz doğrulamamış olması riski azaltmıyor, çünkü tıklayan kullanıcı için sonuç aynı şekilde kötü olabilir.

Önerim net: Gönderen alan adlarını ve yönlendirme adresini engelleyin, tıklayan kullanıcıları tespit edin, Safe Links ayarlarınızı gözden geçirin ve kullanıcılarınıza kesinti bilgisinin yalnızca Microsoft 365 admin center üzerinden doğrulanacağını hatırlatın. Microsoft ayrıntılı bir analiz yayımladığında bu yazıyı güncelleyeceğim.

Başka bir yazımızda görüşmek dileğiyle…