Andromeda Botnet Analizi
Transkript
Andromeda Botnet Analizi
Andromeda Botnet Analizi 1. Giriş 2. Anomaliler 3. Dinamik Analiz 4. Statik Analiz 5. Protokol Analizi 6. Config Dosyaları ve Hedeflerin İncelenmesi 7. Sonuç Emre TINAZTEPE Giriş 20 Aralık tarihinden itibaren NetSec mailing listesinden Turkcell’den geliyormuş gibi görünen ve eklerinde zararlı yazılım olduğu belirtilen bazı e‐postalar almaya başladık. 24 Aralık tarihinde ise benzer olayların farklı firma isimleri ile tekrarlandığını gördük. Aynı tarihte twitter gibi sosyal paylaşım platformlarında aşağıdakine benzer görüntüler paylaşılmaya başladı. Başlangıçta dikkatimizi çekmese de aynı içeriğe benzer e‐postaların THY'den geliyormuş gibi gönderilmesi, bunun düşündüğümüz gibi ‘basit’ bir spam kampanyası değil çok daha büyük bir organizasyonun yüzeydeki kısmı olduğunu belli eder gibiydi. Elimizde Turkish‐Airlines‐Itinerary.pdf.exe ve Fatura Bildirimi 609980.pdf.exe olarak isimlendirilmiş iki örnek bulunmaktaydı. İki örneğinde aynı MD5 hash’e (c7c39fea16c34d867b586fd155dca77a) sahip olduğunu gördük. Örneklerin VirusTotal tespit oranının da epey düşük olması dikkat çekiciydi. Tanıyan AV’ler de tam bir tanım vermek yerine dosyayı şüpheli olarak işaretlemişlerdi. Anomaliler Dosyayı sanal makineye atarak dinamik analiz için hazırlık yapmaya başladığımızda aşağıdaki anomaliler dikkatimizi çekti : ‐ ‐ Dosyanın bağımlılık (dependency) listesine bakıldığında anlamsız harflerden oluşan bir DLL olması, Normal şartlar altında sadece “okunabilir (read‐only)” olması gereken .rdata section’ın “yazılabilir” oluşu ve isminin garip karakterler barındırması, ‐ ‐ Hiçbir resource içermemesi, Çok az sayıda import içermesi ve normal uygulamalarda pek de rastlamaya alışık olmadığımız bazı importlar içermesi, ‐ İçerisinde bulunan metinlerin şifreli bir görünüm sergiliyor olması. Dinamik Analiz Network bağlantısı olmayan “undetected” bir sanal makinede dinamik analize başladığımızda dosyanın kendisini yeniden başlatmaya çalıştığını gözlemledik. Bu tip bir hareket dosyanın paketlenmiş içerik taşıdığının göstergesi olabileceği gibi olası debuggerlar’dan kurtulmak istemesinin de bir göstergesi olabilirdi. Hemen arkasından wuauclt.exe (Windows Update) dosyasının başlatılıyor olması underground’da ‘matruşka’ olarak tabir edilen tekniği andırıyordu. Bu andan itibaren çıkan dosyaları unpack etmeye ve sanal makinenin ana makine ile paylaşılan klasörüne kopyalamaya başladık. 3’ncü adımda çalıştırılan wuauclt.exe dosyası zincirin son halkasını oluşturuyordu. wuauclt.exe sürecini, Process Explorer ile incelediğimizde sessizliğin sebebinin network bağlantısının olmaması olduğu apaçık belliydi… Testlerimize network bağlantısını açarak devam ettiğimizde söz konusu adımların aynı şekilde tekrarladığını fakat bu sefer explorer.exe içerisinde yeni threadler yaratılarak enollo.pl adresine bağlanıldığını gözlemledik. Giden / gelen trafiği incelediğimizde, tüm trafiğin şifreli olduğu aşikardı. Trafiği, Burp Suite ile C&C sunucusuna “forward” ettiğimizde zararlının yeni uygulamalar indirerek çalıştırmaya başladığını gözlemledik. Yeni indirilen bazı dosyaların da aynı “matruşka” tekniği ile çalışması ve kendilerini yeniden başlatarak kontrolü bir sonraki aşamaya devretmesi dikkate değerdi. Tüm bu aşamalarda capture ettiğimiz network paketleri ilerleyen günlerde C&C sunucularının kapanması üzerine lab ortamında C&C sunucularını simüle etmemizi kolaylaştırdı. İlerleyen bölümlerde bu konuya da değineceğiz. Dinamik analizi tamamlamak için RegShot ile sistemde yaptığı değişiklikleri gözlemlediğimizde aşağıdaki değişiklikleri not ettik : Oluşturulan iki dosya da, e‐posta eklentisi ile gelen dosyanın birebir aynısıydı. Statik Analiz Dinamik analiz safhasını geçerek “mail eklentisi” olarak gelen dosyayı IDA ile incelemeye başladık. Dosyayı açar açmaz aldığımız ilk hata ve müteakiben gördüğümüz “SP‐Analysis failed” hatası anti‐debug / anti‐trace / anti‐vm gibi daha bir çok şeyin birazdan başlayacağının belirtisiydi. Özellikle stack pointer analizin başarısız olması, kodu reverse ederken analiste çok iş düşeceğini gösterir ki gerçekten de beklediğimiz gibi oldu. Kodun trace edilmesi ve kritik blokların bulunması epey zamanımızı aldı. Kod içerisinde gördüğümüz bir çok MOV DWORD PTR SS:[ESP] instruction’ı GCC ile derlenen bir uygulama olması ihtimalini güçlendiriyordu ya da tamamen assembler ile yazılmış bir downloader ile karşı karşıyaydık. İlk dallanmadan itibaren gördüğümüz SetUnhandledExceptionFilter APIsi, birkaç dakika içinde anti‐debug rutinleri ile karşılaşmaya başlayacağımızın açık göstergesiydi. Bu API, windows “top level exception handler”ı değiştirmek için kullanıldığı gibi aynı zamanda da çok kullanılan bir anti‐debug yöntemidir. Nedenine gelince, process içerisinde çalışan thread’lerden herhangi birisinin unhandled bir exception ile karşılaşması durumunda ancak ve ancak process “Debug” edilmiyorsa bu filtre çağırılır ve döndürdüğü değere göre exception handler kontrolü devralır. Eğer process debug ediliyorsa bu filtre hiçbir zaman çağırılmaz ve kontrol debugger’a devredilerek exceptionı fix etmesi beklenir, dolayısıyla işlem bir sonraki instructiondan devam eder. Burada FNINIT ile desteklenen ve işlemcinin exception flaglarını silerek ilerleyen ‘novel’ diyebileceğimiz bir teknik kullanılmış. Her ne kadar IDAStealth gibi anti anti‐debug pluginleri ile geçilebilse de gayet güçlü bir teknik olduğunu belirtmeden geçemeyeceğiz. İlerleyen kısımlarda iki RDTSC instruction’ı arasında geçen süreye dayandırılmış bir Anti‐Debug metodu tespit ettiğimizi düşündük. Aslında başlangıçta bunun sadece Anti‐Debug metodu olduğunu düşündüğümüz için çift dalı da kontrol etmek yerine tek daldan devam ettik. Bu da bazı forum ve sandbox raporlarında yazdığı üzere zararlının “8000” portunu dinleyip bağlanana shell verdiği dalın bu kısım olduğunu farketmemiz ile sonuçlandı. Bizimle aynı anda analiz yapan arkadaşımız Mert SARICA ile görüşmemizde Anti‐Debug olarak düşündüğümüz kısmın daha çok Anti‐Emulator olarak tasarlandığını anlamış olduk. Zararlının gövdesinin çok büyük bir kısmı XOR ile şifrelenmiş durumdaydı. En çok dikkatimizi çeken kısım ise çalışacak olan kod parçalarının çok küçük bloklar halinde çözülerek çalıştırılmasıydı. Dolayısıyla kodun büyük kısmının decrypt edilmesi için trace etmeye başladık. Aşağıdaki görüntüden de anlayacağınız gibi bazı bölümler 38 baytlık hatta daha da küçük bloklar halinde şifrelenmişti. Zararlının trace edilme korkusu ile kendi GetProcAddress implementasyonunu yaptığını farketmemiz ile kodun trace edilme hızı epey arttı. Bu fonksiyonu daha kolay takip edebilmek için VX_GetProcAddress olarak adlandırdık. Çok geçmeden aşağıdaki görüntüyü gördüğümüzde, ikinci safahanın başlamak üzere olduğunu ve kullanılan tekniğin RunPE olduğunu anlamıştık. Aşağıda Phase1.exe’nin (e‐posta eklentisi) kendisini yeniden başlatarak 3888 ID’li yeni process’in hafızasına unpack edilmiş kodları yazdıktan sonraki halini görüyorsunuz. Yeni kopyanın çalışır çalışmaz aşağıdaki kontrolleri gerçekleştirdiğini gözlemledik : ‐ Sistemde çalışan process isimlerinin hashlerini alarak aşağıdaki liste ile karşılaştırdığını, (Bu hashlerin neler olduğunu Mert SARICA’nın bloğundan öğrenebilirsiniz) ‐ Process enümerasyonunun başarısız olması durumunda GetModuleHandle(“sbiedll.dll”) çağrısı ile Sandboxie DLL’inin varlığını tespit etmeye çalıştığı, ve bunu yaparken stack’e DWORD’ler şeklinde push ederek string oluşturduğu, (Bu yöntem zararlının en azından bu kısmının ASM ile yazıldığının ispatıydı) ‐ Hemen arkasından sanal makine ve disk id kontrolü yaparak son bir RDTSC delta kontrolü yaptığı. Bu kontrollerden başarı ile geçilmesi durumunda : ‐ ‐ 32 bit sistemlerde \System32\wuauclt.exe (Windows Update) , 64 bit sistemlerde ise \SysWOW64\svchost.exe (Service Host). Peki neden bu processler? Neden 32 ve 64 bit sistemlerde farklı uygulamalar host olarak seçiliyor diye soracak olursanız; cevap iki uygulamanın da 32bit oluşu. Zararlı 3’üncü fazı bu uygulamalardan birisinin içinde gerçekleştirecek ve içlerine yalnızca 32 bit kod enjekte edebilme yeteneğine sahip, cabası bu uygulamalar, bir çok firewall tarafından otomatik izin verilen ve tüm mimarilerde bulunan uygulamalar. Bu noktada wuauclt.exe SUSPENDED olarak başlatılarak gerekli hafıza modifikasyonları yapılarak 3’üncü aşamaya geçildiğini gördük. Bu aşamada özellikle Anti‐Debug metodlarında çok fazlaca bir artış gözleniyordu. Aslında bu, ana saldırı mihverinin bir göstergesiydi. Bunun yanı sıra aşağıdaki resimde görebileceğiniz gibi çok fazla kullanılmayan başka bir yöntem ile ExitThread APIsi kancalanarak kontrolün thread sonlanmasına müteakip zararlıya geçmesi sağlanmıştı. Bu noktadan itibaren Kernel Debugger (WinDBG) ile devam ederek 3’üncü fazın analizine geçtik. 3’üncü fazın esas görevi daha önce yapmış olduğumuz dinamik analizden gördüğümüz kadarıyla zararlının C&C bağlantısını sağlamak ve yeni zararlıları download etmekti. Kodun decrypt edilmesi için uzun bir süre trace ettikten sonra internet bağlantısını kontrol etmek için kullanılan aşağıdaki windows update adresini bulduk. İlerleyen süreçte dinamik analiz safhasında gördüğümüz moid.pl ve linebench.ru adresleri ile karşılaştık. Burada gördüğümüz dizilim, önce moid.pl’ye eğer bağlantı kurulamaz ise linebench.ru ve sırasıyla diğer adreslere bağlanmaya çalışılmasını açıklıyordu. Protokol Analizi Analizin devamında protokol analizine başladık ve bu adreslere POST metodu ile gönderilen aşağıdaki veriye ulaştık. Sıra bu verinin ne ifade ettiğini bulmaya gelmişti. Burp suite ile trafiği intercept edip network fonksiyonlarına yoğunlaşmaya başladığımızda kod çok daha anlaşılır bir hale bürünmeye başlamıştı bile. Kod içerisinde XOR ve ROR lardan oluşan birkaç encrypt / decrpyt fonksiyonu tespit ettik ve bu kısımlara olan referansları incelemeye başladık. Socket fonksiyonlarından recv / send fonksiyonlarına yoğunlaşır yoğunlaşmaz karşımıza bir anda Base64 olduğu bariz belli olan başka bir fonksiyon çıktı. Hemen arkasından da RC4’e çok benzeyen başka bir fonksiyon daha tespit ettik. Bu andan itibaren daha çok zararlının kullandığı protokole yoğunlaşmaya başladık ve 7 adet komutun (update, execute, download vb.) desteklendiğini gördük. Aşağıda komutların işlendiği switch’i görebilirsiniz. Bu görüntü aslında bir yanılgının da cevabıydı : “Phase 1’den bu yana aslında packed bir downloader değil, tam kapasiteli bir bot ile karşı karşıyaydık ve görünüşe göre hikaye henüz yeni başlıyordu…” Command 9 : Delete Bot Command 1 : Download and Exec Kısa bir süre sonra karşımızdaki manzara aşağıdaki gibiydi : Bir süre sonra BotProtocolString’de yer alan girdilerin hangi inputlar kullanılarak oluşturulduğunu araştırmaya koyulduk. Sunucuya giden isteklerde uzun cevap, sunucudan gelen taleplerde ise kısa cevap kullanılıyordu. Kısa bir süre sonra yaptığımız araştırma çok güzel meyveler vermeye başlamıştı bile. BOT başta da tahmin ettiğimiz gibi RC4 kullanıyordu ve format stringin içeriği aşağıdaki gibiydi. Andromeda (W32.Gamarue) aslında başından beri karşımızda duruyordu fakat hiçbir AV’de böyle bir isme ratlamamıştık. Bu noktada, protokolde kullanılan formatı görür görmez zararlının Andromeda olduğunu anlayan ekip arkadaşım Erkan ARNAUDOV’un yönlendirmesi süreci çok hızlandırdı. Bot’un adını ve yeteneklerini daha derinlemesine inceledikten sonra, sıra sisteme indirmeye çalıştığı yeni zararlıların neler olduğunu anlamaya gelmişti. Çalışmamızın başında dinamik analiz esnasında bir çok zararlı indirildiğinden bahsetmiştik. Bunlar başlangıçta ZeuS/Zbot imzası taşıyan zararlılar olmakla birlikte, müteakip denemelerde farklı davranışlar sergileyen zararlılar download edildiğini gözlemledik. Bunlardan özellikle KBxxxxxx.exe şeklinde dosyalar oluşturan ve SSL hook atmaması ile ZeuS’dan ayrılan başka bir zararlı daha olmasından şüphelendik. TÜBİTAK BİLGEM’in yayınladığı rapor da bunu doğrular nitelikteydi. Dolayısıyla karşı karşıya olduğumuz durum aşağıdaki gibiydi : Config Dosyaları ve Hedeflerin İncelenmesi ZeuS ve Cridex ikilisi banker trojanlar olup, config dosyaları olmadan çok da işe yaramayan zararlılardır. Ayrıldıkları nokta Cridex’in config dosyasının clear text olması ve network trafiği dinlenerek capture edilebilmesidir. Aksine, ZeuS encrypted bir config dosyasına sahiptir ve piyasada config dosyasını extract edebilen tool sayısı çok azdır. BİLGEM’den Osman PAMUK ve Necati Ersen ŞİŞECİ’nin Cridex analizini okuduktan sonra kendi sistemimizde bu zararlıyı çalıştırarak bizde de aynı config parametrelerini indirip indirmediğini test etmek istedik. Çünkü görünüşe göre, zararlı, PC’den PC’ye farklı davranabiliyordu ve bu farklılık config dosyasına da yansıyabilirdi. Sanal makinede çalıştırdığımız Cridex örneği lohtikr.ru adresinden aşağıdaki bir çok bankayı içeren bir config dosyasını download etti. Şunu da belirtmeden geçmemeliyiz, config dosyasındaki toplam banka sayısı Türk bankası sayısının en az 15‐20 katıydı ve adını bile duymadığımız bir sürü banka ile karşı karşıyaydık. Cridex’in config dosyasını extract etmeye müteakip sıra ZeuS’un config dosyasının extract edilmesin gelmişti. Phase 1 de elimize geçen örneği analiz etmek istediğimizde C&C sunucuların 5 inin kapalı olduğunu gördük. Maalesef açık olan sunucu da bize ZeuS yerine Cridex push etmeye başlamıştı. Dolayısıyla mail eki ile gelen zararlı (Andromeda) artık ZeuS analizi için kullanılamıyordu. Bu noktada 4’ncü fazda capture ettiğimiz ZeuS sample’ını sanal makineye kopyalayıp capture edilen network loglarını incelemeye koyulduk ve sample’ın bağlanmaya çalıştığı enollo.pl sunucusunu HOSTS dosyasına ekleyerek ana makinemizde çalışan Apache sunucusuna yönlendirdik. Yapmamız gereken tek şey zararlıdan gelen request’e, C&C sunucusuymuş gibi cevap verip henüz ne olduğu belli olmayan fakat %99.99 encrypted config dosyası olan pipta.bin dosyasını almasını sağlamaktı. Bunun için aşağıdaki PHP scriptini flowers.php adıyla kaydetmemiz yeterli oldu. Her ihtimale karşı 7 saniyelik bir bekleme yarattık ki bu sürede snapshot alma, debugger attach etme gibi işlemler için gerekli olabilirdi. C&C Server : enollo.pl Apache 2 : 192.168.2.50 Bu aşamadan itibaren ZeuS dış dünyasından tamamen soyutlanmış bir halde lab ortamımızda çalışır haldeydi. Kodu API Monitor ile trace etmeye başladığımızda 16 KB’lık dosyayı toplamda 4 InternetReadFile çağrısı yaparak okuduğunu tespit ettik. Beklemeyi ister sunucu tarafında istersek de client tarafında gerçekleştirebilir, dilediğimiz gibi dosyanın hafızaya yüklenişini izleyebilirdik. İkinci yaklaşım daha esnek olduğu için API monitor ile InternetReadFile çağrısına break point koyarak “Break After” seçeneğini işaretledik. ZeuS’un içerisine kod enjekte ettiği Explorer.exe sahte C&C sunucusuna bağlanarak şifrelenmiş config dosyasını talep etti. 4’üncü çağrıyı devam ettirmeden hemen önce Kernel Debugger ile buffer’ın bulunduğu adrese bir hardware breakpoint koyduk. Aradan çok da zaman geçmeden ZeuS config dosyası ile başbaşaydık. Bu andan itibaren dosyanın boyutu olan 0x3F87 sayısına odaklanmaya başladık. Keyifli bir traceden sonra aşağıdaki manzara ile karşı karşıyaydık : Adrese dikkat edecek olursanız, şifreli pipta.bin dosyamızın hafızada açılmaya başladığını görebilirsiniz. Peki URL’ler gayet net görünmekte iken, neden alt kısımda görünen metinler sanki karıştırılmış gibiydi? Acaba heap’de bir adrese bakıyorduk da farkında mı değildik yoksa bu adres pipta.bin’in yüklendiği adres miydi? Ta kendisiydi fakat bir sorun olduğu apaçık belliydi. Bu noktada kodun içine daha fazla girmemek için ZeuS decryptorları araştırmaya başladık ve PCTools tarafından yayınlanmış Config Decrpytor aracını bulduk fakat outdate bir tool olduğu için bu araçtan da bir sonuç alamadık… Yine iş başa düşmüştü, config dosyasının aslında sadece encrypted olmadığını, aynı zamanda da compressed olduğunu anlamamızla hemen kendi ZeuS Config Viewer’ımızı yazmaya koyulduk. Config dosyasının formatını araştırmamız ve ZeuS kaynak kodlarını incelememiz ile formatın aşağıdaki gibi olduğunu tespit ettik. Bu bilgiler ışığında elimizdeki decrpyted config dosyasını decompress edebilecek bir toolu hazırlamamız çok da uzun sürmedi. Aşağıdaki resimde decompress edilmiş C&C sunucu listesini görebilirsiniz. Aracı buradan indirebilirsiniz. Config dosyasından çıkardığımız sunucular aşağıdaki gibiydi : http://cormo.pl/walkmanager.php http://tribes.pl/table.php http://beastbrick.ru/baby.php http://coredis.pl/finance.php http://papersled.ru/uganda.php http://netfest.pl/jikajika.php http://juicepoet.ru/bike.php http://scentdonut.ru/fine.php Peki hedef alınan bankalar hangileriydi? Garip fakat Cridex config dosyasında gördüğümüz yüzlerce bankanın yanında ZeuS config dosyasında sadece aşağıdaki bankalar hedef alınmıştı… Sonuç Sistemli bir saldırıya şahit olduk. Analizimiz boyunca farklı trojanlar ve hedefler arasından en çok dikkatimizi çeken şey NetSEC mailing listesinden temin ettiğimiz XTreme RAT örneği içeren http://downtest.sytes.net/x.exe adresi oldu. Her ne kadar incelediğimiz örnekler arasında XTreme RAT’ın C&C sunucuları tarafından push edildiğine rastlamamış olsak da, yazımızda daha önce de belirttiğimiz gibi enfekte edilen sistemin özelliklerine hatta ve hatta ülkelerine göre zararlı push edebilecek bir yapıya sahip oluşu büyük bir şüpheyi uyandırmaya yetiyordu… İşin ucunda XTreme RAT olduğunu duymak açıkçası korkutucuydu çünkü aynı RAT komşu ülkelere düzenlenen bazı siber saldırılarda kullanılmıştı ve bu saldırıda da kullanan her kimse “kredi kartı” hırsızlığından daha büyük bir hedefi olduğu aşikardı… Neden derseniz, bu zararlı banker trojanden ziyade daha çok dinleme / izleme amaçlı kullanılan ve audio capture özelliği ile göze çarpan bir trojan. İlgili adresten indirdiğimiz trojan’i test ettiğimizde karşımıza çıkan iki adet IP ve domain’in satın alındığı hosting providerın Türkiye’de oluşu, üstüne üstlük adresin Vodafone 3G IP bloğundan alınmış olması, alışveriş merkezinin birinde oturmuş mobil modemi ile bağlandığı C&C sunucusuna bakarak kahvesini yudumlayan bir korsanı aklımıza getiriyordu. Konu ile ilgili arzu eden resmi kurumlara araştırmada kullandığımız her türlü dökümanı sağlamaya hazırız. Bu konuda detaylı bilgi almak için services@zemana.com adresine mail atabilirsiniz.