CARBONATO: Docker sunucusunu parse edicilerle nasıl koruyabilirsiniz

22 Eylül 2026 tarihinde ThreatDown araştırmacıları CARBONATO botnetini tanımladı. Şifre olmadan açık Docker API üzerinden sunuculara giriyor, ev sahibi üzerinde bir AI ajanı başlatıyor ve ilk olarak dil modellerinin anahtarlarını arıyor. SSH anahtarları ve erişim token'ları daha sonra geliyor. Eğer VPS'inizde konteynerlerde ayrıştırıcılar çalışıyorsa ve .env dosyasında OpenRouter veya OpenAI anahtarları ve proxy girişleri varsa, bu sizin risk profilinizdir. Aşağıda saldırının nasıl yapılandığına dair bir analiz ve bu girişi kapatan 15 dakikalık bir kontrol listesi bulunmaktadır.

Ne bulduk: 4,3 GB görüntü ve GH0ST adında bir ajan

Her şey, operatörlerin kendilerine ait kapatılmamış bir Docker kaydından başladı. ThreatDown'a göre, burada 59 depo, 234 görüntü etiketi ve 4,3 GB veri vardı. Arşiv, Ekim 2024 ile Ağustos 2026 arasında bir dönemi kapsıyor, yani botnet tanımlanmadan önce neredeyse iki yıl boyunca çalışmış. Depolarda XMRig madencisi ve fsociety/agent gibi isimlere sahip görüntüler bulundu.

Raporun enfeksiyon zinciri şu şekilde görünmektedir:

Tarayıcı, Docker API'nin TCP 2375 kimlik doğrulaması olmadan açık olduğu ev sahiplerini arar.
Bu API üzerinden solucan, ev sahibinin dosya sistemine bağlı ayrıcalıklı bir konteyner başlatır. Bu andan itibaren makinede aslında root'tur.
Operatörlerin altyapısına geri bir SSH tüneli kurulur, anahtarları ile bir SSH sunucusu kurulur.
Kurulum, cron, systemd zamanlayıcıları, rc.local ve OpenRC üzerinden yapılır ve dosyalar değiştirilemez olarak işaretlenir. Gözetim süreçleri, bir şey silinirse görüntüleri yeniden indirir.
Konteyner, systemd-resolved olarak gizlenir ve süreç, çekirdek akışı [kworker/u2:0] altında görünür.
Her beş dakikada bir, betikler komşu /24 alt ağlarını ve Docker köprülerini bir sonraki açık 2375 portunu aramak için tarar.

Yayılma tamamen otomatik ve AI'ya bağımlı değil. AI, zaten ele geçirilmiş sunucu içinde olanlarla ilgileniyor.

Botnetin AI ajana neden ihtiyacı var ve neden LLM anahtarlarına ihtiyaç duyuyor

Ev sahibine, GH0ST kimliği ile açık bir Hermes Agent çerçevesi kurulur (talimatları SOUL.md dosyasında bulunmaktadır). Operatör, Telegram'da bir görev yazar, ajan bunu LLM operasyon geçidine talimatlarla birlikte iletir. Model, görevi analiz eder, terminal için komutlar yazar, çıktıyı okur ve ne yapacağına karar verir. Sonuçlar Telegram'a geri gönderilir.

Ajanın talimatlarında öncelikler açıkça belirtilmiştir. ThreatDown alıntı yapıyor: “AI API anahtarları mutlak önceliktir. Önce dışarı aktarın”. Listede OpenAI, Anthropic, Google, Groq, Mistral ve OpenRouter dahil olmak üzere 14 model sağlayıcısı bulunmaktadır. SSH hesapları, erişim token'ları ve veri tabanları sonraki maddeler olarak gelir.

Mantık basit: çalınan bir LLM anahtarı hemen ücretsiz hesaplamalara veya yeniden satılacak bir ürüne dönüşüyor ve bunun bedelini anahtarın sahibi ödüyor. Madencilikten farklı olarak, bu tür bir hırsızlık işlemci yükü üzerinden görünmez. Sadece model sağlayıcısından gelen fatura ile fark edersiniz.

Neden bu durum, ayrıştırıcıları olanları ilgilendiriyor

2026 yılında tipik bir ayrıştırma yığını şöyle görünmektedir: VPS, birkaç konteyner (tarayıcı, kuyruk, veri tabanı, headless tarayıcı), sayfaları analiz etmek için LLM ve bir proxy havuzu. Tüm sırlar bir .env dosyasında veya konteynerlerin çevre değişkenlerinde yer almaktadır. Root erişimine sahip olan ve "her şeyi okuyan" bir ajan için bu, tek bir dosyada hazır bir avdır:

