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

ZARARLI YAZILIM
ANALİZİ EĞİTİMİ
BÖLÜM-1
İSTANBUL
blog.btrisk.com @btrisk /btrisktv /btrisk

BTRİSK HAKKINDA
TANIŞMA
Pentest & BT Denetimi
ISO27001 Danışmanlık
Hizmetleri
BG Operasyon
Hizmetleri

Göreviniz, Deneyiminiz ve Eğitimden Beklentileriniz
Nelerdir?
TANIŞMA

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.

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.

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

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

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

LAB ORTAMI
İZOLASYON
• 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)

LAB ORTAMI
İZOLASYON
User Account Control
seviyesinin en aza çekilmesi
(bu ayar UAC kontrolünün tamamen
kaldırıldığı anlamına gelmemektedir)

LAB ORTAMI
İZOLASYON
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.

LAB ORTAMI
İZOLASYON
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.

LAB ORTAMI
İZOLASYON
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.

LAB ORTAMI
İZOLASYON

LAB ORTAMI
İZOLASYON
VM - Honeypot

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

LAB ORTAMI
İZOLASYON
VM – Honeypot
Kali Linux
VM – Hedef
Bilgisayarlar aynı
ağ bölümü

LAB ORTAMI
İZOLASYON
VM – Honeypot
Kali Linux
Statik IP adres
tanımı

LAB ORTAMI
İZOLASYON
VM – Honeypot
Kali Linux

LAB ORTAMI
İZOLASYON
VM – Honeypot
Kali Linux
Hedef Bilgisayara
Erişim Testi

LAB ORTAMI
İZOLASYON
Honeypot Sunucuya
Erişim Testi

LAB ORTAMI
HIZLI GERİ DÖNEBİLME
Hedef bilgisayarın farklı aşamalarında
sanal makine sunucusunun snapshot
alma özelliğinden faydalanmalıyız

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ı

LAB ORTAMI
ARAÇLAR
Neden kullanacağımızı iyi bildiğimiz ve gereksiz olanları
arındırılmış bir araç envanterini kullanmalıyız

LAB ORTAMI
ARAÇ KURULUMLARI
capturebat.exe – Dosya, Registry, Network aktiviteleri
izleme aracı [Dinamik Analiz aracı]

LAB ORTAMI
ARAÇ KURULUMLARI
Malcode Analyst Pack [MAP] – çeşitli küçük statik
analiz araçlarını barındıran bir paket

LAB ORTAMI
ARAÇ KURULUMLARI
Immunity Debugger – Binary Debugger / Disassembler
[Dinamik Analiz Aracı]

LAB ORTAMI
ARAÇ KURULUMLARI
Wireshark – Network Sniffer
[Dinamik Analiz Aracı]

LAB ORTAMI
ARAÇ KURULUMLARI
Notepad++ - Dosya okuma ve not alma aracı (notepad
uygulamasından kesinlikle daha çok işimize yarayacak)

LAB ORTAMI
ARAÇ KURULUMLARI
IDA Pro – Interaktif Disassembler
[Statik Analiz Aracı]

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.
010 Editor / HxD – Hexadecimal Editörler

LAB ORTAMI
ARAÇ KURULUMLARI
Resource Hacker – PE Resource section analiz aracı

LAB ORTAMI
ARAÇ KURULUMLARI
Kurulumlar sonrasında bir
snapshot daha almakta
fayda var

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

Ö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

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ş.

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.

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.

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 !!!

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.

ANALİZ
Servislerin bind edilmesi için tüm
arayüzleri kullanabilmek için bu satıra
"0.0.0.0" girelim.

ANALİZ
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.

ANALİZ
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.

ANALİZ
Söz konusu opsiyon /usr/bin/inetsim
dosyasının ilk satırında görülebilir.

ANALİZ
Hatayı almamak için T opsiyonunu
silmelisiniz.

ANALİZ
"inetsim" uygulaması sağlıklı olarak
başladığında DNS servisi başlatılmış
olacaktır.

ANALİZ
Ayrıca HTTP ve HTTPS servislerinin de
başlatıldığını görebilirsiniz.

ANALİZ
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.

ANALİZ
www.btrisk.com alan adına yapılan ping
istekleri de 10.0.0.1 IP adresine
gönderilmektedir.

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.

ANALİZ
Ş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

ANALİZ
Zararlı uygulamamızı başlatıyoruz.
Bize bir PDF dosyası görüntüledi
ve bir uygulama da hata aldı.

ANALİZ
Ctrl+C komutuyla capturebat.exe'yi
sonlandırıyoruz.

ANALİZ
mlwlog.txt (veya siz hangi ismi vermişseniz)
dosyasını açtığımızda log kayıtlarını görebiliriz.

ANALİZ
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!

ANALİZ
MD5 Hash Değeri:
815E2E11882093CCE54C789D5CB74A7C
Zararlımızın hash değerini
kopyaladığı dosya ile aynı olup
olmadığını anlamak için
hesaplayalım.

ANALİZ
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ış.

ANALİZ
"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ı.

ANALİZ
Dosyayı açmadan bir göz atmak için 010
editör ile dosyayı inceleyebiliriz.

ANALİZ
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ş.

ANALİZ
Dosyayı açtığımızda bir PDF dosyası
olduğunu görebiliyoruz.

ANALİZ
"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.

ANALİZ
"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.

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.

ANALİZ
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.

ANALİZ
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.

ANALİZ
Giden ve gelen paketler içindeki yazılabilir
karakterleri izlemek için Wireshark'ın
"Follow / TCP Stream" fonksiyonalitesini
kullanabiliriz.

ANALİZ
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.

