VM'in CPU fanı varmış gibi görünmesini sağlayarak kötü amaçlı yazılımı kandırmak

 (wbenny.github.io)
9 puan yazan GN⁺ 2025-06-30 | 1 yorum | WhatsApp'ta paylaş
  • Kötü amaçlı yazılımlar, sanal ortamda çalışmaktan kaçınmak için CPU fanı gibi donanımların varlığını kontrol eder
  • CPU fanı bilgisi WMI'nin Win32_Fan sınıfı üzerinden kontrol edilebilir ve bu veri SMBIOS içinde saklanır
  • Xen'de özel SMBIOS verisi eklemek için yama ve ek yapılandırma gerekir; ayrıca hem Cooling Device(Type 27) hem de Temperature Probe(Type 28) tablolarının yapılandırılması gerekir
  • QEMU/KVM'de ek yama olmadan -smbios seçeneği ile özel SMBIOS kolayca uygulanabilir
  • Böylece sanal makine, CPU fanı varmış gibi gösterilerek kötü amaçlı yazılımın tespit mekanizmasını atlatma denemesi yapılabilir

Bu neden yapılıyor?

  • Bazı kötü amaçlı yazılımlar, sanal ortamda çalışıp çalışmadığını anlamak için belirli donanımların (ör. CPU fanı) mevcut olup olmadığını kontrol eder
  • Win32_Fan gibi WMI sınıfları ile donanımı denetler; bu bilgi yoksa bunun bir sanal makine olduğuna karar verip çalışmayı reddeder
  • Amaç, analistlerin kötü amaçlı yazılımı incelemesini engellemektir
  • Win32_CacheMemory, Win32_VoltageProbe gibi çeşitli WMI sınıfları vardır, ancak bu yazı CPU fanına odaklanır

Bilgisayar CPU fanı olduğunu nasıl anlar?

  • Bilgisayar, SMBIOS bilgisini okuyarak soğutma aygıtının (CPU fanının) varlığını algılar
  • Win32_Fan örneği cimwin32.dll tarafından sağlanır ve ilgili DLL fan bilgisini SMBIOS type 27 girdisinden okur
  • DLL hooking gibi yöntemler de mümkün olsa da SMBIOS'u doğrudan değiştirmek daha iyi bir yaklaşımdır

SMBIOS Type 27

  • SMBIOS type 27, "Cooling Device" anlamına gelir
  • SMBIOS içindeki Cooling Device verisi dmidecode aracıyla doğrudan incelenebilir
  • Örnek:
    • Type: Chip Fan
    • Status: OK
    • Description: CPU Fan
    • Nominal Speed: 5600 rpm vb.

Xen'de özel SMBIOS verisi nasıl yapılandırılır?

  • Xen'de domain yapılandırma dosyasındaki smbios_firmware seçeneği kullanılarak SMBIOS verisi ikili biçimde doğrudan belirtilebilir
  • smbios.bin dosyası oluşturulup Cooling Device(type 27) verisi eklenir
  • SMBIOS struct boyutu (ör. 24 bayt) başına 32 bit little-endian tamsayı olarak eklenmelidir

Sorun: struct override kısıtı

  • Xen, yalnızca 0, 1, 2, 3, 11, 22, 39 numaralı struct'ların üzerine yazılmasına izin verecek şekilde kısıtlanmıştır
  • type 27 varsayılan olarak izinli değildir; bu nedenle kaynak kod yaması gerekir
  • Xen geliştirici forumunda ilgili yama önerilmiş olsa da resmî olarak kabul edilmemiştir (yamayı uygulayıp derlemek gerekir)

Type 28 de gerekir

  • Cooling Device(type 27), Temperature Probe(type 28) ile ilişkilidir
  • SMBIOS'ta type 28 girdisi yoksa Win32_Fan sınıfında düzgün şekilde görünmez
  • Doğru algılama için host sistemin type 28 verisi alınıp smbios.bin içine eklenmelidir

Nihai smbios.bin yapısı

  • Hem Type 27 hem de Type 28 verisini içerir
  • Her struct'ın önüne boyut bilgisi (little-endian) eklenir
  • Örnek: 18 00 00 00 ... (type 27) ... 29 00 00 00 ... (type 28) ... biçimi

Xen'de uygulama ve doğrulama

  • Domain oluşturma komutuyla Windows sanal makinesi başlatıldıktan sonra WMI'da Win32_Fan sınıfının düzgün algılanıp algılanmadığı kontrol edilir
  • Description: Cooling Device, Status: OK görünmesiyle CPU fanının başarıyla algılandığı anlaşılır