LLM anahtarları: CARBONATO'nun yaratılma sebebi budur;
proxy kullanıcı adları ve şifreleri: rapor bunları ayrı olarak belirtmiyor, ancak root erişimine sahip ajan, gördüğü herhangi bir hesabı ve token'ı toplar ve proxy kredileri genellikle yan yana bulunur;
bulut anahtarları ve ayrıştırma sonuçlarına erişim;
sunucu: aynı arşivdeki XMRig, tarayıcınızın CPU'sunun madenciliğe gideceği anlamına gelir ve görevler zaman aşımına uğramaya başlayacaktır.

İtibar ile ilgili ayrı bir sorun vardır. Solucanın başkalarının alt ağlarını taradığı sunucu hızla kötüye kullanım listelerine düşer ve barındırıcı, şikayet üzerine onu engelleyebilir. Ayrıştırma için bu, iki kat darbe demektir: sunucunun IP'si işaretlenir ve çalınan proxy kredileri, sizin trafiğinizi başkalarının istekleri ile tüketir.

Port 2375 nasıl açık kalıyor, oysa siz onu açmadınız

Varsayılan olarak Docker, yerel UNIX soketini dinler, ağı değil. Port 2375, birisi kasıtlı olarak -H tcp://0.0.0.0:2375 komutunu demonun yapılandırmasına eklediğinde ortaya çıkar. Genellikle, uzaktan bir IDE, CI veya konteyner yönetim paneli bağlamak için yapılır ve sonra unutulur. Docker belgeleri, demonun erişiminin makinedeki root erişimine eşit olduğunu açıkça uyarır ve anahtarları root parolası gibi korumayı önerir. TLS ile şifrelenmiş versiyonu 2376 portunda çalışır, 2375 ise istemci doğrulaması olmadan açık metin anlamına gelir.

İkinci tuzak, "benim ufw'im var" diyenleri vurur. Docker belgelerinde, yayınlanan konteyner portlarının trafiğinin nat tablosunda INPUT ve OUTPUT zincirlerinden önce yönlendirildiği belirtilmiştir; bu zincirler ufw'ye dayanır. Pratikte, ufw için bu tür portlardaki kurallar çalışmaz. Eğer Redis, kuyruk paneli veya -p 6379:6379 ile bir proxy yöneticisi başlattıysanız, port internet üzerinde açık kalır, ne olursa olsun ufw status ne gösterirse göstersin.

Ayrıştırıcılar için 15 dakikalık kontrol listesi

1. Docker API'nin ağı dinlemediğinden emin olun

