Makale Kapsamı:
-
Akamai Hunt, meşru bir büyük dil modeli (LLM) API endpoint’inin arkasına saklanmaya çalışan yeni bir kötü amaçlı yazılım ailesi tespit etti.
-
Bu zararlı, standart bir şema kullanmak yerine, komuta-kontrol (C2) bağlantısını kurmak için Base64 ile kodlanmış gibi görünen bir string gönderiyor.
-
Bu yaklaşım, saldırganın sistemi tamamen uzaktan kontrol etmesine ve veri sızdırmasına (data exfiltration) kapı açabiliyor.
-
Bu vaka, saldırganların saldırı yöntemlerini ne kadar hızlı evrimleştirdiğinin bir başka örneği ve kurumların modern tehditlere hazırlıklı olması gerektiğini bir kez daha gösteriyor.
Giriş
Tehdit ortamı, yapay zekanın önlenemez hızıyla birlikte değişiyor ve saldırganlar bu değişime çok hızlı uyum sağlıyor. Büyük dil modelleri (LLM’ler) kurumlarda yaygınlaştıkça, bu modellerin iletişim kalıpları saldırganlara kötü amaçlı trafiği çok açık bir şekilde gizleme fırsatı sunuyor.
Savunma tarafında güvenlik ekipleri; alarmları incelemek, özetlemek ve göstergeleri ilişkilendirmek için LLM’leri tespit hatlarına entegre etmek için yarışırken, kötü amaçlı yazılım geliştiricileri de aynı araçlarla deney yapıyor. Metin üretimi için tasarlanmış LLM’lerin nasıl kötüye kullanılabileceğini gösteren LameHug ve PromptLock gibi örnekleri çoktan gördük.
Benzer şekilde, saldırganların OpenAI API’sini komuta-kontrol (C2) altyapısı olarak kullandığı SesameOp gizli bağlantısında da, yapay zeka dünyasında tamamen yeni bir saldırı yüzeyinin ortaya çıktığına tanık olduk.
Kısa süre önce API Security alanındaki iş ortağımız Akamai (eski adıyla Noname) ekibi, LLM suistimaline farklı bir açıdan yaklaşan, kötü amaçlı trafiği LLM API isteklerinin arasına karıştıran yeni bir zararlı yazılım keşfetti. Bu blog yazısında Akamai Hunt ekibinin, bir müşterilerinde ortaya çıkardıkları bu yeni ve yükselen tehdidin bir örneğini sizlerle paylaşacağız.
Endpoint’in kötüye kullanımı
Akamai’nin son araştırmasını incelerken özellikle dikkat çeken bir örnekle karşılaştık. LLM tabanlı saldırı örüntülerini takip ederken karşımıza çıkan bu dosya, VirusTotal’da zaten kötü amaçlı olarak işaretlenmişti ve çeşitli YARA (Yet Another Ridiculous Acronym) kurallarıyla eşleşiyordu. Bu nedenle ilk beklentimiz, daha önce de örneklerini gördüğümüz şekilde, saldırganın bir LLM üzerinden kod ürettirip kurban makinede çalıştırması, yönündeydi. Ancak ilerledikçe çok daha sofistike bir yaklaşımın kullanıldığını gördük.
Zararlı yazılımın ilk adımı, bir socket bağlantısıyla 39.97.57[.]244 adresine erişmeye çalışmak. Bu girişim başarısız olunca, saldırı akışı doğrudan ilginç bir HTTP tabanlı C2 endpoint’ine kayıyor:
1347790942-k1bok35vg3.ap-guangzhou.tencentscf[.]com/v1/chat/completions
Bu noktada bize en ilginç gelen şey, endpoint’e yapılan ilk HTTP isteğinin bir LLM API çağrısında bulunması için zorunlu olan header’ları hiç içermemesi oldu. Bu hem alışılmadık hem de saldırganın kamuflaj stratejisine işaret eden önemli bir detay.
API endpoint’i
Bu noktada biz de LLM API kullanım örüntülerine özellikle odaklandık. Özellikle /v1/chat/completions endpoint’i kritik bir konumdaydı, çünkü sektör genelinde OpenAI’yi taklit eden çok sayıda API, gateway ve servis tarafından benimsenmiş durumda.
OpenAI dokümantasyonu bu endpoint’i şu şekilde tanımlıyor:
“Verilen sohbet konuşması için bir model yanıtı oluşturur.”