ANALİZ
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

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.

ANALİZ
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.

ANALİZ
Malcode Analysis
Pack (MAP)
Strings aracı

ANALİZ
Daha anlamlı string'ler
bulmak için string
boyutunu artırabiliriz

ANALİZ
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.

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.

ANALİZ
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.

ANALİZ
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".

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.

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.

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

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)

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.

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

ANALİZ
UPX ile unpack etme
UPX "-d" opsiyonu ile
UPX ile compress
edilmiş bir dosyayı
decompress etmek için
de kullanılabiliyor

ANALİZ
UPX ile unpack etme
upx -d ..fatura_pdf.scr -o fatura_pdf-decompress.exe

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

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

ANALİZ
UPX ile unpack etme
Malcode Analysis
Pack (MAP)
Strings aracı
String analizinde kaldığımız
yerden biraz ilerleyelim

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

ANALİZ
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.

ANALİZ
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

ANALİZ
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.

ANALİZ
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.

ANALİZ
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.

ANALİZ
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.

ANALİZ
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.

ANALİZ
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.

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

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.

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.

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.

ANALİZ
Bellekten DUMP etme
Immunity Debugger'ı başlattıktan sonra
zararlı yazılımımızı debugger'dan
başlatalım.

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.

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.

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.

ANALİZ
Bellekten DUMP etme
Register penceresinde ESP register'ının
değerine sağ klikleyerek Follow in Dump
seçeneğine tıklayalım.

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.

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.

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.

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.

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.

ANALİZ
Bellekten DUMP etme
F9 tuşu veya "Run
Program" düğmesine
bastıktan sonra
breakpoint'imize
ulaşabiliriz.

ANALİZ
Bellekten DUMP etme
Bir sonra işletilecek
instruction'dan öncekine
baktığımızda bunun POPAD
olduğunu görebiliriz.

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.

ANALİZ
Bellekten DUMP etme
Bunun için Jmp
instruction'ının olduğu
satıra HW breakpoint
koyalım.

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.]

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.

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.

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]

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ı.

ANALİZ
Bellekten DUMP etme
Şimdi OllyDumpEx plugin'imizle
uygulamanın bu anda bellekteki
imajını diske yazalım.

ANALİZ
Bellekten DUMP etme

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.

ANALİZ
Bellekten DUMP etme
"Dump" düğmesine tıklayarak
bellekteki uygulama imajını
diske "fatura_pdf_dump.exe"
adıyla yazalım.

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.

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.

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.

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.

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.

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.

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.

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.

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.

#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.

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

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.

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.

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.]

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.

MS-DOS Stub Program
IDA ile dosyayı disassemble
ederken dosyayı bir MS-DOS
uygulaması gibi disassemble
etmesini söylüyoruz.

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.

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ü.

Ç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:

MS-DOS Stub Program
Interrupt 0x21'e AH register'ı ile
verilebilecek parametreler ve bu
parametrelerle elde edilecek sonuçlara
bir göz atalım.

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)

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.

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.

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.

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.

IMAGE FILE HEADER
Uygulama kodunun uyumlu
olduğu işlemci mimarisini
belirtir

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.

IMAGE FILE HEADER
Saldırgana dair az da olsa fikir verebilecek bu alan
zararlı uygulamanın ne zaman linklendiğini belirtir.

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.

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ı.

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.

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.

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.

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.

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.

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.

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.

PE Dosyamızın bellek
üzerindeki hali.

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.

Adres Kavramları [File Offset]
.text section'ının
Disk üzerindeki dosya
içindeki offset adresi

Adres Kavramları - RVA [Relative Virtual Address]
bellekte modülün
başlangıç adresine göre
offset adresi

Adres Kavramları - VA [Virtual Address]
bellekte bulunacağı sanal
adres

Adres Kavramları – Bellekten Görüntü
.text section'ının bellekte disassemble edilmiş hali [adres
bilgilerinin yanında opcode'ları görebilirsiniz]

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ı.

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.

".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

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.

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.

IAT Data Directory'sinin RVA adresine
gittiğimizde IAT'nin içeriğine ulaşabiliriz.

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.

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.

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.

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.

Görüldüğü gibi 0xCC3
offset'inden 0xE00
offset'ine kadar olan alan
0x00 ile pad'lenmiş.

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].

Padding öncesinde son
verinin 0xCC3 adresinde
bulunduğunu .text
section'ının son bölümüne
göz attığımızda görebiliriz.

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.

.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.

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.

.text section'ının adres
formatını File Offset'e
değiştirdiğimizde PEView
bize 0x400 değerini
gösteriyor.

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.

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.

.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.

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.

Basit PE dosyamızda tek bir
resource kaydı var:
MANIFEST

Ö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.

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.

Ancak unpack edilmiş uygulamada debug
sembol bilgilerinin referansının yok olduğunu
görüyoruz.

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.

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)

PACK'LENMEMİŞ ZARARLI YAZILIM
PEView aracı data directory verisi bulunduğu
için orijinal zararlı dosyamızda debug sembol
dosyasını bulabiliyor.

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.

ANALİZ
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ış.

ANALİZ
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.

ANALİZ
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ı.

ANALİZ
MSDN'den RCDATA resource tipini incelediğimizde
herhangi bir binary veriyi saklamak için kullanılan
bir resource tipi olduğunu görüyoruz.

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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

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

Similar to BTRisk Zararlı Yazılım Analizi Eğitimi Sunumu - Bölüm 1 (20)

More from BTRisk Bilgi Güvenliği ve BT Yönetişim Hizmetleri

More from BTRisk Bilgi Güvenliği ve BT Yönetişim Hizmetleri (17)

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