Açık portları kontrol edin: ss -tlnp | grep -E '2375|2376|dockerd'. Çıktıda 0.0.0.0:2375 veya :::2375 varsa, hemen kapatın.
Bayrağın nereden geldiğini kontrol edin: /etc/docker/daemon.json (anahtar "hosts") ve birim systemctl cat docker (satır ExecStart ile -H tcp://).
TCP dinleyicisini kaldırın ve demonun yeniden başlatın. Uzaktan yönetim için SSH bağlamını kullanın: docker context create remote --docker host=ssh://user@server. Bu durumda dışarıya port açmanıza gerek yoktur.
TCP gerekli ise (CI, orkestratör), yalnızca 2376 ile karşılıklı TLS kimlik doğrulaması ve kaynak IP için beyaz liste kullanın.

2. Konteynerlerden dışarıda neyin açık olduğunu kontrol edin

docker ps --format '{{.Names}} {{.Ports}}' komutunu çalıştırın. 0.0.0.0: ile başlayan her şey, ufw'yi atlayarak internetten erişilebilir.
Hizmetler (Redis, Postgres, Mongo, kuyruk panelleri, Selenium Grid, proxy yöneticisi API'si) yalnızca yerel adrese yayınlanmalıdır: -p 127.0.0.1:6379:6379. Dış erişimi SSH tüneli üzerinden yapın.
Dış port olmadan geçemiyorsanız, DOCKER-USER zincirinde filtreleyin: Docker bunu yeniden yazmaz ve bu, konteynerlerin trafiğine uygulanır.
Sunucuda kimlik doğrulaması olmayan açık bir proxy bulundurmayın (3128'de Squid, "kendi" için 1080'de SOCKS). Tarayıcılar bu tür portları düzenli olarak bulur ve sizin IP'niz üzerinden başkalarının trafiği geçer.

3. Gizli anahtarlarla ilgilenin

Anahtarları ayırın: her sunucu veya proje için ayrı bir LLM anahtarı, model sağlayıcısında harcama limiti. $20 limiti olan çalınan bir anahtar - bir sorun, limiti olmayan - bütçede bir delik.
Proxy anahtarlarını da görevler için ayırın: her ayrıştırıcı için ayrı bir kullanıcı adı (alt hesap). Böylece sızıntıyı belirli bir kullanıcı adı üzerinden görebilirsiniz ve sadece onu iptal edebilirsiniz, diğer çalışmaları durdurmadan.
Bir hizmetin yalnızca iki anahtara ihtiyacı varsa, tüm .env dosyasını env_file üzerinden konteynere geçirmeyin.
Mümkünse, erişimi sunucunun IP'sine bağlayın: proxy sağlayıcısında beyaz liste veya API anahtarını adresle sınırlayın.

Proxy kullanıcı adlarını betiklerde ve konteynerlerde nerede ve nasıl saklayacağınız hakkında daha fazla bilgi için proxy kimlik bilgilerini güvenli bir şekilde saklama analizimize göz atabilirsiniz.

4. Gereksiz ayrıcalıkları kaldırın

--privileged ile konteynerleri başlatmayın ve / veya /var/run/docker.sock dosyasını içeriye monte etmeyin, acil bir ihtiyaç olmadıkça. Konteyner içindeki soket, ev sahibi üzerinde aynı root'tur.
Headless tarayıcılar için genellikle --shm-size ve seccomp profili yeterlidir. "Chrome'un çalışması için" ayrıcalıklı mod kötü bir uzlaşmadır.

Sizi zaten enfekte olup olmadığınızı nasıl anlayabilirsiniz

ThreatDown ve raporunun analizleri, aşağıdaki uzlaşma belirtilerini sunmaktadır:

SOUL.md dosyası içinde GH0ST kelimesi (örneğin, /root/.hermes/SOUL.md);
Bir çevre değişkeni veya .env dosyasındaki bir satır: CARBONATO_API_KEY;
/usr/local/bin/.docker-network-monitor ve şüpheli /usr/sbin/systemd-logind dosyaları;
systemd-resolved adında bir konteyner (gerçek systemd-resolved, ev sahibi hizmetidir, konteyner değil);
Telegram API'sine beklenmedik çıkış trafiği ve AS262145 yönünde ters SSH tüneller;
45.79.183.61, 213.136.79.115, 190.211.124.187 adresleri ile bağlantılar;
cron ve systemd'deki değiştirilemez dosyalar: lsattr /etc/cron.d/* /etc/systemd/system/* komutu i bayrağını gösterecektir.

Eğer en az bir belirti eşleşiyorsa, sunucuyu manuel olarak temizlemek anlamsızdır: kurulum çok katmanlıdır ve gözetim implantları geri dönecektir. Doğru sıra şöyledir:

Başka bir makineden, sunucuda bulunan tüm anahtarları geri çağırın: LLM, bulut, veri tabanları, proxy.
Son haftalarda her anahtarın harcamasını sağlayıcılardan kontrol edin. Proxy kullanıcı adı üzerinden istatistik, hemen başkalarının trafiğini gösterecektir.
Temiz bir görüntüden yeni bir sunucu oluşturun, yeni anahtarlar çıkarın ve yalnızca verileri taşıyın, eski makineden ikili dosyalar ve cron dosyaları olmadan.

Burada proxy nerede ve neyi çözmüyorlar

Proxy'ler sunucuyu CARBONATO'dan korumaz. Solucan, sizin çıkış istekleriniz üzerinden değil, giriş portu üzerinden gelir. Ancak doğru proxy kullanımı hasarı azaltır. Görevler için ayrı kullanıcı adları, trafik limitleri ve IP ile bağlama, sızıntıyı "tüm bakiye gitti" durumundan "bir kullanıcı adını iptal ettim" durumuna dönüştürür.

Ayrıca, botnetlerin düzenli olarak gösterdiği ters bir taraf vardır: başkalarının ele geçirilmiş cihazları, şüpheli ağların "ikamet eden proxy'leri" haline gelir. Bu nedenle, ayrıştırma için, havuzun kökenini net bir şekilde anlayabileceğiniz bir sağlayıcıdan trafik almak önemlidir. Çoğu veri toplama görevi için gigabayt başına ödeme yapan ikamet eden proxy'ler uygundur; burada her proxy'nin harcaması panelde görünür. Hizmet görevleri için, sert anti-bot koruması olmayan daha ucuz veri merkezi proxy'leri yeterlidir.

Sonuç

CARBONATO, ne sıfır gün açıklarını ne de karmaşık istismarları kullanıyor. Sunucuların sahiplerinin kendilerinin açtığı kapıdan giriyor: TCP 2375 şifresiz. Onu farklı kılan şey, içinde bir AI ajanın çalışmasıdır; bu ajana ilk iş olarak model anahtarlarını almak verilmiştir. VPS'lerinde veri toplayanlar için pratik bir sonuç var. Docker API'sini kapatın, hizmet portlarını 127.0.0.1 üzerinde yayınlayın, LLM ve proxy anahtarlarını görevlerle harcama limitleri ile ayırın. Bu, 15 dakikalık bir iş ve sonrasında sunucunuz bu tür botnetler için ilginç bir hedef olmaktan çıkacaktır.