Bu endpoint, OpenAI’nin yaygınlaşmasıyla birlikte kısa sürede OpenRouter, Hugging Face gibi çok sayıdaki sağlayıcı tarafından kopyalandı ve “OpenAI-compatible API” kavramı artık kendi başına bir standart hâline geldi.
Ancak bu standart resmî bir RFC değil. Yani herkes uyuyor gibi görünse de aslında kimse uymak zorunda değil ve bu durum, saldırganlara mükemmel bir kamuflaj alanı sağlıyor
İstek şeması
Sektörde yaygın kabul görmüş şema genel olarak şu üç zorunlu parametreye dayanıyor:
-
Authorization
Authorization: Bearer YOUR_API_KEYheader’ı ile kimlik doğrulama. -
Model
Sohbet yeteneğine sahip modelin seçildiği string tanımlayıcı.
(Örneğin:gpt-3.5-turbo,Llama-4-Maverick-17B-128E-Instruct-FP8) -
Messages
Rol ve içerik alanlarından oluşan, modelin bir sonraki yanıtı üretmek için ihtiyaç duyduğu geçmiş konuşma bağlamı.
Akamai’nin daha önce tespit ettiği LameHug vakasında saldırganlar bu endpoint’i suistimal ederek Hugging Face üzerindeki bir LLM’e komut ürettirmiş ve kurbanda çalıştırılacak kodu dinamik olarak oluşturmuşlardı.

Chat completions üzerinden kamuflaj
Akamai araştırmasındaki örnekte ise saldırgan çok daha farklı bir yol izliyor.
Binary analizinde ilk olarak şu nokta dikkat çekiyor: Saldırgan şemaya dair hiçbir alanı kullanmıyor.
Ne model, ne messages, ne Authorization…
Bunun yerine, tamamen Base64 ile kodlanmış gibi görünen bir gövde gönderiyor.

Bu davranış iki ihtimali akla getiriyor:
-
Arka tarafta gerçekten bir LLM olabilir ve saldırgan özel bir sunucu-side prompt ile çalışıyor olabilir.
-
Ama çok daha olası olanı: Bu endpoint yalnızca kamuflaj olarak kullanılıyor.
Akamai’nin değerlendirmesi ikinci senaryonun doğru olduğu yönünde.
Çünkü API Security ürünümüzden elde edilen verilerde toplam 151 farklı chat/completions kullanımı görülüyor. Hepsi küçük farklarla da olsa aynı şemaya yakın davranıyor. Bu bize, resmi olmayan ancak sektörün fiilen benimsediği bir uygulama standardı olduğunu gösteriyor. Saldırganlar ise tam da bu standardın arkasına saklanmış durumda.
Daha derin analiz
Gönderilen gövde (body) çözüldüğünde ve 0xBB değeriyle XORlandığında, ilk keşif (reconnaissance) aşamasında kullanılan veri karşımıza çıkıyor.
Ardından zararlı yazılımın yanıtı nasıl işlediğini izlediğimizde ise şu görülüyor:
-
Beklenen yanıt LLM API şemasına uymuyor.
-
Gelen veri tekrar XOR + Base64 ile çözülüyor.
-
Ardından yanıt içindeki talimatlar birebir uygulanıyor.

C2 sunucusu olan
1347790942-k1bok35vg3.ap-guangzhou.tencentscf[.]com,
Tencent Cloud üzerinde çalışan bir Serverless Cloud Function. Bu yaklaşım saldırganlara:
-
otomatik ölçeklenebilen,
-
geçici olmayan,
-
meşru trafiğe karışan
bir C2 altyapısı sağlıyor.
Dolayısıyla savunma açısından hem tespiti zorlaşıyor hem de network analizinde “normal” görünme olasılığı artıyor.
Bu yazılım ayrıca birden fazla talimat (instruction) barındırıyor. Bu da onu net şekilde bir remote access trojan (RAT) sınıfına sokuyor.
Örneğin $HunterInfo talimatı, kurbanda belirli uzak erişim araçlarına ait konfigürasyon dosyalarını buluyor ve aynı XOR + Base64 yöntemiyle geri iletiyor.

Gömülü dosyalar ve proxy altyapısı
Zararlı yazılım içinde 0x88 ile XORlanmış ve Base64 kodlanmış üç adet gömülü dosya bulunuyor.
Üçü de aynı isimde: net_test.exe
Görevleri ise şu şekilde dağılıyor:
-
İki adet sunucu bileşeni
-
SOCKS5 sunucusu
-
HTTP sunucusu
-
-
Bir adet istemci bileşeni
-
trafiği alıp yönlendiriyor
-
Bu yapı kurbanın bulunduğu ağda küçük bir proxy ekosistemi yaratıyor.

