Bir önceki yazıda int 2dh komutunun debugger'ı nasıl etkilediğinden bahsedilmiş ve bu tekniği atlatmanın yollarından bahsedilmiştir. Bir Anti-Debugger tekniği olan int 2dh atlatıldıktan sonra aşağıdaki komutlarla karşılaşılacaktır.
CALL Max++_do.00413BB4 rutini ilgi çekmektedir. Bunun sebebi kendisinden sonra gelen komutların gözlenen sırada oldukça anlamsız olmasıdır. Bu yargıyı doğrulamak için CALL Max++_do.00413BB4 rutini çağırılmadan önce ve sonra çalıştırılabilir kod dizilimine bakmak yeterli olacaktır. Yukarıda verilen resim CALL Max++_do.00413BB4 çağırılmadan önce hafızanın hali, aşağıdaki ise hemen çağırıldıktan sonraki halini göstermektedir.
Resimlerden de anlaşılacağı üzere , zararlı yazılım Runtime içerisinde kendisinin kodlarını değiştirmektedir. CALL Max++_do.00413BB4 fonksiyonu belirli algoritmaları uygulayarak program akarken işlenecek komutları değiştirmektedir. Burada karşılaşılınan durum da bir Anti-Debugging ve aynı zamanda Anti-Virus yazılımlarından kaçma tekniğidir. Zararlı yazılım hafızaya alındığında zararlı her hangi bir fonksiyonu yokmuş gibi davranarak anti-virus yazılımlarından kaçmaya çalışmaktadır.
Şimdi zararlı yazılımın kendi kodlarını değiştirmek için kullandığı CALL Max++_do.00413BB4 fonksiyonunun içine girilerek algoritma daha detaylı incelenecektir. CALL Max++_do.00413BB4 rutinine girildiğinde aşağıdaki kod parçası bulunacaktır.
Biraz daha ilerlendiğinde görülecektir ki 00413BF6 lokasyonundaki JMP instructionu, zararlı yazılımı runtime içerisinde decrypt ediyor. JMP instruction'unu geçtikten sonra karşımıza aşağıdaki kodlar çıkacaktır.
İlk önce EAX register'ına FS:18 değeri atılıyor. FS:18 TIB(Thread Information Block) (aynı zamanda TEB olarak adlandırılıyor) adı verilen bölgeyi temsil ediyor. Zararlı yazılım TIB 'e ve ardından TIB+30 lokasyonunda bulunan değere erişiyor. TIB+30 lokasyonunda PEB(Process Environment Block) değerine erişiyor.En sonunda da ECX register'ına InInitilizationOrderModuleList'i gösteren pointer atılıyor.
Zararlı yazılım bu bilgileri kullanarak daha önceden import edilmiş fonksiyonların listesine erişerek kendi kendisine yeni bir import tablosu yaratıyor. Daha sonra kodu parça parça decrypt ediyor. Bunu yaparak ilk yazımızda baktığımız imported functionlarda hangi fonksiyonları kullandığını gizlemeyi başarıyor. İhtiyacı olduğu zaman import tablosunu yapılandırarak gereken fonksiyonlara ulaşıyor. Karmaşık ve takip etmesi bir hayli zor bir döngüden sonra 2. resimde gösterildiği gibi zararlı yazılım kendi kendisini runtime içerisinde değiştiriyor. Bu döngü geçildikten sonra aşağıdaki kod parçası ilgi çekecektir.
Zararlı yazılım lz32.dll'ini çağırıyor ve ardından Session Object yaratarak kurban sisteme sızma işleminin büyük bir kısmını tamamlıyor. Session Object'lerden bahsetmek gerekirse;
Session Object'ler prosesler arasında ortak kullanılabilecek bir hafıza alanı yaratabilir, herhangi bir dosyanın içeriğini yaratıldığı prosesin içerisine aktarılabilir. Burada Session Object, zararlı yazılım tarafından başka bir çalıştırılabilir dosyayı kendi içerisine enjekte etmek için kullanacaktır. lz32 rutinine girildiği zaman aşağıdaki kod parçası ile karşılaşılacaktır.
CALL lz.32 instruction'u çağırıldığı zaman zararlı yazılım aşağıdaki döngüye girecektir.
Yukarıdaki resimde görüleceği üzere, zararlı yazılım ntdll.RtlAdjustPrivilege rutinine giderek tekrar bir anti-debugging tekniği kullanmak istiyor. Bu tekniği kısaca özetlemek gerekirse, debuggerlar herhangi bir prosesi debug edebilmek için sistemden debug yetkisi almalıdırlar. Zararlı yazılım burada prosese herhangi bir debugger bağlı olup olmadığını böyle bir yetkinin verilmiş olup olmamasına göre anlamaya çalışıyor. Ollydbg ile ilerlendiği zaman zararlı yazılımın bunu tespit edemediği görülecektir.(Ollydbg bunu atlatıyor.) Biraz daha ilerlendiğinde 2 tane CALL instructionu dikkat çekecektir.
İlk CALL instruction'una girildiğince aşağıdaki kod ile karşılaşılacaktır. Burada ilk göze çarpan şey, kırmızı renk ile seçilmiş bölgeden anlaşılacağı üzere zararlı yazılımın sistemdeki driverları belirlemeye çalışmasıdır. Bunu neden yaptığı yazımızın ilerleyen kısımlarında anlaşılacaktır.
Driverlar tarandıktan sonra zararlı yazılım aşağıdaki kod parçasına yönleniyor. Bu kod parçasından görüleceği üzere öncelikle rastgele bir sayı üretiyor.
Rastgele(random) bir sayı üretmek için besleme değeri olarak kernel32.GetTickCount isimli fonksiyona erişiyor. Bu fonksiyon bilgisayar başlatıldıktan sonra geçen süreyi dönüyor. Aşağıda MSDN sitesinden alınan bir ekran görüntüsü görülebilir.
Rastgele sayı üretildikten sonra, üretilen sayıya göre driver listesinden rastgele bir driver seçiliyor. Daha sonra seçilen driver için bir Session Object oluşturuluyor.
Yaratılan Session Object'in Access değerine bakılacak olursa f001f değeri bize yaratılan Session Object'in her türlü izine sahip olduğunu gösterecektir. Bu demektir ki Session Object tıpkı bir executable gibi çalıştırılabilecektir.
Yaratılan Session Object zararlı yazılım için gerekli olan her türlü ihtiyacı sağlayacak ve çalışabilmesi için ona uygun bir ortam sağlayacaktır. Runtime içerisinde yaratılan bu executable sayesinde Anti-Viruslere yakalanmadan sistemlere sızabilme ihtimali oldukça arttırılmıştır.
Bir sonraki yazıda Session Object yaratıldıktan sonra içerisine enjekte edilecek olan zararlı yazılım detaylı incelenecektir.