Detecting Process Injection Techniques via Memory Forensic – Chapter 1

Merhaba dostlar. Bu yazımda sizlere zararlı yazılımlar tarafından kullanılan “process injection” tekniklerinin bellek analizi ile nasıl tespit edebileceğimizi anlatacağım.

Asıl bölüme geçmeden önce ufak bir hatırlatma yapayım. Yazı içerisinde teknikler hakkında kısa detaylar bulunmakta. Eğer process injection teknikleri üzerine hatrınızda kalmış bir şeyler yoksa yazıyı okumadan önce tekniklerin çalışma yapılarını incelemenizi tavsiye ediyorum.

Tespit etmeye çalışacağımız injection teknikleri:

  • Process Hollowing
  • Process-Doppelganging

Process Hollowing

Tekniği basitçe açıklayalım. Hedef aldığı bir uygulamayı önce suspended halde başlatıyor. Ardından uygulamanın asıl bölümünü bellekten “UnMap” edip zararlı olan kısım için bellekte açtığı yere yazma gerçekleştirdikten sonra EP’i yeni bölüme yönlendirip amacını gerçekleştiriyor. Sistem uygulaması olarak listelenen bir process’in içerisinde farklı işler yürütebiliyor.

Gelelim RAM imajı üzerinden bu tekniğin kullanılıp/kullanılmadığının tespitine.

İlk olarak imajıma erişip çalışmış olan uygulamalar bakıyorum.

pslist1

Normal şartlarda “services.exe” child’i olarak başlatan “svchost.exe”‘lerden bir tanesinin “evil.exeollowi” altında çalıştığını farkediyoruz.

“evil.exeollowi” process’ine ait bilgileri sorgulayalım.

hol1

Gelen verilere baktığımızda çağırmış olduğu fonksiyonların “burada bir haltlar dönüyor kesin” sınıfına dahil olan fonksiyonlar olduğunu gördük.  Teknikte kullanılan fonksiyonlar bariz şekilde peş peşe dizilmiş. Nereye ne yazmış, neresine yazmış diye sormadan duramıyoruz. Merak işte.

Ardından kendisi ile bağlantılı olan “svchost.exe:884”‘e bakıyoruz.

peinfosvchost

Bilgicik : Vakalarda kalabalığı azaltmak ve bu teknikle alakalı şüphelileri ortaya çıkarmak için elinizde bulunan legit process’lere ait GUID’leri, ilgili işletim sisteminde bulunan asıl dosyaların GUID’leri ile karşılaştırarak işleri kolaylaştırabilirsiniz.

PE Info ortada bağırıyor, seçilmiş kişiyim diyor. Legit bir process’e ait bu bilgi ali cengiz oyunlarının döndüğünü bize söylüyor. Bellek içerisinde bir değişim olduğunu da anladık ama detaylandıralım.

Hedefimize ait modüllerin listesi.

modules

Process’in kullanmış olduğu kütüphaneler map’lenmiş halde ve çıktıdan da bunu anlıyoruz ancak tuhaf olan durum ise “svchost.exe”‘nin dosya yolunun burada bulunmaması.  Devam edelim kurcalamaya.

dlllist ile process’imize baktığımızda işler biraz daha şekillenmeye başladı.

dlllist

“svchost.exe” 0xa60000‘da var, oradan yürütülüyor. BaseAdress’ler gene o gülüşü attırıyor. Bu kısımda farklı giden bir şeyler olduğunu biliyorduk ve temel olan noktaya geldik.

Process’e ait VAD(Virtual Address Descriptor)’a yığın çıktısına bakıyoruz.

VAD, Windows kernel'ı tarafından process'lere ait bellek yönetimi için kullanılan bir yapı.

vad

Burada baştan beri takip ettiğimiz tuhaflıklar(injection’lar) silsilesinin çıktısını görüyoruz. Genellikle Windows içerisinde normal şartlarda çalışan bir uygulama, bellekte yer edinirken, kendisinin ve fonksiyon çağıracağı kütüphanelerin sistemde bulunan dosya yollarını da ref ederek “Mapped” halde ve “EXECUTE_WRITECOPY” izniyle tutmakta. Bellek içerisinde bulunan process’lerin herbirine erişimi olduğun için bir process başka bir process’e ait bellek alanında manipülasyon gerçekleştirebilir. Böyle bir işlem yani belleğe yazma işlemi gerçekleşmişse eğer ilgili bölümün perm.’i “EXECUTE_READWRITE” olarak belirlenmektedir.

Ekran görüntüsünde de görüldüğü üzere bizim minik “svchost.exe:884” içerisinde değişiklik yapılmış bir alana sahip. İlgili bölüm 0xa60000  adresinden başlıyormuş. BINGO (İlk 3 adımda zaten almıştık ama neyse)
dlllist çıktısında gördüğümüz adres ile çakıştı ve üzerinden değişiklik olduğunu tam anlamıyla gördük artık.

İlgili adresten legit uygulama üzerine enjekte edilmiş olan arkadaşı dump edip bu teknik ile alakalı kısmı bitirelim.

mainprog

Minik bir HelloWorl’müş :p

Process Doppelganging

Kendileri TxF nimetinden yararlanarak Transacted bir dosya yaratıp(İstediğiniz dizinde, istediğiniz adda ve uzantıda), bellekte onca can verip ardından Rollback yaparak dosya işlemi hiç gerçekleşmemiş gibi devam eden ve elimize process veren bir teknik. Süreç Hollowing’den tamamen farklı şekilde ilerlemekte.

Bu tekniğe ait detayları önceden yazmıştım. Şurdan okuyabilirsiniz.

İmajın hakkı pslisttir diyerek rekall’dan komutumuzu yolluyoruz.

rekallps