Ek dosyalar ve çok aşamalı saldırı zinciri
Sonrasında ekip aynı kötü amaçlı yazılım ailesinin daha eski varyantlarına ulaşıyor.(Hash değerlerini aşağıda IOC bölümünde görebilirsiniz.)
Buna ek olarak, aynı C2 altyapısıyla ilişkili bir RAR arşivi VirusTotal’da tespit ediliyor. İçeriğinde:
-
Çincede “özgeçmiş” anlamına gelen 个人简历.lnk
-
Zararlı bir
ftp -s"" :_/_/_/...çağrısı -
İç içe klasörlerde yer alan ve içeriği aslında binary kod olan .doc dosyaları
bulunuyor.

RAR içindeki _ dosyası, .doc dosyalarını PE formatına dönüştürüyor ve bunları şu dizine kopyalıyor:
C:\Users\Public\Update
Ardından bir sonraki aşama tetikleniyor:

Zaman bilgisinin kullanılması, .doc dosyalarına dinamik olarak MZ header eklenmesi ve dosyanın dakikaya göre adlandırılması, imza tabanlı tespitleri atlatmak için kullanılan yaratıcı yöntemler arasında.
svchost.exe ve 360 DLL zinciri
Zincirin bir aşamasında çalıştırılan svchost.exe, aslında tamamen meşru bir dosya:
SangforPromote.exe
-InstallLsp parametresi ile çağrıldığında verilen DLL’i LoadLibrary aracılığıyla yüklüyor.

Bu DLL (adı 360):
-
RWX izinli bellek ayırıyor,
-
içine sc adlı bir payload yüklüyor,
-
ardından doğrudan çalıştırıyor.
sc adlı bileşen ise:
-
API fonksiyonlarını dinamik olarak çözüyor (
LoadLibrary,GetProcAddress) -
İki sabit C2 adresiyle iletişime geçiyor:
-
39.97.57[.]244
-
Veriyi yine Base64 + XOR yöntemiyle işliyor
Bu bileşenin kurbana son RAT yükünü indirdiği görülüyor.

Chat completion temelli tehditleri nasıl tespit edebilirsiniz?
Quasys teknik ekibi olarak bu tür saldırıların önümüzdeki dönemde daha sık görülmesini bekliyoruz. Tespit ve koruma için üç temel önerimiz var:
1. LLM’lerinizi tanıyın
Hangi endpoint’lerin kurum içinde gerçekten kullanılmasının beklendiğini net şekilde belirleyin.
“Shadow AI” kullanımını engellemek için görünürlük şart.
2. LLM endpoint trafiğini izleyin
/v1/chat/completions dahil tüm LLM endpoint’lerine giden outbound trafiği gözlemleyin.
Model, messages veya Authorization alanları eksik/bozuksa mutlaka şüphe duyulmalı.
3. Dosya aktivitelerini izleyin
C:\Users\Public gibi dizinler kötü amaçlı aktiviteler için çok kullanılan alanlardır.
Yeni dosya oluşturma, PE türetme ve benzeri davranışları takip edin.
Akamai Hunt koruma ve önleme yetenekleri
Akamai Hunt’ın 7/24 sürekli izleme modeli, bu tür gelişmiş ve çok aşamalı saldırıları daha davranışsal seviyede tespit edebilmesini sağlıyor.

Buna ek olarak Hunt’ın Adaptive Segmentation özelliği; gereksiz outbound erişimleri sınırlar, üretim ve geliştirme ortamlarını izole eder, potansiyel lateral movement yollarını kısıtlar.
Bu sayede LLM tabanlı yeni nesil C2 tekniklerine karşı proaktif dayanıklılık sağlanıyor.
Saldırganların C2 iletişimlerini /v1/chat/completions üzerinden yönlendirmesi, yapay zekâ servislerinin giderek yaygınlaştığı bir dönemde görünürlüğü azaltan çok akıllıca bir taktik.
Bu yaklaşım üç temel trendle örtüşüyor:
-
Bulut API’lerine yönelik sürekli outbound HTTPS trafiği
-
Makine tarafından üretilen trafiğe artan tolerans
-
Saldırganların rahatça kullanabildiği uzun ömürlü cloud endpoint’leri
Bu nedenle eğer trafik “yeterince normal” görünüyorsa, savunma sistemlerini aşma ihtimali yükseliyor.
Saldırganların kötü amaçlı payload’ları meşru LLM çağrılarının içine gizlemesi, giderek artan AI entegrasyonlarıyla birlikte kurum ağlarında büyük bir “gürültü” oluşturuyor. İşte saldırganlar da tam olarak bu gürültünün içinde kaybolmayı hedefliyor.
IOCs

