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
[email protected]
adresine
mail
atabilirsiniz.