Process’ler önümüzde ancak bu yöntem diğeri gibi olmadığı için tespit işini tekniği tam olarak anlayarak yapmamız gerekecek.

Doppelgänging :

Transact -> Load -> Rollback -> Animate

adımlarından oluşuyor. Transact içerisinde bir dosya oluşturma işlemi mevcut ancak bu işlem TxF kullanılarak yapıldığı için klasik süreçten farklı bir durum söz konusu. TxF’de bir dosya işlemi başlattığınızda süreci sonlandırmazsanız ilgili dosya görünmemekte. Yani kullanabildiğiniz bir dosya yaratabiliyorsunuz ve işiniz bittiğinde işlemi sonlandırmayıp Rollback yaparsanız o orda hiç varolmamış sayılıyor.

Böyle bir dosya yaratılıp içine zararlı olan kısım yazılıyor ve ardından bildiğimiz “NtCreateSection” ile dosya hafızaya yüklenip Rollback yapıyor.

Son olarak “NtCreateProcessEx” ile hafızadaki ayırdığı kısmı işaret edip dosya yoluna gidince hiçlikle karşılaşacağımız ya da bilinçli olarak legit uygulama dizini üzerine yazılmış bir process ayağa kaldırıyor.(Permission farketmeksizin TxF ile istediğiniz dizinde transacted bir dosya oluşturabiliyorsunuz)

Şimdi bu anlattığım olayın Windows içerisinde gerçekleşirken monitorlerimize nasıl takıldığına bakalım.

procdopp

Tekniği kullanarak bir process başlattık. Process’e ait bilgilere baktığımızda “C:\Windows\yolo.txt” dizinini vermiş ve mevcut klasörü de System32.(Uzantılar da bizim :p)

Bir de teknik bu işlemi gerçekleştirirken arkada neler yapmış ona bakalım.

doppmon

TxF’siydi,Transacted dosyasıydı dedik durduk. Teknik bu işlemi gerçekleştirirken teorikte hiç oluşmamış olacak bir dosya oluşturabilecek ancak arkada API’ler söz konusu olunca tekniği fişekleyen uygulamanın, enjeksiyon için kullanacağı sahte path’i kendi bulunduğu mevcut klasörde oluşturuyor.

Detay az dedik ama burada detay vermezsek yapacaklarımız anlaşılmaz. Şimdi tekniğin bize sunmuş olduğu verilere bakarak belli başlı çıkarımlar yapacağız.

  1. Process, bellekte injection tekniği tarafından kendisine atanmış path’i kullanıyor.(in_mem)
  2. Teknik fonksiyonlarını gerçekleştirirken kullanacağı sahte path için bulunduğu dizinde sahte path’e dahil olan dosya adını kullanarak bir dosya oluşturmakta.(mapped)

Şimdi tekrardan imajımıza dönelim.

Bu teknik için incelemekte olduğumuz vakada, tekniğin kendisi sebebi ile işimiz biraz zordu. Çünkü  tek tek tüm process’leri gezip procinfo’lara bakıp bellek dökümlerinde olan bitene bakmamız çok zamanımızı alacaktı. Şimdi işleri kolaylaştıralım.

mem2

ldrmodules çıktısı

ldrmodules ile process’lere ait unlinked DLL’leri listeleyebiliyorduk. Bu fonksiyonun çıktılarında ise yüklediği dosyalara ait verileri görebiliyoruz. DLL’in load path’i, bellekte mi, adresi gibi gibi. Burada önemli olan noktalardan bir tanesi ise çıktı içerisinde yüklemiş olduğu modülün bellekte bulunan dizini(in_mem_path) ve sistemde dosya olarak map edildiği yerin dizini(mapped) bulunmakta.

Az önce 2 çıkarımda bulunmuştuk ve şimdi de aradığımız şeyler elimizde. ldrmodules komutunu paremetre olmadan çalıştırdığımzıda bize RAM imajının içerisinde bulunan tüm process’lere ait bu verileri getirmekte. Cebimize atalım.

Teknik enjeksiyonu gerçekleştirirken disk işleminde farklı bir dizin(mapped), process yaratma işleminde farklı bir dizin(in_mem_path – malum sahte path’imiz) kullanıyordu. Eğer biz elimizde bulunan imajda “in_mem_path != mapped” olanları çıkarabilirsek Process Doppelgänging tekniği kullanılarak yaratılmış olan dosyayı bulabilir ve ilgili process’e erişebiliriz. Kısaca RAM’de Doppelgänging tekniği kullanan bir process var mı yok mu öğrenebiliriz?

Öyleyse biraz kod yazalım:

carbon

https://gist.github.com/kaganisildak/2552f009198542982648d91a3fc05b1a

Yazı için örnek olsun diye şöyle bir şey karaladım. FP ürettiğinden şuan için basit kontroller ekledim ancak işi garantiye almak için biraz daha düzenlemem şart ama şuan için mühim değil.

Kodumuz ldrmodules çıktısını alıp parse ediyor ve “in_mem_path” ve “mapped” bölümleri birbirine eşit olmayan modülleri ve process’i bize veriyor.

doppsearcher

Ve buraya da bir BINGO

“Explorer.EXE:2236” elimize düştü. Baktığımızda normal dizininde çalışıyor gibi gözüken “explorer”‘nin, Doppelgänging kullanılarak oluşturulduğunu tespit ettik.

Bitti Gibi

Öncelikle yazımda,anlatımda hata varsa affola. Okuduğunuz için teşekkür ederim. Bölüm 1’imiz burada son  buldu. Diğer bölümlerde farklı teknikler için neler yapılabileceğine bakacağız. Öneri,şikayet,eksik gedik varsa düzeltelim dikkate alalım.

İyi Analizler

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Google fotoğrafı

Google hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Connecting to %s