Exchange Online Oturumlarındaki Atak Aktivitelerini İzleme – Attacker Activity within Sessions in Exchange Online
Exchange server pek çok şirketin Kurumsal bir doküman yönetim sistemine sahip olmaması nedeni ile tüm şirket bilgilerini bulabileceğiniz son derece değerli bir veri ambarıdır.
Aslen mesajlaşma sistemi olarak tasarlanmış olan exchange server ne yazık ki pek çok şirket için en kritik dokümanların dahil paylaşıldığı bir platform olunca pek çok kötü niyetli kişi için ilk saldırı odağı olabiliyor. Biz sistem ve güvenlik yöneticilerinin de görevi tam olarak burada neler döndüğünü izliyor olmamızdır.
Her ne kadar exchange online başlığı altında bunu yazıyor olsam da aslında pek çok müşterimde yaptığım sağlık taraması raporlarında daha temel açıklar tespit etmiştim. “Managed Full Access” izinleri olarak tanımladığımızın izinlerin bilgi işlem personeli bilgisi dahilinde veya bazen bilgisi dışında kullanıldığını, yani bir veya birden çok kişinin yine bir veya bir den çok kişi için posta kutusuna izinsiz eriştiğini gördüm. Bunun önüne geçmek için en temel yöntemin mailbox Audit açmak olduğunu ve bu sayede gerek izinsiz erişimler gerekse kullanıcının hali hazırda kendi yaptığı ama inkâr ettiği işlemleri raporlayabilirsiniz;
https://www.lepide.com/how-to/track-who-accessed-mailboxes-in-exchange-server-2016.html
Peki benzer bir durumu exchange online için nasıl gerçekleştiriyoruz?
Office 365 tarafındaki yenilikleri yakından takip edenler hatırlayacaktır, uzun süredir müşterilerin istediği bir özellik olan mailbox Audit exchange online üzerinde varsayılan olarak açık değildir. Haziran 2018 sonrasında ise artık Microsoft yeni posta kutuları için artık mailbox Audit özelliğinin varsayılan olarak açık geleceğini açıkladı. Bu aslında konuya bakış açısını ve özellikle güvenliğin önemini gösteriyor. Bana göre çok geç kalınmış bir karar ancak her zaman olaylara iki taraflı bakmaya çalışan birisi olarak, on prem exchange sunucusunda bile müşteriye konuyu anlatırken bu Audit bilgilerinin her bir kullanıcının kendi posta kutusu içerisinde saklandığını bu nedenle ortalama %10 büyüme yapacağını ifade ediyorum. Yani 1TB olan bir veri tabanı için 1.1TB yani 100GB Audit log’ dan bahsediyoruz. Aynı şeyi milyonlarca posta kutusu tutan exchange online için düşünürseniz bunun için ciddi bir storage hazırlığı olması gerektiğini de kabul ediyorum.
Peki öncelikle mevcut durumu bir kontrol edelim;
$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session
Get-Mailbox | fl *Audit*
Gördüğünüz gibi “AuditEnabled” false durumda, yani açık değil.
Tek bir kullanıcıda Mailbox Audit açmak için aşağıdaki gibi bir komut kullanabilirsiniz;
Set-Mailbox -Identity “Hakan Uzuner” -AuditEnabled $true
İsim yerine mail adresini de yazabilirsiniz.
Eğer tüm kullanıcılarda açmak veya kapatmak istiyorsanız;
Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq “UserMailbox”} | Set-Mailbox -AuditEnabled $true
Tüm kullanıcıları çağırıp hepsinde Mailbox Audit açabilirsiniz.
Tabiki Audit açmak yeterli değil, posta kutusunun sahibi, admin ve delege edilmiş kullanıcı olmak üzere 3 ana sınıf için alt sınıflandırmaları ayarlayabilirsiniz. Bunun için aşağıdaki makaleyi inceleyebilirsiniz.
https://docs.microsoft.com/en-us/office365/securitycompliance/enable-mailbox-auditing
Not: Bu bölüm için ÇözümPark üzerindeki makalelerimde çok daha detaylı bilgi var, hatta önerilerim de var, yani admin için hangi loglama başlıklarını, posta kutusu sahibi için hangi loglama başlıklarını, delegasyon yapılan kullanıcılar için hangi loglama başlıklarını açacağınızı görebilirsiniz.
Örneğin benim kullanıcım için kendi yaptığım hareketler, admin hareketleri ve delegasyon verdiğim kullanıcı için bunları logluyorum, siz bunları benim makalemdeki gibi değiştirebilirsiniz;
Peki biraz daha detaya girelim;
Ocak 2019 itibari ile artık biz bu logların içerisinde Session ID isminde bir değer görebiliyoruz. Bu yeni değer sayesinde hesap aktivitelerini daha iyi anlayabiliyoruz.
Session ID, mailbox Audit ve Admin Audit log’ un bir parçasıdır. Bir kodlanmış GUID olan Session ID, Azure AD token’ ı temsil etmektedir.
Session ID sayesinde her bir logon işlemi içerisindeki tüm aktiviteleri takip etmemizi sağlar. Her bir yeni şifre girişinde ise yeni bir session ID tanımlanır.
Ancak burada önemli bir detay yer almaktadır. Özellikle son dönemde office 365 kullanıcı şifrelerinin çaldırılması gibi durumları session id sayesinde çok kolay yakalayabiliyoruz. Ancak kötü niyetli kişi eğer kullanıcının makinesini ele geçirmiş ise bu durumda session id, kötü niyetli kişinin aktivitelerini yakalayamaz çünkü ilgili kişi hali hazırda kullanıcı AD token kullandığı için tek bir session id üzerinden işlem yaparlar.
Session ID’ nin temsil ettiği token sadece Azure AD tarafından üretilmektedir. Bunun kullanabilmek için temel şart ortamınızda basic authentication ile logon işlemini yasaklamanız. Eğer bunu yapmazsanız Session ID ile kötü niyetli kişileri takip etmeniz mümkün olmaz.
Bunun için aşağıdaki makaleyi inceleyebilirsiniz;
Peki tam olarak nasıl takip ediyoruz?
Öncelikle kolay olan yöntem admin center üzerinden aşağıdaki gibi bu logları export etmektedir;
Ama ben daha çok PS kullanıyorum, çünkü daha net sonuçlara ulaşmanızın en kolay yolu bence.
Aşağıdaki bir örnek yer almaktadır;
Search-MailboxAuditLog -Identity hakan -LogonTypes Admin,Delegate -StartDate 1/1/2019 -EndDate 12/31/2019 -ResultSize 2000
Hakan kullanıcısı için 2019 yılı içerisinde yönetici ve delegasyon verdiğim kullanıcılara ait olan logları listelemek için kullanabilirim.
Eğer aynı komut içerisinde birden çok kullanıcı için sorgu çekmek istiyorsanız aşağıdaki gibi yan yana yazabilirsiniz;
Search-MailboxAuditLog -Identity hakan, serkan -LogonTypes Admin,Delegate -StartDate 1/1/2019 -EndDate 12/31/2019 -ResultSize 2000
Ya da benim en çok kullandığım komutu paylaşmak isterim.
Malum kullanıcılar genelde böyle bir mail geldi ama silinmiş ben silmedim noktasında kullanıcı destek ekiplerine çok soru yöneltiyorlar. Klasik bir durum aslında, mail kendi kendine silinmez. Bir kural vardır, genelde kural çıkar. Ama kural yok ise de genelde kullanıcının çıktığını görüyoruz. Peki nasıl görüyoruz? Aşağıdaki komut yardımı ile;
Search-MailboxAuditLog -Identity hakan -LogonTypes Owner -ShowDetails -StartDate 1/1/2019 -EndDate 3/1/2019 | Where-Object {$_.Operation -eq “HardDelete”}
Yani shift delete ile geri dönüşüm kutusuna gitmeden silme operasyonuna biz “HardDelete” ismini veriyoruz. Bu işlemi eğer kullanıcı kendisi yapmış ise “Logon type bölümüne owner yazdık yani kullanıcının kendi hareketleri arasında arama yaptığımızı görebiliriz.
Peki sonuçlarda bizim takip etmemiz gereken session ID yi nasıl gözlemliyoruz;
PS ile öncelikle session ID leri aşağıdaki gibi bir tabloda birleştirirsek hızlıca bir anormallik olduğunu anlayabiliriz;
Yeşil olanlar kullanıcının kendi hareketleri olup kırmızı olanların kötü niyetli kişiler olduğunu varsayıyoruz. Hızlıca bir kural yazdıklarını fark ediyoruz. Bu office 365 de ne yazık ki son dönemde gördüğümüz bir atak yöntemi, şifreyi alıyor, mail trafiğini kendisi yönetmek için maillerin bir kopyasını kendisine gönderip gelen maili direkt siliyor. Bu nedenle kullanıcıya ilgili kişiden mail gelmiyor gibi duruyor hatta hiç mail gelmiyor, tüm trafiği kötü niyetli kişi yönetiyor.
Peki bu ID leri nasıl buluyoruz, eğer mailbox audit açık ise aşağıdaki gibi bir komut seti ile bunlara kolaylıkla ulaşabilirsiniz;
Search-MailboxAuditLog -Identity hakan.uzuner -LogonTypes Owner -ShowDetails -StartDate 1/1/2019 -EndDate 3/1/2019 | Where-Object {$_.Operation -eq “Update”}
Yukarıdaki komutun çıktısında pek çok log gelecektir, bir tanesini örnek olarak inceliyorum;
Gördüğünüz gibi ikinci bölümde (ben resmi iki parça aldığım için) sessionId detayını görebiliyoruz. O zaman bu çıktıyı biraz daha sadeleştirelim;
Search-MailboxAuditLog -Identity hakan.uzuner -LogonTypes Owner -ShowDetails -StartDate 1/1/2019 -EndDate 3/1/2019 | Where-Object {$_.Operation -eq “Update”} | select ClientIPAddress,OperationResult,Operation,FolderPathName,LastAccessed,SessionId
Ajanda için yapılan güncellemeleri tarih ve sessionid olacak şekilde sınıflandırdım;
Gördüğünüz gibi farklı tarihler var ancak SessionID aynı.
Biraz daha geniş bakabilirsiniz;
Search-MailboxAuditLog -Identity hakan.uzuner -LogonTypes Owner -ShowDetails -StartDate 1/1/2019 -EndDate 3/1/2019 | select ClientIPAddress,LastAccessed,SessionId
Tabi bunun için en temiz yöntemi ürün kullanmak.
Bu ürün sayesinde bu logları sahip olduğunuz SIEM’ e kolayca entegre edebilirsiniz.
Ya da ben uğraşmak istiyorum derseniz bu PS ile 24 saatlik logları bir dizine alır oradan import edersiniz
https://practical365.com/exchange-server/powershell-script-report-mailbox-audit-log-entries/
Ek olarak bir şekilde birileri posta kutusunu ele geçirir ise ilk yapacağı işlerden birisi yönlendirme kuralı oluşturmaktır, bu konuda Microsoft Office 365 üzerinde otomatik bir alert de görebilirsiniz. Yani organizasyon içerisinde herhangi birisi bir inbox rule oluşturur ise bunu alet bölümünde görebiliyoruz. Hatta ilgili ayarları yapmışsanız da bu uyarılar size mail olarak düşecektir.
Evet belki gündelik hayat için çok yorucu bir makale oldu ama ne yazık ki danışmanlık işimizin bir parçası da güvenlik olduğu için böyle case’ leri çözmek için bu teknolojileri kullanıyor ve sizler içinde makale haline getiriyoruz.
Makalemin sonuna geldik, umarım faydalı bir makale olmuştur.
Kaynak
Eğer ürün hakkında daha fazla bilgi almak veya POC yapmak için Türkiye de ki resmi dağıtıcı ile görüşebilirsiniz.
[email protected] ye mail atmanız halinde size en uygun bayi üzerinden POC desteği sunulacaktır.