QEMU/KVM'de SMBIOS verisi yapılandırma

  • QEMU/KVM'de -smbios file=yol seçeneğiyle özel SMBIOS kolayca yapılandırılabilir
  • Struct boyut bilgisi olmadan yalnızca raw veri kullanılır
  • Host'un SMBIOS verisi doğrudan kullanılsa da sorun olmaz

Başvuru kaynakları

  • Xen domain yapılandırma dosyası dokümantasyonu, mcnewton'ın kurulum notları, reddedilen Xen yama arşivi, System Management BIOS Reference, QEMU Anti Detection yaması vb.

İlgili okumalar

1 yorum

 
GN⁺ 2025-06-30
Hacker News görüşleri

  • Yeni bir anti-malware yöntemi olarak pasif soğutmalı bir PC satın almak da var; ayrıca Rusça klavye düzeni ayarlamanın da dolandırıcılık amaçlı malware'i engelleyen bir ipucu olduğundan bahsediliyor, bkz. ilgili bağlantı

    • Ben gerçekten Streacom FC8 Evo pasif soğutmalı bir Linux PC ve Rusça klavye kullanıyorum, ancak dmidecode komutuna baktığımda soğutma aygıtı bilgisi hâlâ mevcut ve soğutma aygıtı gerçekten algılanıyor; sensör verilerinde sıcaklık bilgisi de görülebiliyor

    • Pasif soğutmalı bir PC kullansanız bile anakartta genelde fan header'ları kalır; fiilen bağlı olmasalar da büyük bir fark yaratmayacakları görüşü

  • smol pp gibi bir dil kullanmamak gerektiği söyleniyor; bedensel aşağılama içeren ifadelerin dile yerleşmesine dikkat çekiliyor

    • Benim şehrimde SML PP özel plakalı biri var, ama nedenini bilmiyorum

    • "Bizim dilimiz" ifadesi kullanılırken bile, bir blog yorum bölümündeki birinin biz demesinin başlı başına muğlak olduğu görüşü

  • İşletim sistemini sanki sanal makineymiş gibi göstermek güvenliği artırabilir ve araştırmacılara yardımcı olabilir; sanallaştırılmamış erişim isteniyorsa bunun için mutlaka yetki alınması gerekir ve böylece malware, araştırmacı analizinden kaçınmak uğruna sıradan kullanıcıları da hedeflememeyi seçebilir; sonuçta malware yazarları hariç herkes kazanır iddiası

    • Normal bir işletim sistemini VM gibi göstermekten ziyade, asıl olanın sanal makinenin sanallaştırıldığını hiç fark etmemesi olduğu; IBM'in lpars sisteminin bu şekilde çalıştığı görüşü

    • Bu yaklaşımın anti-cheat yazılım şirketlerine de zarar vereceği belirtiliyor; ben yazılımımın nerede çalıştığını açıkça bilmek isterim ama hile yapanlardan da çok hile kullanıcılarından nefret eden çok oyunculu oyun kullanıcıları olduğu için pratikte değişimin zor olduğu görüşü

    • Mobil geliştirme dünyasında bu çerçevenin zaten fiilen gerçek olduğu görüşü

  • Şimdiye kadar tüketici tipi anakartlarda SMBIOS açıklamalarının gerçek donanımla örtüştüğünü hiç görmediğim söyleniyor; bu tür SMBIOS kontrolleri gerçek donanımın %50'sinde başarısız olsa bile, VM ya da debugger'ların %100'ünü güvenilir biçimde engelliyorsa malware açısından yine de değerli olabilir; ancak bu yaklaşımdan daha güvenilir olanın muhtemelen zaman ölçümüne dayalı kontrol olacağı düşünülüyor

    • SMBIOS açıklamalarının gerçek donanımla uyuşmaması özellikle ucuz Çin menşeli kutularda daha belirgin; to be filled in by OEM gibi doldurulmamış değerler gerçek live BIOS image'larında kodlama sırasında sık görülüyor, dolayısıyla yalnızca bu değerler bile yeterince komik bir durum oluşturuyor

    • Malware'de de bolca bug var; geçmişte ağ kodundaki hatalar yüzünden bir virüsün amaçlananın yarı hızında yayıldığı örnekler olduğu gibi, malware tüm cihazları enfekte etmese bile yine de muazzam zarar verebilir

    • Bugünlerde Linux'un fanları nasıl algıladığını merak ettiğini, ACPI mı yoksa EFI mı kullandığını bilmediğini ve kendi cihazlarında fan/sensörlerin çoğunlukla doğru algılandığını söyleyen bir soru

    • Bu SMBIOS kontrolünün gerçekten sahadaki malware tarafından mı kullanıldığı, yoksa yalnızca araştırmacıların oluşturduğu örneklerde mi görüldüğü soruluyor

  • Malware'in analizi zorlaştırmak için API kullanan numaraları sevimli görünebilir, ama bu tür API çağrıları çoğu zaman statik analizde kolayca tespit edilir ve binary obfuscate edilmemişse hatta ters tepebilir; gerçekten amaçlı yazılımlar genelde güvenilen bir CA imzasıyla dağıtıldığından, güvenlik analizi açısından bunlar zaten şüpheli davranış olarak iyi yakalanır; junior dönemimde regex kalıplarıyla bu API kullanımlarını avlama işi yapmıştım ve geniş çapta dağıtılmış temel kötü amaçlı yazılımları yakalamada epey etkiliydi

    • Son dönemde malware de oldukça sık dosya imzalıyor; malware üreticilerinin artık binary imzalamayacağını ummak yanlış, çalınmış code-signing sertifikaları yaygın ve Microsoft da mevcut müşteri yazılımlarının bozulmasından çekindiği için sertifika iptalinde isteksiz kalıyor; ayrıca malware'in çekirdeğe sızmak için zafiyetli sürücülerden yararlandığı da sık görülüyor; bu yüzden WMI çağrıları yapan küçük şüpheli bir binary yerine, güvenlik açığı dolu bir overclock utility aynı sorguları yaptığında pek kimsenin dikkatini çekmiyor; pratikte bu yöntemin amacı tespitten kaçmak değil, analistin PC'sinde malware payload'ının etkinleşmesini önlemek; tespit edilirse ikinci aşama payload indirilmiyor ve gerçek saldırıyı başlatabilecek C&C davranışı erteleniyor

    • Güvenlik açısından tüm yazılımları VM içinde çalıştırmanın daha iyi olup olmayacağı öneriliyor

    • Antivirüsün yalnızca statik analizle bir şeyin malware olup olmadığını tahmin etmesi de sorunlu; o zaman en baştan whitelist yaklaşımıyla yalnızca güvenilen yazılımlara izin verip geri kalan her şeyi malware saymakla sonuç aynı olur iddiası

    • CrowdStrike gibi şirketlerin kernel seviyesinde çalışan vasat yazılımları resmî olarak imzalatıp her türlü system call'u yapabildiği ve kimsenin bunu umursamadığı eleştiriliyor; VM olup olmamasından bağımsız olarak production'a doğrulanmamış kod ve release'ler sürülüyor, sonra dünya gerçekten aksıyor, uçuşlar gecikiyor ya da kritik altyapılarda olaylar yaşanıyor ama ciddi sorumluluk alınmıyor; hatta meşru şirketlerin bazen hacker'lardan ya da devlet düzeyindeki saldırganlardan daha büyük zarar verebildiği söyleniyor; xz utility olayı da SolarWinds ve ClownStrike ile karşılaştırılabilecek ölçekte büyük bir güvenlik vakası olarak değerlendiriliyor

  • Bir infosec arkadaşının malware honeypot'larını gerçek donanımla tamamen aynı görünecek şekilde hazırlamak için zamanının çoğunu harcadığını gördüğünü anlatan bir yorum var; Windows XP tabanlı termostatlardan Siemens PLC kontrolörlerine, bankacılık masaüstlerine kadar çok farklı cihazların inanılmaz ayrıntılı biçimde ayarlanması şaşırtıcı bulunuyor

    • Lütfen dünyada Windows XP ile çalışan termostatlar olmasın diye duyulan endişe

  • Hackintosh kurarken uygun SMBIOS'un mutlaka gerekli olduğunu hatırlatan bir yorum var; son birkaç on yılda nispeten niş birçok PC API'si eklendi ve bunlar sanallaştırma yazılımlarının ya da malware'in bu ayrıntıları ne kadar iyi yansıttığını test etmek için sık kullanılıyor; bir adım ileri gitmek için gerçek CPU yüküne göre dinamik değişen sıcaklık sensörü simülasyonu da gerekeceği değerlendirmesi yapılıyor

  • Mitre ATT&CK T1497.001 (VM Detection) kapsamında SMBIOS kontrolünün bilinen bir vektör olduğu belirtiliyor; ben de deneyince güç kaynağını HotReplaceable=Yes, Status=OK olarak ayarlayıp sistemi 5.000 dolarlık bir bare-metal sunucu gibi gösterebildim; kullanılan komut şuydu: pip install dmigen sonrası dmigen -o smbios.bin --type0 vendor="American Megatrends",version="F.1" --type1 manufacturer="Dell Inc.",product="PowerEdge T630" --type39 name="PSU1",location="Bay 1",status=3,hotreplaceable=1

    • Bu arada, Hacker News'te gerçek satır sonu oluşturmak için ya iki kez ya da daha fazla Enter'a basmak ya da her satırı iki boşlukla girintileyip code mode olarak yazmak gerektiğine dair bir ipucu da veriliyor