Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

BTRisk Zararlı Yazılım Analizi Eğitimi Sunumu - Bölüm 1

1,633 views

Published on

BTRisk Zararlı Yazılım Analizi Eğitimi Sunumu - Bölüm 1

Published in: Education
  • Be the first to comment

BTRisk Zararlı Yazılım Analizi Eğitimi Sunumu - Bölüm 1

  1. 1. ZARARLI YAZILIM ANALİZİ EĞİTİMİ BÖLÜM-1 İSTANBUL blog.btrisk.com @btrisk /btrisktv /btrisk
  2. 2. BTRİSK HAKKINDA TANIŞMA Pentest & BT Denetimi ISO27001 Danışmanlık Hizmetleri BG Operasyon Hizmetleri
  3. 3. Göreviniz, Deneyiminiz ve Eğitimden Beklentileriniz Nelerdir? TANIŞMA
  4. 4. MALWARE ANALİZİNİN AMAÇLARI • Zararlı Yazılımın Amaçları ve Verdiği Zarar Nedir?: Zararlı yazılım bir anti-malware aracı tarafından tespit edilmiş ve karantinaya alınmış olabilir. Ancak bir malware analizi yapmadan saldırının amaçlarını, potansiyel veri sızmalarını ve diğer zararları tam olarak tespit etmek mümkün olmayacaktır. • Başka Hangi Sistemlerde Mevcut Olabilir?: Zararlı yazılımı belli bir bilgisayar üzerinde tespit etmiş ve ortadan kaldırmış olmanız onun ağınız üzerindeki başka bir sistem üzerinde bulunmayacağı anlamına gelmez. Yapacağınız analizle Indicators of Compromise (IOC) tespiti yaparak mevcut diğer enfekte olmuş sistemleri veya daha sonra gerçekleşebilecek enfeksiyonları tespit edebilirsiniz. IOC'lere örnek olarak dosya hash'i, dosya içinde geçen bir bölüm, oluşturulan bir registry değeri, belli bir ağ aktivitesi verilebilir.
  5. 5. LAB ORTAMI • İzolasyon: Lab ortamında amacı ve yöntemleri bilinmeyen bir yazılımı dinamik analize tabi tutacağımızdan izolasyon ihtiyacı en yüksek seviyededir. • Hızlı Geri Dönebilme: Zararlı yazılımın sistem üzerindeki etkilerini defalarca görme ihtiyacımız olabileceğinden sistemi temiz duruma hızla döndürebilmek ihtiyacımız olacaktır. • Farklı İşletim Sistemleri: Zararlı yazılımın platform bağımlılığı bulunabileceğinden lab ortamı olarak 32bit, 64bit, yamalı, yamasız, çeşitli imajları kullanmamız gerekebilir. • Araçlar: Zararlı yazılımın dinamik analiz sırasında izlenebilmesi ve statik analizinin yapılabilmesi için bir araç envanterine ihtiyacımız olacaktır. Ancak hangi aracı ne için kullandığımızı iyi bilmek aracın fonksiyonalitesinden daha önemlidir.
  6. 6. LAB ORTAMI İZOLASYON VM – Hedef Bilgisayar (MS Windows) VM – Honeypot (Çeşitli sahte servisleri barındırır) HOST BİLGİSAYAR İnternet Custom Network Segmenti
  7. 7. LAB ORTAMI İZOLASYON VM – Hedef Bilgisayar (MS Windows) VM – Honeypot (Çeşitli sahte servisleri barındırır) HOST BİLGİSAYAR İnternet Custom Network Segmenti ZARARLI YAZILIMIN İNTERNET ERİŞİMİ OLMASI HALİNDEKİ DAVRANIŞINI İZLEMEMİZ GEREKİYORSA MODEM DSL / 3G NAT
  8. 8. LAB ORTAMI İZOLASYON VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit • Alternatif MS Windows versiyonlarını • Alternatif dillerde dağıtımı yapılan Windows versiyonlarını • Yamalı / yamasız • Çeşitli 3. parti araçlar ve yazılımların çeşitli versiyonlarıyla (Adobe, Java, Internet Explorer, v.d.) DENEMEK DURUMUNDA OLABİLİRSİNİZ
  9. 9. LAB ORTAMI İZOLASYON VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit • Firewall pasif durumda olmalıdır • Herhangi bir anti-virüs aracı aktif olmamalıdır • Kullandığınız işletim sistemi üzerinde User Account Control, ASLR, DEP kontrolleri aktif ise bunu analiz aşamalarınızda aklınızda bulundurmalısınız (çünkü bazı adımlarınızda buna uygun düzenleme yapmanız gerekebilir, örneğin bellekten bir imajı dump ederken dump aracına mevcut modül başlangıç adresini vermeniz gerekebilir)
  10. 10. LAB ORTAMI İZOLASYON VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit User Account Control seviyesinin en aza çekilmesi (bu ayar UAC kontrolünün tamamen kaldırıldığı anlamına gelmemektedir)
  11. 11. LAB ORTAMI İZOLASYON VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit bcdedit.exe /set {current} NX AlwaysOff Data Execution Prevention'ın iptal edilmesi: DEP (ya da No Execute – NX) kontrolü stack ve heap overflow açıklıklarında bu alanlarda kod çalıştırılmasını engeller.ÖNEMLİ: Komut satırını Run as Administrator olarak başlatınız.
  12. 12. LAB ORTAMI İZOLASYON VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit REG ADD "HKLMSYSTEMCurrentControlSetControlSession ManagerMemory Management" /f /v MoveImages /t REG_SZ /d 0 Address Space Layout Randomization'ın iptal edilmesi: ASLR kontrolü bu özelliği destekleyen uygulamaların rastgele bellek alanlarından başlatılarak bellek taşma açıklıklarının hedefine ulaşma ihtimalini azaltmayı amaçlar. ÖNEMLİ: Komut satırını Run as Administrator olarak başlatınız.
  13. 13. LAB ORTAMI İZOLASYON VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit Windows Explorer uygulamasında Tools / Folder Options menüsünde bilinen dosya uzantılarının gizlenmesi v.d. Gizleme ayarlarının iptal edilmesi incelemeyi kolaylaştıracaktır.
  14. 14. LAB ORTAMI İZOLASYON VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit
  15. 15. LAB ORTAMI İZOLASYON VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit VM - Honeypot
  16. 16. LAB ORTAMI İZOLASYON VM – Honeypot Kali Linux Üzerinde: • DNS servisi • Sahte HTTP, HTTPS, FTP, SMTP, v.b. çalıştırılabilen • Çalıştırdığı servislerle ilgili loglama yapabilen (kriptolu servisler için gerekli olabilir, diğerleri Wireshark ile izlenebilir) • Mümkünse yamaları tam HERHANGİ BİR İŞLETİM SİSTEMİ OLABİLİR
  17. 17. LAB ORTAMI İZOLASYON VM – Honeypot Kali Linux VM – Hedef Bilgisayarlar aynı ağ bölümü
  18. 18. LAB ORTAMI İZOLASYON VM – Honeypot Kali Linux Statik IP adres tanımı
  19. 19. LAB ORTAMI İZOLASYON VM – Honeypot Kali Linux
  20. 20. LAB ORTAMI İZOLASYON VM – Honeypot Kali Linux Hedef Bilgisayara Erişim Testi
  21. 21. LAB ORTAMI İZOLASYON VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit Honeypot Sunucuya Erişim Testi
  22. 22. LAB ORTAMI HIZLI GERİ DÖNEBİLME VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit Hedef bilgisayarın farklı aşamalarında sanal makine sunucusunun snapshot alma özelliğinden faydalanmalıyız
  23. 23. LAB ORTAMI ARAÇLAR Dinamik Analiz • Çalışma anında dosya ve registry aktivitesi izleme • Çalışma anında ağ iletişimi izleme • Binary debugger ve çeşitli pluginleri (ör: dump etme plugini) Statik Analiz • Packer, encryptor v.b. signature analizi yapabilen bir araç • Disassembler • PE dosya inceleme, string ayıklama ve inceleme araçları Yardımcı Araçlar • Hash hesaplama aracı • Metin dosyası inceleme ve not alma aracı
  24. 24. LAB ORTAMI ARAÇLAR Neden kullanacağımızı iyi bildiğimiz ve gereksiz olanları arındırılmış bir araç envanterini kullanmalıyız
  25. 25. LAB ORTAMI ARAÇ KURULUMLARI VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit capturebat.exe – Dosya, Registry, Network aktiviteleri izleme aracı [Dinamik Analiz aracı]
  26. 26. LAB ORTAMI ARAÇ KURULUMLARI VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit Malcode Analyst Pack [MAP] – çeşitli küçük statik analiz araçlarını barındıran bir paket
  27. 27. LAB ORTAMI ARAÇ KURULUMLARI VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit Immunity Debugger – Binary Debugger / Disassembler [Dinamik Analiz Aracı]
  28. 28. LAB ORTAMI ARAÇ KURULUMLARI VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit Wireshark – Network Sniffer [Dinamik Analiz Aracı]
  29. 29. LAB ORTAMI ARAÇ KURULUMLARI VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit Notepad++ - Dosya okuma ve not alma aracı (notepad uygulamasından kesinlikle daha çok işimize yarayacak)
  30. 30. LAB ORTAMI ARAÇ KURULUMLARI VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit IDA Pro – Interaktif Disassembler [Statik Analiz Aracı]
  31. 31. LAB ORTAMI ARAÇ KURULUMLARI 010 editörünün deneme süresi 30 gün olduğundan daha uzun süreler için HxD editörü kullanılabilir. VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit 010 Editor / HxD – Hexadecimal Editörler [Statik Analiz Aracı]
  32. 32. LAB ORTAMI ARAÇ KURULUMLARI VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit Resource Hacker – PE Resource section analiz aracı [Statik Analiz Aracı]
  33. 33. LAB ORTAMI ARAÇ KURULUMLARI Kurulumlar sonrasında bir snapshot daha almakta fayda var VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit
  34. 34. ANALİZ METODU STATİK ANALİZ DİNAMİK ANALİZ • Statik ve dinamik analizlerin tamamen birbirleriyle ilişkisiz yapılmasından ziyade gerek duyulan adımda gerekli metodun kullanılması gerekir • Analize statik veya dinamik yöntemlerle başlanabilir • Analizin kapsamının yeterli olduğundan emin olabilmek için bir rapor formatı hazırlanarak kontrol listesi olarak kullanılabilir
  35. 35. ÖRNEK RAPOR ALANLARI • Yapılan çalışmalarla ilgili not alma, ekran görüntüsü, kayıt tutma amacıyla bir mindmapper uygulaması (ör: Freemind) kullanılabilir • Yönetici özeti dışında kalacak teknik rapor alanları ana hatları ile aşağıdaki gibi olabilir
  36. 36. ANALİZ ZARARLI YAZILIMIMIZ Öntanımlı olarak bilinen dosya uzantılarının gizlendiği bir sistem üzerinde zararlının görünümü Zararlı gizlenmek için bir PDF icon'u kullanmış. Ayrıca adı da sosyal mühendislik senaryosunu destekleyecek nitelikte verilmiş.
  37. 37. ANALİZ ZARARLI YAZILIMIMIZ Uzantıların gizlenmesinin kaldırıldığında dosya uzantısı "scr" olarak görülüyor. Sıradan bir kullanıcı bu uzantıyı tanıyamasa da "Screen Saver" uygulamalarına verilen bu uzantı da uygulama çift tıklandığında işletim sistemi tarafından çalıştırılmasına neden olacaktır.
  38. 38. ANALİZ İLK ADIM • Normalde eğer zararlı yazılımın sizin açınızdan bir mahrem özelliği yoksa (yani başkalarının sizin veya size yönelik tehdidin hakkında bilgi edinmesini sakıncalı kılan bir durum yoksa) ilk olarak zararlı yazılımı Virus Total sitesine ve/veya online sandbox analiz platformlarından birisine gönderebilirsiniz. • Bu size zararlının bilinen bir zararlı mı yoksa size özel geliştirilmiş bir zararlı mı olduğu hakkında hızlı bir fikir verebilir.
  39. 39. ANALİZ İLK ADIM • Ancak biz eğitim amacıyla geliştirdiğimiz zararlının tüm özelliklerini biliyoruz ve mümkün olduğunca anti-virüs firmalarının da eline geç geçmesini istiyoruz. • Böylece anti-virüs araçlarının etkinliğini bu örnekle de değerlendirebiliyoruz. • Bu yüzden yazılımı LÜTFEN Virus Total'e yüklemeyiniz !!!
  40. 40. ANALİZ HONEYPOT SERVİSLERİNİN BAŞLATILMASI Servisleri simüle etmek için Kali ile öntanımlı olarak gelen "inetsim" uygulamasını kullanacağız Bu uygulamanın konfigürasyon dosyası olan /etc/inetsim/inetsim.conf içinde tüm servisleri öntanımlı olarak başlatılmaktadır.
  41. 41. ANALİZ HONEYPOT SERVİSLERİNİN BAŞLATILMASI Servislerin bind edilmesi için tüm arayüzleri kullanabilmek için bu satıra "0.0.0.0" girelim.
  42. 42. ANALİZ HONEYPOT SERVİSLERİNİN BAŞLATILMASI Tüm DNS isteklerine yanıt olarak honeypot sistemimizin IP adresinin döndürülmesi için bu alana "10.0.0.1" girelim. Bu sayede örneğin zararlı bir HTTP erişimi kuracak ise erişim kuracağı alan adı ne olursa olsun honeypot sistemimizde çalışan HTTP servisi ile bağlantı kuracaktır.
  43. 43. ANALİZ HONEYPOT SERVİSLERİNİN BAŞLATILMASI Bazı kullanıcılar aşağıdaki gibi bir hata alabilirler. Bu hata DNS servisinin başlatılmasını engellemektedir. Nedeni de inetsim uygulamasının (aslında script'inin) başlatma parametresi olan –T opsiyonunun ürettiği bir güvenlik hatasıdır.
  44. 44. ANALİZ HONEYPOT SERVİSLERİNİN BAŞLATILMASI Söz konusu opsiyon /usr/bin/inetsim dosyasının ilk satırında görülebilir.
  45. 45. ANALİZ HONEYPOT SERVİSLERİNİN BAŞLATILMASI Hatayı almamak için T opsiyonunu silmelisiniz.
  46. 46. ANALİZ HONEYPOT SERVİSLERİNİN BAŞLATILMASI "inetsim" uygulaması sağlıklı olarak başladığında DNS servisi başlatılmış olacaktır.
  47. 47. ANALİZ HONEYPOT SERVİSLERİNİN BAŞLATILMASI Ayrıca HTTP ve HTTPS servislerinin de başlatıldığını görebilirsiniz.
  48. 48. ANALİZ HONEYPOT SERVİSLERİNİN BAŞLATILMASI Hedef Bilgisayar üzerinde hangi alan adına istek yaparsanız yapın 10.0.0.1 IP adresinde hizmet veren HTTP sunucusuna ulaşacaksınız. VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit
  49. 49. ANALİZ HONEYPOT SERVİSLERİNİN BAŞLATILMASI VM – Hedef Bilgisayar Windows 7 Pro – 32 Bit www.btrisk.com alan adına yapılan ping istekleri de 10.0.0.1 IP adresine gönderilmektedir.
  50. 50. ANALİZ DİNAMİK ANALİZ [capturebat.exe] Capturebat uygulaması bir honeypot uygulaması. Çalışan proseslerin dosya, registry ve ağ hareketlerini kayıt altına alıyor. Bu uygulamayı komut satırından (cmd.exe) çalıştırmamız lazım, ancak herhangi bir yer den çalıştıramadığımızdan C:/Program Files/Capture dizininden başlatmamız lazım.
  51. 51. ANALİZ DİNAMİK ANALİZ [capturebat.exe] Şu komutla izleme uygulamamızı başlatıyoruz: capturebat.exe -cn -l mlwlog.txt -c: Silinen ve değiştirilen dosyaları kaydet -n: Ağ paketlerini pcap formatında kaydet -l: Log kayıtlarını ismi verilen dosyada sakla
  52. 52. ANALİZ DİNAMİK ANALİZ [capturebat.exe] Zararlı uygulamamızı başlatıyoruz. Bize bir PDF dosyası görüntüledi ve bir uygulama da hata aldı.
  53. 53. ANALİZ DİNAMİK ANALİZ [capturebat.exe] Ctrl+C komutuyla capturebat.exe'yi sonlandırıyoruz.
  54. 54. ANALİZ DİNAMİK ANALİZ [capturebat.exe] mlwlog.txt (veya siz hangi ismi vermişseniz) dosyasını açtığımızda log kayıtlarını görebiliriz.
  55. 55. ANALİZ DİNAMİK ANALİZ [capturebat.exe] Dikkate değer satırlar: "13/10/2017 17:32:6.272","file","Write","C:UsersbtriskDesktopfatura_pdf.s cr","C:WindowsSystem32netdrv.exe" • Zararlımız bir dosya yazmış görünüyor. • Zararlı yazılımlar genellikle ya resource section'larında raw veri olarak barındırdıkları bir dosyayı veya kendilerini disk üzerinde farklı yerlere kopyalayabilirler. Sizin denemenizde muhtemelen farklı bir metin görünecektir!
  56. 56. ANALİZ DİNAMİK ANALİZ [capturebat.exe] MD5 Hash Değeri: 815E2E11882093CCE54C789D5CB74A7C Zararlımızın hash değerini kopyaladığı dosya ile aynı olup olmadığını anlamak için hesaplayalım.
  57. 57. ANALİZ DİNAMİK ANALİZ [capturebat.exe] MD5 Hash Değeri: 815E2E11882093CCE54C789D5CB74A7C Her iki dosyanın da hash değeri aynı, demek ki kendisini bir başka dizine bir başka isimle kopyalamış.
  58. 58. ANALİZ DİNAMİK ANALİZ [capturebat.exe] Dikkate değer satırlar: "13/10/2017 17:32:6.303","file","Write","C:UsersbtriskDesktopfatura_pdf.s cr","C:WindowsSystem32menu.pdf" • Zararlımız bir de PDF dosyası yazmış. • Daha önce de belirttiğimiz gibi PE dosyaları resource olarak raw veri taşıyabilmekte ve bunları drop edebilmektedir. Burada gerçekleşen durum muhtemelen böyle birşey olmalı. Sizin denemenizde muhtemelen farklı bir metin görünecektir!
  59. 59. ANALİZ DİNAMİK ANALİZ [capturebat.exe] Dosyayı açmadan bir göz atmak için 010 editör ile dosyayı inceleyebiliriz.
  60. 60. ANALİZ DİNAMİK ANALİZ [capturebat.exe] Dosyanın ilk bölümlerinden PDF gibi görünüyor. Hatta 010 editör bizim için aşağıda da parse etmiş.
  61. 61. ANALİZ DİNAMİK ANALİZ [capturebat.exe] Dosyayı açtığımızda bir PDF dosyası olduğunu görebiliyoruz.
  62. 62. ANALİZ DİNAMİK ANALİZ [capturebat.exe] Dikkate değer satırlar: "13/10/2017 17:32:6.350","registry","SetValueKey","C:UsersbtriskDesktopfa tura_pdf.scr","HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun RunSysControl" • Bir registry değeri atanmış. • Bu registry değerini ilginç kılan durum bir autorun registry değeri olması. Autorun değerleri sistem her reboot ettiğinde buradaki değerlere atanmış uygulamaların çalışmasına imkan verdiğinden zararlı yazılımlarca sıklıkla kullanılmaktadır. Sizin denemenizde muhtemelen farklı bir metin görünecektir!
  63. 63. ANALİZ DİNAMİK ANALİZ [capturebat.exe] Dikkate değer satırlar: "13/10/2017 17:32:6.397","registry","SetValueKey","C:UsersbtriskDesktopfa tura_pdf.scr","HKCUSoftwareMicrosoftWindowsCurrentVersionInt ernet SettingsProxyEnable" • Bir registry değeri daha atanmış. • Buradaysa ilgimizi çeken konu erişilen registry değerinin bir Internet Explorer değeri olması. Bu kayıt uygulamanın bir HTTP erişiminde bulunduğuna ve Internet Explorer API'lerini kullandığına dair bir iz olabilir.
  64. 64. ANALİZ DİNAMİK ANALİZ [Wireshark] capturebat.exe'nin işlevlerinden birisi de ağ paketlerini PCAP formatında saklaması. Aynı analizi Wireshark veya farklı bir sniffer'la da yapabilirdik.
  65. 65. ANALİZ DİNAMİK ANALİZ [Wireshark] PCAP dosyasının içeriğini Wireshark ile izleyebiliriz. Ağ hareketlerini izlediğinizde www.btr-mlwsunucu.com adlı alan adı için bir DNS isteği gönderildiğini görebilirsiniz.
  66. 66. ANALİZ DİNAMİK ANALİZ [Wireshark] DNS isteğini takip eden paketlerde de bu sunucu ile kurulan bir TCP bağlantısını (bir HTTP bağlantısını) görebilirsiniz.
  67. 67. ANALİZ DİNAMİK ANALİZ [Wireshark] Giden ve gelen paketler içindeki yazılabilir karakterleri izlemek için Wireshark'ın "Follow / TCP Stream" fonksiyonalitesini kullanabiliriz.
  68. 68. ANALİZ DİNAMİK ANALİZ [Wireshark] Yapılan HTTP isteğinde paket.bin adlı bir dosyanın talep edildiğini görebiliyoruz. Yanıt iste inetsim'den geldiğinden zararlının beklediği türden bir veri barındırmadığı muhakkak.
  69. 69. ANALİZ DİNAMİK ANALİZ [Wireshark] alert tcp any any -> any 80 (msg:'BTRMLW Aktivitesi'; content:"btr-mlwsunucu"; sid:9000001;) Malware aktivitesinin tespiti için kullanılabilecek bir SNORT kural örneği
  70. 70. ANALİZ STATİK ANALİZ [strings] Binary executable dosyaların içinde de pek çok metin (string) bulunabilir. Bu metinler bize uygulamanın fonksiyonalitesi hakkında fikir verebilir. ASCII ve Unicode String'ler • ASCII string'lerde her bir karakter 1 byte'lık bir alan kaplar. String'in sonu da bir null byte ("0x00") ile belirlenir. • Unicode string'lerde karakterler İngilizce dışındaki dillerde kulanılan karakterleri de karşılayabilmek için daha geniş (2 byte'lık) bir alan kullanırlar. String'in bitişi de 2 null byte ile belirtilir.
  71. 71. ANALİZ STATİK ANALİZ [strings] String analiz araçları arka arkaya belli sayıda yazılabilir (printable) karakteri bulmayı amaçlar. Elbette pek çok durumda şans eseri dosyanın aslında metin olmayan bölümlerinde de yazılabilir karakterler arka arkaya sıralanmış olabilir. Strings analizi yapan pek çok araç mevcuttur: • Unix ve Windows (Sysinternals, Malcode Analysis Pack) strings araçları • Interactive Disassembler (IDA Pro) Önemli: Bazı araçlar Unicode string'leri bulamayabilir.
  72. 72. ANALİZ STATİK ANALİZ [strings] Malcode Analysis Pack (MAP) Strings aracı
  73. 73. ANALİZ STATİK ANALİZ [strings] Daha anlamlı string'ler bulmak için string boyutunu artırabiliriz
  74. 74. ANALİZ STATİK ANALİZ [strings] Strings aracı Unicode string'lerini de tespit edebiliyor. Ancak bu dosyada hiçbir Unicode string bulamamış. Diğer stringler de hem anlamlılık hem de sayı bakımından zayıf sayılır.
  75. 75. ANALİZ STATİK ANALİZ [PEview] Portable Executable (PE) dosya formatına daha sonra değineceğiz. Ancak uygulamanın Import Address Table'ına göz attığımızda çok az sayıda kullanılan sistem API'ı görüyoruz. Bu tespitler uygulamanın packed olma ihtimalini artırıyor.
  76. 76. ANALİZ STATİK ANALİZ [PEview] Aslında eğitimli gözler için PE dosyasının section isimleri hemen bu dosyanın UPX (the Ultimate Packer for eXecutables) ile pack'lendiğini ele veriyor.
  77. 77. ANALİZ STATİK ANALİZ [PEview] PE dosya formatı ile ilgili detaylara girmeyeceğiz, ancak bu aşamada gördüğünüz UPX0 section'ının Size of Raw Data'sının "0" olması bir gariplik olduğuna işaret ediyor. Çünkü disk üzerinde bir veri barındırmayan bu section için Virtual Size değeri 0x6600 olan bu dosya için bellekte bir yer ayrılacak. Bu tipik bir packer yöntemi, unpack edilen dosya bellekteki bu alana yazılacak, ancak diskte bu alanın büyüklüğü "0".
  78. 78. ANALİZ STATİK ANALİZ [die – Detect It Easy] Packlenmiş veya encode edilmiş olduğundan şüphelendiğimiz dosyaların hangi araç veya yöntemle kodlandığını hızlı bir biçimde incelemek için pek çok dosya formatını ve kodlama yöntemini tanıyan DIE, PEiD veya benzeri bir araç da kullanabiliriz.
  79. 79. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Pack'lenmiş bir dosya üzerinde aşağıdaki statik analiz çalışmalarını yapamayız: • String analizi yapamayız (çünkü sıkıştırılmış veya encode edilmişlerdir) • Import Address Table analizi yaparak fonksiyonalitesine yönelik bir tahminde bulunamayız (çünkü sadece packer'ın IAT'si görülebilir) • ve elbette encode / pack edilmiş kod bölümünü disassemble edemeyiz. Ancak yine de büyük oranda dinamik analiz yapma imkanımız vardır. Dolayısıyla zararlı yazılımı unpack edemesekte tüm yollar kapanmış olmayacaktır.
  80. 80. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Unpack Etme Yöntemleri Bir dosyanın unpack edilmesi için aşağıdaki yöntemler izlenebilir: • Unpacker ile: Mevcutsa unpacker uygulaması ile uygulamanın orjinal veya orjinale yakın haline geri döndürülmesi • Manuel dump ile: Bir unpacker uygulaması yoksa dinamik olarak uygulamanın bellekte unpack edilmesi sonrasında dump edilmesi
  81. 81. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekte Unpack Edilmiş Dosyanın Dump Edilmesi ve IAT Problemi • Bellekte unpack edilmiş bir uygulama diske yazıldığında bu dosyanın orijinal Import Address Table'ı olmayacak, dolayısıyla da çalıştırılamayacaktır. Çünkü packer uygulamasının unpack eden bileşeni uygulamanın kullandığı kütüphaneleri belleğe yükleme ve uygulamanın kullandığı fonksiyonların adreslerini belirleme işlemini dinamik olarak yapacak ve fonksiyon adresleri de o çalışma durumunda geçerli adresler olacaktır. (Bu kavramları tam olarak anlayabilmek için PE dosya formatını, OS loader'ın belleğe yükleme yöntemini ve ASLR ile address randomization kavramlarını bilmeniz gerekmektedir)
  82. 82. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekte Unpack Edilmiş Dosyanın Dump Edilmesi ve IAT Problemi • Import Address Table'ı tekrar oluşturmak için kullanılabilecek araçlar bulunmaktadır (ör: ImportREC veya Ollydbg extension'ları). Ancak bu araçlar çoğunlukla yetersiz kalmaktadır. Bu durumda da manuel olarak IAT'nin oluşturulması gerekir. Bu çalışma zaman alan ve detaylı bir çalışma gerektirir. • IAT'si doğru oluşturulmamış olsa da unpack edilmiş bir uygulama üzerinde string incelemesi ve disassembly analizleri yapılabilir.
  83. 83. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ UPX ile unpack etme UPX'in Linux versiyonu olduğu gibi Windows versiyonu da var Bu yüzden unpack etme işlemini hedef sistem üzerinde de Windows versiyonuyla yapabiliriz
  84. 84. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ UPX ile unpack etme UPX "-d" opsiyonu ile UPX ile compress edilmiş bir dosyayı decompress etmek için de kullanılabiliyor
  85. 85. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ UPX ile unpack etme upx -d ..fatura_pdf.scr -o fatura_pdf-decompress.exe
  86. 86. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ UPX ile unpack etme Henüz PE dosya formatı ile ilgili bir çalışma yapmadık, ancak bu noktada UPX'in decompress fonksiyonu ile dosyanın orijinal PE dosya formatına döndüğümüzü belirterek yetinelim Görüldüğü gibi section isimleri UPX0 ve UPX1 gibi isimlerden .text, .rdata, .data, v.d. şekline geldi
  87. 87. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ UPX ile unpack etme Import Address Table (IAT)'ı da tam olarak oluşturulmuş olan dosyamız üzerinde zararlı yazılımın kullandığı Windows API'lerini inceleyebilmeye ve dolayısıyla işlevlerini anlayabilmeye daha yakınız
  88. 88. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ UPX ile unpack etme Malcode Analysis Pack (MAP) Strings aracı String analizinde kaldığımız yerden biraz ilerleyelim
  89. 89. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ UPX ile unpack etme Bu defa Unicode string'ler de dahil olmak üzere (minimum 8 karakterden oluşan) 651 string'i gözlemleyebildik
  90. 90. ANALİZ STATİK ANALİZ [strings] Dikkate değer string'ler: C:OrnekSaldirganfatura_pdfReleasefatura_pdf.pdb • ASCII string'ler arasında bulunan bu string'i PE dosyasını incelerken de göreceğiz. Buradaki ham haliyle değerlendirdiğimizde zararlı yazılımı geliştiren kişinin bilgisayarındaki bir dizine işaret ettiğiniz söyleyebiliriz.
  91. 91. ANALİZ STATİK ANALİZ [strings] Dikkate değer string'ler: DLL ve API fonksiyon isimleri de string analizimizde karşımıza çıkıyor Bu bilgiler yine PE dosyasını incelerken Import DLL Names ve Import Hints/Names karşılaşacağımız import edilmiş kütüphane ve fonksiyon bilgileri
  92. 92. ANALİZ STATİK ANALİZ [strings] Dikkate değer string'ler: Copyright (c) by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. • Bu tür bilgilerin önemli olup olmadığına ilişkin kanaatleriniz zararlı yazılım analizlerinizi tekrarladıkça yerleşecektir. P.J. Plauger ismini internette araştırdığımızda bu kişinin C ve C++ diliyle ilgili standartlarda lisans haklarının bulunduğunu görebiliriz. Dolayısıyla yukarıda gördüğümüz metnin bu entellektüel haklarla ilgili yasalara uyum gereği olarak derleyici / linkleyici tarafından dosyaya yerleştirildiğini düşünebiliriz.
  93. 93. ANALİZ STATİK ANALİZ [strings] Dikkate değer string'ler: Normalde bir PDF dosyasının ilk byte'larında görebileceğimiz bu metin de ilginç. Bu konudaki şüphelerimizi PE dosya formatını incelediğimizde daha net biçimde doğrulama imkanımız olacak.
  94. 94. ANALİZ STATİK ANALİZ [strings] Dikkate değer string'ler: Unicode string'ler arasında aşağıdaki exe dosya ismine benzer verilere de rastlıyoruz: • apnputil.exe • netdrv.exe • expraw.exe • igfxperso.exe • juschedule.exe • rundll.exe • taskhost32.exe • winlogon32.exe • splwow.exe • netsess.exe Hatırlayın; capturebat.exe ile yaptığımız dinamik analizde bunlardan bir veya daha fazlasını gözlemlemiştik.
  95. 95. ANALİZ STATİK ANALİZ [strings] UNICODE string'ler ile ilgili bir not: • Visual Studio ile geliştirilen C++ uygulamalarında WCHAR veri tipindeki string'ler sıklıkla kullanılır. Bu nedenle kullandığınız string analiz aracının Unicode string'leri de tespit edebilmesi son derece önemlidir. • Örneğin Linux ile gelen "strings" aracı sadece ASCII string'lerini dökebilir.
  96. 96. ANALİZ STATİK ANALİZ [strings] Dikkate değer string'ler: Unicode string'ler arasında aşağıdaki pdf dosya ismine benzer verilere de rastlıyoruz: • manual.pdf • instructions.pdf • installation.pdf • readme.pdf • menu.pdf • WindowsClient.pdf • UserMan.pdf • description.pdf • ApplicantForm.pdf • form.pdf Hatırlayın; capturebat.exe ile yaptığımız dinamik analizde bunlardan bir veya daha fazlasını gözlemlemiştik.
  97. 97. ANALİZ STATİK ANALİZ [strings] Dikkate değer string'ler: Registry değerleri olduğunu rahatça anlayabileceğimiz string'leri de gözlemleyebiliyoruz. Bu değerleri ve onların altındaki kelimelerden bir veya daha fazlasını daha önce de görmüştük.
  98. 98. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Eğer packlenmiş veya encode edilmiş bir dosya ile karşı karşıya isek, bu packleme işlemi standart dışı bir araç kullanılarak yapılmış veya unpack etme aracı mevcut değilse, o zaman izlememiz gereken yol şudur: • Uygulamayı bir binary debugger'ı attack ederek çalıştırmak • Uygulamanın unpack kodunu kontrollü olarak çalıştırmak ve unpack işlemi bittiği anda uygulamanın çalışmasını durdurmak • Tam bu noktada uygulamanın bellekteki halini diske yazmak (DUMP etmek) • Yapabiliyorsak dump edilmiş uygulamanın Import Address Table'ını tekrar oluşturmak
  99. 99. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Bu noktada unutulmaması gerekenler şunlardır: • Bu işlemi gerçekleştirebilmek için bir binary debugger kullanacağımız için eğer anti-debugger yöntemleri kullanan bir packer kullanılmışsa işimiz çok zorlaşacaktır. • Dump ettiğimiz dosyanın IAT'sunu otomatik araçlarla oluşturmamız mümkün olmayabilir. • Bu durumda uygulama çalıştırılamayacaktır. Ancak bu durum strings analizi ve disassembly yaparak analiz etmemize engel değildir. Ayrıca pack'li zararlıyı dinamik olarak test etmemize de engel değildir.
  100. 100. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Bellekten DUMP etme işlemini gerçekleştirebilmek için bir Ollydbg plugin'ini kullanacağız. Immunity Debugger Ollydbg'dan türetilmiş bir araç. Bu nedenle OllyDumpEx'in Immunity uyumlu dll'ini kullanmalıyız.
  101. 101. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Bu dosyayı C:Program FilesUmmunity IncImmunity Debugger dizinine kopyalayalım. Bu işlemi Immunity Debugger'ı başlatmadan önce yapmalıyız, Immunity başlatıldığında bu plugin'i tanıyacaktır.
  102. 102. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Immunity Debugger'ı başlattıktan sonra zararlı yazılımımızı debugger'dan başlatalım.
  103. 103. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Uygulama başlatıldığında Immunity Debugger uygulamanın Address of Entry Point adresinde uygulamayı durduracaktır. PE dosyasını incelerken Address of Entry Point kavramına tekrar değineceğiz.
  104. 104. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme PUSHAD: Push All General Purpose Registers • Bu X86 Assembly Instruction'ı sırasıyla EAX, ECX, EDX, EBX, ESP, EBP, ESI ve EDI register'larını stack'e saklar. • Genellikle uygulamaya daha sonradan eklenen kodlar veya bellekte inject edilen shellcode'lar uygulama akışını bozmamak için tüm register'ları önce belleğe yazar, işlerini bitirince de bunları (POPAD instruction'ı ile) geri alarak uygulamanın devam etmesini sağlar. Temel X86 Assembly ve X86 mimari konularına daha sonra daha detaylı değineceğiz.
  105. 105. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme F7 tuşu ile veya "Step Into" düğmesi ile instruction'ı çalıştıralım ve Sağ Alt köşe de 8 register'ın değerinin Stack'e yazıldığını görelim.
  106. 106. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Register penceresinde ESP register'ının değerine sağ klikleyerek Follow in Dump seçeneğine tıklayalım.
  107. 107. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Bu işlemi yaptıktan sonra Sol Alt'ta bulunan Dump penceresinde ESP ile işaret edilen stack'in uç noktasına geldiğimizi görebiliriz.
  108. 108. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Ne yapmaya çalışıyoruz? • Burada aslında bir varsayımı test edeceğiz. UPX packer'ı için varsayımımız doğru çıkacak, ancak farklı bir packer için durum farklı olabilir. • Varsayımımız PUSHAD instruction'ı ile stack'e yazılan verilerin (muhtemelen POPAD instruction'ı ile) tekrar register'lara atandığı noktanın unpack etme işleminin sonlarına yakın bir noktada gerçekleşmesini bekliyor olmamız. • Bu noktaya kadar uygulamayı çalıştırıp buradan sonra adım adım ilerleyerek unpack işleminin başarı ile yapıldığından emin olmaya çalışacağız.
  109. 109. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Dump penceresinde ilk dört byte'ı taradıktan sonra sağ klikleyerek Breakpoint / Hardware, on access / Dword seçimi ile bir HW breakpoint koyalım.
  110. 110. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Breakpoint ve Türleri Debug ederken en büyük yardımcılarımızdan olan breakpoint koyma işlemi belli koşullar gerçekleştiğinde uygulamanın durdurulmasını ve analistin belli veri yapılarını, register'ları incelemesine imkan verir. • Software Breakpoint: Bu işlemde debugger bellekte breakpoint konulan noktayı 0xCC byte'ı ile değiştirir. Bu INT 3 anlamına gelen bir interrupt'tır ve kontrolü debugger'a devreder. • Hardware Breakpoint: İşlemci donanımı tarafından desteklenen bu türde X86 mimarisi için 4 breakpoint koyma imkanı vardır. Bellekteki kod üzerinde herhangi bir değişiklik oluşturmaz.
  111. 111. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Hardware Breakpoint mi Software Breakpoint mi kullanmalı? • Anti-debug yöntemlerinden bir tanesi de uygulamanın bellekteki imajını 0xCC byte'ını arayacak biçimde taraması ve bulursa sonlanmasıdır. • Bu nedenle eğer 4 HW breakpoint'te dolu değilse öncelikli olarak HW breakpoint'lerin tercih edilmesi bu kontrole takılma ihtimalini azaltacaktır.
  112. 112. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme F9 tuşu veya "Run Program" düğmesine bastıktan sonra breakpoint'imize ulaşabiliriz.
  113. 113. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Bir sonra işletilecek instruction'dan öncekine baktığımızda bunun POPAD olduğunu görebiliriz.
  114. 114. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Assembly kodunu biraz incelediğimizde birkaç instruction aşağıda bir Unconditional Jump instruction'ı görebiliriz. Bu işlemin uygulamanın orijinal koduna atlanan, dolayısıyla da unpack işleminin bittiği varsayımımızı test edebiliriz.
  115. 115. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Bunun için Jmp instruction'ının olduğu satıra HW breakpoint koyalım.
  116. 116. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme F9 tuşu veya "Run program" düğmesine basarak breakpoint'imize ulaşacağız. [Arada daha önce stack'te koyduğumuz bellek erişim breakpoint'i nedeniyle bir defa daha durma olacaktır, tekrar "Run program" düğmesine basınız.]
  117. 117. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme F7 tuşu ile veya "Step Into" düğmesi ile instruction'ı çalıştırdığımızda unpack işleminin bittiğini varsayıyoruz. Bundan kesin olarak emin olamayız, ama basit bir inceleme yaparak varsayımımızı test edebiliriz.
  118. 118. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Immunity Debugger'da "m" düğmesine basarak modüllerin (yani zararlı uygulamamız ve kullandığı kütüphanelerin) bellekte yerleştiği alanları inceleyelim.
  119. 119. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Burada atladığımız bu adresin UPX0 section'ında olduğunu görebiliriz [buradaki örnekte F17560 adresine atlamıştık]
  120. 120. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme UPX0 sectionının diskte kapladığı alanın 0 olduğunu PE dosyası içindeki UPX0 section başlık alanında görebiliriz. Demekki bu section için bellekte ayrılan alan [Virtual Size – 6600] unpacker tarafından doldurulmuş olmalı.
  121. 121. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Şimdi OllyDumpEx plugin'imizle uygulamanın bu anda bellekteki imajını diske yazalım.
  122. 122. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme
  123. 123. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme EIP register'ının [Instruction Pointer] işaret ettiği adresin Original Entry Point olarak değiştirilmesi için bu düğmeye tıklayalım. Çünkü uygulamanın şu anda bellekte bulunduğu halinde unpack bölümünün tekrar çalışmasına gerek yok.
  124. 124. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme "Dump" düğmesine tıklayarak bellekteki uygulama imajını diske "fatura_pdf_dump.exe" adıyla yazalım.
  125. 125. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Diske yazılmış olan uygulamayı çift tıklayarak çalıştırmak istediğimizde hata aldığımızı görebiliriz. Bu hatayı dump ettiğimiz imajın Import Address Table'ı oluşmadığı için alıyoruz.
  126. 126. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Dump Edilen Dosyayı Çalışabilir Hale Getirmek İçin • Dump ettiğimiz dosyayı çalışabilir hale getirmek için IAT'ı oluşturmamız gerekir. • Bunun için ImportREC gibi araçları kullanabiliriz, ancak başarılı olamayabiliriz (bizim imajımız için bu araç yararlı olmadı örneğin) • Ya da bu işlemi büyük çabalarla manuel olarak yapabiliriz. • Örneğimizi UPX ile geri döndürdüğümüz için bu yolu izlemeyeceğiz. • Ancak string analizi ve disassembly statik analizi için göz atacağız.
  127. 127. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Dump ettiğimiz dosyada tıpkı UPX ile decompress ettiğimiz kopyada olduğu gibi kritik string tespitlerimizi tekrar yapabilliyoruz.
  128. 128. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Dump edilen dosya IDA'da açılarak içindeki string'ler incelenebilir [unicode string'leri görebilmek için strings ekranında sağ klikleyerek Unicode seçeneği seçilmeli ve Strict ASCII seçeneği kaldırılmalıdır.
  129. 129. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Strings ekranındaki veriye çift tıklanarak bu verinin bulunduğu section'daki ilgili alana gelebiliriz. Bu alanda da IDA'nın bu veriye verdiği isim [sol tarafta] üzerine tıkladıktan sonra "x" karakterine basarak bu veriye referans verilen noktaları görebiliriz.
  130. 130. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Bellekten DUMP etme Bu referansa da çift tıklandığında ilgimizi çekebilecek bir kod bölümüne geçebiliriz. Dolayısı ile DUMP edilmiş kodu çalıştıramasak da reverse engineering çalışması yapabiliriz.
  131. 131. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ Packing'in Diğer Kullanım Amaçları • Packing'in ilk kullanım alanlarından birisi çalıştırılabilir dosya imajlarının boyutunu küçültmektir ve UPX bu tür araçlardan birisidir. • Packing sadece zararlı yazılım üretenler tarafından kullanılmaz. Entellektüel varlıklarını korumak isteyen yazılım üreticileri tarafından da kullanılabilirler. • Profesyonel (ücretli) packer uygulamalar UPX'te yaptığımız gibi basitçe bellekten unpack ettiğimiz imajın dump edilmesini engellemek için anti-debug yöntemleri barındırırlar. Yani her zaman işimiz buradaki gibi kolay olmayabilir.
  132. 132. ANALİZ PACK'LENMİŞ DOSYA ANALİZİ İleri Yöntemler • Packing yönteminden de ileri bir gizleme tekniği zararlı yazılım geliştiren kişinin kendi sanal makinesini oluşturmasıdır. Ancak diğer tüm korunma yöntemi gibi bu yöntem de aşılamaz değildir, yeterli zaman ve odaklanma ile sanal makine komut seti ortaya çıkarılarak kod bir pseudo kod'a çevrilebilir.
  133. 133. PORTABLE EXECUTABLE (PE) PE Dosya Formatı Neden Önemli? • Zararlı yazılım analizinde bu noktaya kadar PE dosya formatıyla doğrudan ilişkili bir analiz yapmadık. Ancak yaptığımız incelemeleri açıklarken hep PE dosya formatına referans verme ihtiyacı hissettik. • Dolayısıyla PE formatının gerek dinamik gerekse statik analiz için önemli bir arka plan bilgisi olduğunu söyleyebiliriz. • Buna ek olarak dinamik analizde tespitini yaptığımız drop edilen PDF dosyasının daha net görülmesi, zararlı yazılımın ne zaman derlendiği (daha doğrusu linklendiği), debug dizin bilgisi gibi saldırgana ilişkin bilgi verme potansiyeli olabilecek bilgileri de doğrudan PE dosya formatı üzerinde görebiliriz.
  134. 134. PORTABLE EXECUTABLE (PE) #include<stdio.h> int add(int prm1, int prm2) { int result; result = prm1 + prm2; return result; } int main() { int i = 10; int j = 20; int sonuc; sonuc = add(i, j); printf("Sonuc = %d", sonuc); getchar(); } PE dosya formatını açıklamak için yukarıda gördüğünüz basit bir C uygulamasını kullanacağız.
  135. 135. PORTABLE EXECUTABLE (PE) IMAGE DOS HEADER PE formatında bulunan ilk bölümde modern Windows sistemleri için çok da önemli olmayan bilgiler yer alır. PEView
  136. 136. PORTABLE EXECUTABLE (PE) IMAGE DOS HEADER Bu bölümün başında da ASCII "MZ" karakterlerinden oluşan bir signature bölümü yer alır. Bu harfler MSDOS işletim sisteminin mimarlarından Mark Zbikowski'nin ad ve soyadının ilk harfleridir.
  137. 137. PORTABLE EXECUTABLE (PE) IMAGE DOS HEADER Bu bölümde bizim için önemli tek alan en sonda yer alan ve NT exe başlığının başladığı alanın dosya içindeki offset'ini içeren bölümdür.
  138. 138. PORTABLE EXECUTABLE (PE) IMAGE DOS HEADER • Soru: Madem içinde işimize yarayan hiçbir şey yok neden bu bölüm var? • Cevap: Çünkü; Microsoft bu dosya formatının MSDOS işletim sistemi üzerinde çalıştırıldığında hata üretmek yerine bir mesaj vererek sonlanmasını istemiştir. [Ne demek istediğimiz bir sonraki sayfada açıklığa kavuşacaktır.]
  139. 139. PORTABLE EXECUTABLE (PE) MS-DOS Stub Program Burada gördüğümüz bölüm içinde Real Mode (16 bitlik) bir DOS işletim sistemi kodu içerir. Yaptığı işi IDA ile bu bölümü disassemble ederek açıklayalım.
  140. 140. PORTABLE EXECUTABLE (PE) MS-DOS Stub Program IDA ile dosyayı disassemble ederken dosyayı bir MS-DOS uygulaması gibi disassemble etmesini söylüyoruz.
  141. 141. PORTABLE EXECUTABLE (PE) MS-DOS Stub Program • Biz daha çok X86 assembly [32 Bit] ile ilgileneceğiz, ancak burada bir Real Mode assembly [16 Bit] ile karşı karşıyayız. • Buradaki fonksiyon çağırma yöntemi (Linux işletim sisteminde de benzer bir durum söz konusudur) temel fonksiyonları çağırmak için interrupt mekanizmasını kullanmaktır. Yani sanki tek bir fonksiyonu çağırıyoruz ancak fonksiyon aldığı girdilere göre farklı farklı davranış gösteriyor gibi. • İlk olarak DX register'ına 0x0E değerini ve AH register'ına da 0x9 değerini atayarak 0x21 numaralı interrupt'ı çağırıyoruz.
  142. 142. PORTABLE EXECUTABLE (PE) MS-DOS Stub Program 0x0E adresine çift tıkladığımızda hemen kod bölümünün altında yer alan ve sonu "$" karakteri ile biten bir metne ulaşıyoruz. Bu ASCII string PEView'da da kolaylıkla görülmüştü.
  143. 143. PORTABLE EXECUTABLE (PE) Çok Kısa Bir Assembly Giriş Buradaki register'ları anlamlandırmak için aşağıdaki şekil üzerinde register adları ve bunların alt bölümlerine kısaca değinelim:
  144. 144. PORTABLE EXECUTABLE (PE) MS-DOS Stub Program Interrupt 0x21'e AH register'ı ile verilebilecek parametreler ve bu parametrelerle elde edilecek sonuçlara bir göz atalım.
  145. 145. PORTABLE EXECUTABLE (PE) MS-DOS Stub Program İlk interrupt'ımızda AH register'ına atanan değer 0x09'du. Bu değerin standard output'a (yani normalde konsola) bir string yazdırmaya yaradığını görüyoruz. Ayrıca DX register'ının da yazılacak string'e işaret eden adresi barındırması gerektiğini anlıyoruz (bizim örneğimizde bu 0x0E idi ve bu adreste de "This program cannot be run in DOS mode." ifadesi yer alıyordu)
  146. 146. PORTABLE EXECUTABLE (PE) MS-DOS Stub Program İkinci interrupt'ımızda AX register'ına 0x4C01 değeri atanıyordu, bu da AH register'ına 0x4C atandığı anlamına gelir. Bu çağrının sonucunun uygulamanın sonlanması olduğunu yukarıdaki bilgiye bakarak anlayabiliriz. Bizim örneğimizde uygulama sonlandığında uygulamanın döndüreceği return değeri de "1" olacaktır.
  147. 147. PORTABLE EXECUTABLE (PE) MS-DOS Stub Program Özetle bu bölümdeki DOS uygulamasının tek işlevi bu dosyanın bir DOS uygulaması olmadığını (ironik biçimde aslında biraz öyle olmasına rağmen) belirtmek ve uygulamayı sonlandırmaktır.
  148. 148. PORTABLE EXECUTABLE (PE) IMAGE NT HEADERS [Signature] Dosyanın geri kalanının hangi formatta olduğunu belirten bölüm bu alandır. Günümüz Windows uygulamalarında bu alan NT signature olarak belirtilmektedir.
  149. 149. PORTABLE EXECUTABLE (PE) IMAGE NT HEADERS [Signature] Signature alanında olabilecek diğer değerler aşağıdaki gibidir: • #define IMAGE_DOS_SIGNATURE 0x5A4D // MZ • #define IMAGE_OS2_SIGNATURE 0x454E // NE • #define IMAGE_OS2_SIGNATURE_LE 0x454C // LE • #define IMAGE_NT_SIGNATURE 0x00004550 // PE00 Not: OS/2 Microsoft'un 90'lı yılların başlarında IBM ile birlikte geliştirdiği bir işletim sisteminin adıdır.
  150. 150. PORTABLE EXECUTABLE (PE) IMAGE FILE HEADER Uygulama kodunun uyumlu olduğu işlemci mimarisini belirtir
  151. 151. PORTABLE EXECUTABLE (PE) IMAGE FILE HEADER Dosya içinde kaç section bulunduğunu belirtir. Aşağıda görülen section header'lar bu sayıya göre parse edilecektir.
  152. 152. PORTABLE EXECUTABLE (PE) IMAGE FILE HEADER Saldırgana dair az da olsa fikir verebilecek bu alan zararlı uygulamanın ne zaman linklendiğini belirtir.
  153. 153. PORTABLE EXECUTABLE (PE) IMAGE FILE HEADER Optional Header alanının büyüklüğü bu alandan sonra gelecek section header'ların başlangıç adresini bulmak için kullanılır.
  154. 154. PORTABLE EXECUTABLE (PE) IMAGE FILE HEADER Bu bölümde dosyanın çalıştırılabilir bir dosya olduğunu anlayabiliyoruz. Eğer bu dosya bir DLL olsaydı IMAGE_FILE_EXECUTABLE_IMAGE yerine IMAGE_FILE_DLL işareti aktif olacaktı.
  155. 155. PORTABLE EXECUTABLE (PE) IMAGE OPTIONAL HEADER Optional Header ile ilgili söylenmesi gereken ilk şey aslında optional olmadığı, çünkü içinde uygulamanın belleğe yüklenmesi ve çalıştırılması ile ilgili kritik bilgiler barındırıyor. Bunlardan "Address of Entry Point" uygulamanın çalıştırılacak ilk instruction'ının RVA adresine işaret eder.
  156. 156. PORTABLE EXECUTABLE (PE) Adres of Entry Point Hakkında Bu ifade yanlış anlaşılmaya müsait olacağı için şu açıklamayı yapmakta fayda bulunmaktadır: • Uygulama modülü içinde çalıştırılacak ilk kod zannedilebileceği gibi "main()" fonksiyonunun ilk instruction'ı değildir. "main()" fonksiyonu çağrılmadan önce derleyici tarafından yazılım geliştiricinin seçtiği subsystem'e göre çevresel koşulları düzenleyen kodlar uygulamaya eklenmektedir. • Immunity Debugger gibi bir binary debugger ile bir uygulamayı başlattığınızda debugger'ın ilk breakpoint'i koyduğu yer ilk çalışan kod olan NTDLL kütüphanesi içindeki bir initial stub (kod parçası)'dır.
  157. 157. PORTABLE EXECUTABLE (PE) Adres of Entry Point Hakkında (devamı) • NTDLL'deki bu initial stub önce belleğe yüklenen diğer kütüphanelerin entry point'lerini çalıştırır, en son da uygulamanın ilk instruction'ını çalıştırır. • Özetle uygulamanın "main()" fonksiyonundan önce tüm DLL'lerin initial kodları, bunlardan sonra da uygulamanın kendi hazırlık kodları çalışır.
  158. 158. PORTABLE EXECUTABLE (PE) IMAGE OPTIONAL HEADER Image Base alanı uygulama belleğe yüklendiğinde yerleştirilmeyi arzu ettiği baz sanal adresi (Virtual Address – VA) ifade eder. Biraz önce uygulama başlangıç adresi için RVA kavramını kullanmıştık, burada ise VA kavramından söz ediyoruz. Bu noktada sanal adres kavramını ve adres kavramlarını açıklamakta fayda bulunmaktadır.
  159. 159. PORTABLE EXECUTABLE (PE) Modül Kavramı Nedir? Bir çalıştırılabilir dosya OS loader tarafından belleğe yüklenirken bu dosyanın kullanacağı kütüphaneler de bu prosesin adres alanına haritalanır (map'lenir). Yüklenen çalıştırılabilir dosyanın kendisi (PE dosyamız) ve yüklenen kütüphaneler (DLL'ler)'in her birisi modül olarak adlandırılırlar.
  160. 160. PORTABLE EXECUTABLE (PE) Modül Kavramı Nedir? PE modülümüzün bellekteki imajı Uygulamamızın kullandığı DLL modülleri Uygulamamızın adres alanında kendi kod ve verileri bulunduğu gibi kullandığı kütüphanelerin modülleri de hazır bulunmaktadır.
  161. 161. PORTABLE EXECUTABLE (PE) Yükleme, Fiziksel ve Mantıksal Adresler
  162. 162. PORTABLE EXECUTABLE (PE) Yükleme, Fiziksel ve Mantıksal Adresler
  163. 163. PORTABLE EXECUTABLE (PE) Yükleme, Fiziksel ve Mantıksal Adresler PE Dosyamızın disk üzerindeki hali. PEView bizim için başlangıç adresinin VA cinsinden değerini belirtiyor.
  164. 164. PORTABLE EXECUTABLE (PE) Yükleme, Fiziksel ve Mantıksal Adresler PE Dosyamızın bellek üzerindeki hali.
  165. 165. PORTABLE EXECUTABLE (PE) Adres Kavramları ÖNEMLİ: Bir PE dosyası çalıştırılmak üzere OS Loader tarafından belleğe yüklenirken PE dosyasında gördüğünüz veriler ve yerleri büyük oranda değişmeden belleğe aktarılır. • File Offset: PE dosyasındaki verinin disk üzerindeki dosyada bulunduğu offset değerini belirtir. • Relative Virtual Address [RVA]: PE dosyasında gördüğümüz verinin belleğe yüklendiğinde modülün yüklendiği baz sanal adresten itibaren bulunduğu offset değerini belirtir. • Virtual Address [VA]: PE dosyasında gördüğümüz verinin belleğe yüklendiğinde bulunacağı sanal adrestir.
  166. 166. PORTABLE EXECUTABLE (PE) Adres Kavramları [File Offset] .text section'ının Disk üzerindeki dosya içindeki offset adresi
  167. 167. PORTABLE EXECUTABLE (PE) Adres Kavramları - RVA [Relative Virtual Address] .text section'ının bellekte modülün başlangıç adresine göre offset adresi
  168. 168. PORTABLE EXECUTABLE (PE) Adres Kavramları - VA [Virtual Address] .text section'ının bellekte bulunacağı sanal adres
  169. 169. PORTABLE EXECUTABLE (PE) Adres Kavramları – Bellekten Görüntü .text section'ının bellekte disassemble edilmiş hali [adres bilgilerinin yanında opcode'ları görebilirsiniz]
  170. 170. PORTABLE EXECUTABLE (PE) IMAGE OPTIONAL HEADER Section'ların belleğe yerleştiklerinde align olmaları gereken adres periyodu. Yani her section'ın Virtual Adresi Hex 1000 byte'ın katları olan adreslerden başlayabilir. Bu nedenle ".text" section'ı disk üzerinde 0x400 offset'te iken belleğe yüklendiğinde 0x401000 VA adresinden başlamaktaydı.
  171. 171. PORTABLE EXECUTABLE (PE) IMAGE OPTIONAL HEADER Section'ların disk üzerindeki hallerinin (raw hallerinin) başlaması gereken offset adreslerinin hangi sayının katı olması gerektiğini belirtir. Bu nedenle section sonu bu sayının katına erişmek için "0x00" byte'ları ile pad'lenir.
  172. 172. PORTABLE EXECUTABLE (PE) IMAGE OPTIONAL HEADER ".text" section'ının sonunda 0x200 byte'ın katı olacak biçimde yapılmış 0x00 byte'larıyla yapılmış padding'i görebilirsiniz. Son adres: 0x401E00
  173. 173. PORTABLE EXECUTABLE (PE) IMAGE OPTIONAL HEADER DLL Characteristics alanı isminde DLL geçse de tüm PE dosyalarıyla ilgilidir. Daha sonra örneğini uygulayacağımız ASLR desteği, DEP desteği, v.d. özellikleri modülümüzün taşıyıp taşımadığını belirtir. Bu örnekte ASLR desteğimiz bulunmamaktadır.
  174. 174. PORTABLE EXECUTABLE (PE) IMAGE OPTIONAL HEADER Data Directories dizisi OS loader'ın işlevini yerine getirebilmesi için önemli çeşitli bilgileri barındırır. Bu örnekte IAT'nin yerini ve büyüklüğünü görüyoruz.
  175. 175. PORTABLE EXECUTABLE (PE) IMAGE OPTIONAL HEADER IAT Data Directory'sinin RVA adresine gittiğimizde IAT'nin içeriğine ulaşabiliriz.
  176. 176. PORTABLE EXECUTABLE (PE) PE Dosya Organizasyonu Temel Referanslar PE dosya organizasyonunun içinde OS loader'ın görevini yerine getirebilmesi için kod / veri alanlarını ve özelliklerini tanımlayan 2 tür referans bulunmaktadır: 1. Section Header'ları: Section'ların dosya içindeki yerleri, disk üzerinde ve bellekte kaplayacakları alan büyüklükleri ve erişim kuralları gibi özellikleri tanımlarlar [henüz değinmedik]. 2. Data Directory kayıtları: Import Address Table gibi, Base Relocation Table (modül Image Base alanında belirtilen adrese oturmamışsa değişmesi gereken adreslerin yerleri) gibi OS loader için önemli ve farklı section'ların içlerinde yer alan veri alanlarının RVA adreslerini ve büyüklüklerini tanımlarlar.
  177. 177. PORTABLE EXECUTABLE (PE) IMAGE OPTIONAL HEADER Eğer bir DLL yazmış olsaydık bir takım fonksiyonları da Export edecektik. Bu örnek basit bir EXE uygulaması olduğu için Export Table RVA adresi 0 olarak görülüyor. Bu bilgiye özellikle shellcode yazarken çok ihtiyacımız olacaktır, çünkü shellcode uygulamaları bu veri yapılarını kullanarak bellekteki fonksiyon adreslerini tespit ederler.
  178. 178. PORTABLE EXECUTABLE (PE) IMAGE SECTION HEADER Data Directory'lerle birlikte 2 önemli referans noktasından birisi olan Section Header'ların ilk 8 byte'ı section ismi için kullanılır. Belli section'lar için derleyicilerin kullandığı geleneksel isimler olsa da section'ın Characteristics alanı belirleyicidir. Yani isimlerin hiçbir önemi yoktur makine (işlemci) için.
  179. 179. PORTABLE EXECUTABLE (PE) IMAGE SECTION HEADER Size of Raw Data bu section'ın disk üzerindeki dosya içinde kapladığı alanı belirtir. Image Optional Header'daki File Alignment değerini hatırlarsanız Raw Data boyutunun 0x200 byte'ın katları olması gerektiğini bilebiliriz. Derleyici bunu sağlamak için section'ın son bölümlerini 0x00 ile pad'lemeli.
  180. 180. PORTABLE EXECUTABLE (PE) IMAGE SECTION HEADER Görüldüğü gibi 0xCC3 offset'inden 0xE00 offset'ine kadar olan alan 0x00 ile pad'lenmiş.
  181. 181. PORTABLE EXECUTABLE (PE) IMAGE SECTION HEADER Virtual Size değeri bu section'ın uygulama belleğe yüklendiğinde bellekte kaplayacağız alanı ifade ediyor. Bu section için bellekteki alanın diskteki alanından daha küçük olduğunu görüyoruz. Ancak UPX örneğinde olduğu gibi bunun tersi de mümkün [UPX diskte hiç yer kaplamayan bir section için bellekte geniş bir alan istemekteydi].
  182. 182. PORTABLE EXECUTABLE (PE) IMAGE SECTION HEADER Padding öncesinde son verinin 0xCC3 adresinde bulunduğunu .text section'ının son bölümüne göz attığımızda görebiliriz.
  183. 183. PORTABLE EXECUTABLE (PE) IMAGE SECTION HEADER RVA adres kavramını daha önce konuşmuştuk, bu section'ın EXE modülünün başlangıç adresinden itibaren 0x1000 offset'ten başlatılacağını bu alandan anlıyoruz. Yine Image Optional Header'dan hatırlarsak bu değerin 0x1000 olan section alignment değerinin katı olması gerektiğini söyleyebiliriz.
  184. 184. PORTABLE EXECUTABLE (PE) IMAGE SECTION HEADER .text section'ının adres formatını File Offset'ten RVA'e değiştirdiğimizde PEView bize olması gereken 0x1000 değerini gösteriyor.
  185. 185. PORTABLE EXECUTABLE (PE) IMAGE SECTION HEADER Section'ın bellekte başlayacağı adres ile disk üzerinde bulunduğu File Offset değeri farklı. Burada bu section'ın 0x400 File Offset'inde bulunduğunu anlıyoruz. Bellekte 0x400 ve 0x1000 offset'leri arasındaki boşluk ne olacak derseniz bellekteki adreslerini Virtual adresler olduğunu ve bu adreslerin fiziksel karşılıklarının farklı olduklarını hatırlamamız gerekir. Yani aslında bir boşluk olmayacak, sadece bu sanal adresler için herhangi bir fiziksel alan kullanılmayacaktır.
  186. 186. PORTABLE EXECUTABLE (PE) IMAGE SECTION HEADER .text section'ının adres formatını File Offset'e değiştirdiğimizde PEView bize 0x400 değerini gösteriyor.
  187. 187. PORTABLE EXECUTABLE (PE) IMAGE SECTION HEADER Section isimlerinin aslında işlemci için hiçbir anlamı olmadığını, section'ın özellikleri hakkında Characteristics alanının belirleyici olduğunu daha önce söylemiştik. Geleneksel olarak uygulamanın kod bölümlerinin yerleştirildiği .text section'ının Execute hakkı uygulama belleğe yüklenirken bu section için ayrılan memory page'lerine atanacaktır. Yani bu alanlardaki veriler kod olarak çalıştırılabilecektir.
  188. 188. PORTABLE EXECUTABLE (PE) IMAGE SECTION HEADER Yine geleneksel olarak .rdata alanı Read Only verilerin (yani constant string v.d. veri tiplerinin) saklandığı section'dır. Tabi yine bu özellik aslında Characteristics alanı tanımlarından gelmektedir.
  189. 189. PORTABLE EXECUTABLE (PE) IMAGE SECTION HEADER .data alanı belli bir alanı kaplayan ancak değiştirilebilecek Global değişkenlerin tutulması için kullanılan alandır. Dolayısıyla bu alana yazma (Write) hakkı da verilmiştir.
  190. 190. PORTABLE EXECUTABLE (PE) IMAGE SECTION HEADER Resource section'ı diğerlerinden biraz farklı. Diğer section'lar da kendi içlerinde bazı özel veri yapıları barındırıyor (ör: IAT – Import Address Table, Export Table gibi), ancak .rsrc section'ı bir bütün olarak bir directory yapısına sahip, yani tek bir genel veri yapısına sahip.
  191. 191. PORTABLE EXECUTABLE (PE) IMAGE SECTION HEADER Basit PE dosyamızda tek bir resource kaydı var: MANIFEST
  192. 192. PORTABLE EXECUTABLE (PE) IMAGE SECTION HEADER Özellikle dropper (yani resource section'ından dosyaları alıp diske bağımsız dosyalar olarak yazma) fonksiyonalitesine sahip zararlıları incelerken bu alana özel bir araç kullanmakta fayda var: Resource Hacker. PEView'ın veriyi Raw formatta göstermesi bize yeterli desteği vermiyor.
  193. 193. PORTABLE EXECUTABLE (PE) ZARARLI YAZILIM İNCELEME UPX ile unpack ettiğimiz zararlı yazılımın derlenme / linklenme zamanını kontrol ettiğimizde bu değerin halen mevcut olduğunu görebiliyoruz.
  194. 194. PORTABLE EXECUTABLE (PE) ZARARLI YAZILIM İNCELEME Ancak unpack edilmiş uygulamada debug sembol bilgilerinin referansının yok olduğunu görüyoruz.
  195. 195. PORTABLE EXECUTABLE (PE) ZARARLI YAZILIM İNCELEME Ancak bu debug sembol dosyasının linkinin .rdata section'ı içinde olmadığı anlamına gelmiyor. Bu section'ı elle incelediğimizde halen debug dosya yolunu görebiliyoruz.
  196. 196. PORTABLE EXECUTABLE (PE) PACK'LENMEMİŞ ZARARLI YAZILIM Pack'lenmemiş zararlı yazılımı (original haliyle) inceleseydik aşağıdaki gibi debug data directory bilgisinin mevcut olduğunu görecektik. Demekki bu bilgi pack'lerken kaybediliyor (ya da unpacker bu bilgiyi geri getirme zahmetine girmiyor)
  197. 197. PORTABLE EXECUTABLE (PE) PACK'LENMEMİŞ ZARARLI YAZILIM PEView aracı data directory verisi bulunduğu için orijinal zararlı dosyamızda debug sembol dosyasını bulabiliyor.
  198. 198. ANALİZ RESOURCE ANALİZİ [Resource Hacker] Zararlı yazılımımızın Resource section'ında bulunan verileri Resource Hacker ile anlamlandırarak inceleyelim.
  199. 199. ANALİZ RESOURCE ANALİZİ [Resource Hacker] Icon tipindeki resource'a göz attığımızda Resource Hacker PDF icon'larını bizim için görüntülüyor. Zararlıyı geliştiren kişi çalıştırılabilir dosyanın PDF dosyası gibi algılanmasını sağlamak için uygulamanın icon'u olarak PDF icon'unu kullanmış.
  200. 200. ANALİZ RESOURCE ANALİZİ [Resource Hacker] RCData bölümünde ise PDF dosya verisine benzer bir verinin bulunduğunu görebiliyoruz. Bu veriyi PDF uzantılı bir dosya olarak kaydetmek ve açmak için Save edelim.
  201. 201. ANALİZ RESOURCE ANALİZİ [Resource Hacker] RCDATA tipindeki verinin gerçekten PDF dosyası olduğunu görebiliyoruz. Dinamik analiz sırasında görüntülenen PDF dosyası zararlı tarafından bu bölümdeki verinin drop edilmesiyle oluşturulmuş olmalı.
  202. 202. ANALİZ RESOURCE ANALİZİ [Resource Hacker] MSDN'den RCDATA resource tipini incelediğimizde herhangi bir binary veriyi saklamak için kullanılan bir resource tipi olduğunu görüyoruz.

×