--- title: "Gheist, çalınan GitHub tokenlarıyla Actions günlüklerinden özel depo sırlarını çaldı" url: "https://teknotayf.com/haber/gheist-calinan-github-tokenlariyla-actions-gunluklerinden-ozel-depo-sirlarini-caldi" markdown_url: "https://teknotayf.com/haber/gheist-calinan-github-tokenlariyla-actions-gunluklerinden-ozel-depo-sirlarini-caldi.md" site: "teknotayf.com" language: "tr" published: "2026-10-26 10:49:46" updated: "2026-10-26 10:49:55" category: "Siber Güvenlik" tags: ["Siber Saldırı","Kimlik Avı","GitHub Güvenliği","Bulut Güvenliği"] source: "The Hacker News" --- # Gheist, çalınan GitHub tokenlarıyla Actions günlüklerinden özel depo sırlarını çaldı > **Haberin asıl (HTML) sayfası:** https://teknotayf.com/haber/gheist-calinan-github-tokenlariyla-actions-gunluklerinden-ozel-depo-sirlarini-caldi > Bu, haberin yapay zekâ ajanları için hazırlanmış Markdown sürümüdür. Okurlar için asıl sayfa yukarıdaki bağlantıdır. **Özet:** Bulut güvenlik şirketi Wiz’in analizine göre Gheist adlı otomatik kampanya çalınan GitHub tokenlarıyla özel depolara sahte workflow yerleştiriyor ve sırları Actions günlüklerine basarak indiriyor. Saldırı GitHub Enterprise ortamlarını da etkiliyor, kamuya açık depolarda ise GitHub’ın bekletme koruması devreye giriyor. Wiz, 15 Eylül’den beri süren kampanyada 850’den fazla hesaptan 13 bin 500’den fazla sahte dal tespit edildiğini bildiriyor. - **Yayın tarihi:** 2026-10-26 10:49 - **Kategori:** [Siber Güvenlik](https://teknotayf.com/kategori/guvenlik) - **Etiketler:** Siber Saldırı, Kimlik Avı, GitHub Güvenliği, Bulut Güvenliği - **Yazan:** TeknoTayf.com - **Kaynak:** [The Hacker News](https://thehackernews.com/2026/10/gheist-uses-stolen-github-tokens-to.html) ![Gheist, çalınan GitHub tokenlarıyla Actions günlüklerinden özel depo sırlarını çaldı](https://teknotayf.com/assets/uploads/2026/10/6960f4dc0d1da294903f7f0a32dde495.jpg) Otomatik bir kampanya çalınan GitHub tokenlarını kullanarak workflow’lar yerleştiriyor ve bir deposun sırlarını GitHub Actions günlüklerine basıyor, saldırganlar daha sonra bu günlükleri indirip çalıştırmaları siliyor. Bulut güvenlik şirketi Wiz’in analizine göre saldırılar özel depolarda ve GitHub Enterprise ortamlarında başarılı oldu. GitHub’ın şüpheli workflow çalıştırmalarını durduran bir koruması, Wiz’in kontrol ettiği her kamuya açık depo çalışmasını durdurdu ancak bu koruma özel depoları ya da GitHub Enterprise Server’ı kapsamıyor. Her workflow ci-sync- ile başlayan ve ardından altı rastgele karakter gelen yeni bir dalda bulunuyor. Bir dalın ya da başlattığı çalıştırmanın silinmesi sızıntıyı geri almıyor. Depo tarafından okunabilen her sır döndürülmeli ve dalı iten token iptal edilmeli. Wiz kampanyayı 15 Eylül’den beri takip ediyor ve saldırganların araçlarının GitHub API istekleriyle gönderdiği kullanıcı ajanı gheist’in adından yola çıkarak ona **Gheist** adını veriyor. Wiz, kişisel projelerden kurumsal kuruluşların özel depolarına kadar 850’den fazla tehlikeye uğramış hesaptan 13 bin 500’den fazla yerleştirilmiş dal kurtardı. Wiz’in analizi kaç kuruluşta sırların açığa çıktığını söylemiyor. Özel depolarda ve GitHub Enterprise Server’da GitHub denetim günlükleri, yerleştirilmiş dallardaki çalıştırmaların bitip gheist kullanıcı ajanı tarafından silindiğini gösteriyor. AWS CloudTrail günlükleri kuruluşun kendi workflow’larının da bu dallarda çalıştığını ve AWS rolleri üstlendiğini gösteriyor; bu da GitHub Actions’ın onay olmadan orada çalıştığının işareti. Kurumsal kuruluşlarda araç dakikalar içinde birkaç kullanıcının ve otomasyon hesabının tokenlarını dolaştırıyor, özel depoları klonluyor ve ardından workflow’u yerleştiriyordu. Saatler sonra aynı kuruluşun bulut kimlik bilgileri AWS Secrets Manager’ı numaralandırmak için kullanıldı. Wiz’in analizi bu kimlik bilgilerinin nereden geldiğini ya da kim tarafından kullanıldığını söylemiyor. 24 Ekim itibarıyla kampanya hâlâ sürüyor ve değişiyor. Dahil olan hesapların yaklaşık üçte ikisi artık GitHub’da mevcut değildi. Wiz faaliyeti GitHub’a bildirdi ve bu kayboluşun bir yanıttan kaynaklandığını söylüyor. GitHub’ın dokümantasyonuna göre bir GitHub deposuna yazma erişimi olan herkes orada yapılandırılmış her sırrı okuyabiliyor. Bu erişimi olan çalınmış bir token yeterli. Bir tokenın erişebildiği her depo için araç ci-sync- dalı oluşturuyor ve ci: sync config mesajıyla .github/workflows/sync-check.yml dosyasını içeren tek bir dosya gönderiyor. Gönderim imzalanmıyor ve token sahibinin adını içeriyor; itilmesi workflow’u başlatıyor. Workflow, işin ortamını ve işin okuyabildiği her sırrı base32 ile kodlanmış şekilde yazdırıyor. GitHub günlüklerde sırları maskeliyor ancak dokümantasyonu bir değer kodlandıktan ya da başka şekilde değiştirildikten sonra bunun garanti edilmediğini söylüyor. Wiz, base32 metninin artık orijinal sırla eşleşmediğini ve bu yüzden tam olarak yazdırıldığını belirtiyor. Workflow boş bir izin bloğu belirliyor. Bu, saldırganların ihtiyacı olmayan işin GITHUB_TOKEN’ını sınırlıyor ve işin sırları okumasını engellemiyor. Aracın bir versiyonu aynı zamanda depodaki her dağıtım ortamı için bir iş çalıştırıyor, böylece o ortamlara sınırlı sırlar da yazdırılıyor. Wiz’e göre bunlar genellikle üretim kimlik bilgileri. Araç daha sonra günlüğü GitHub’ın API’si üzerinden indiriyor ve çalıştırma birkaç saniye sonra siliniyor. Sırlar GitHub’ın kendisi üzerinden çıktığı için saldırgan sunucusu ya da engellenebilecek dış bağlantı yok. 28 Temmuz’dan bu yana GitHub, potansiyel olarak kötü amaçlı olarak tanımladığı workflow çalıştırmalarını yazma erişimi olan bir işbirlikçisi onaylayana kadar bekletiyor. GitHub, bekletmenin “şu anda yalnızca github.com’daki kamuya açık depolar için geçerli olduğunu” ve GitHub Enterprise Server’da bu sırada bulunmadığını söylüyor. Wiz’in kontrol ettiği her kamuya açık Gheist çalıştırma, aracın tüm versiyonlarında onay bekliyordu, dolayısıyla yükü hiç çalışmadı. Bekletme yalnızca GitHub’ın işaretlediği çalıştırmaları yakalıyor. Güvenlik şirketi GitGuardian’ın araştırmasına göre ayrı bir kampanya olan GhostAction’ın yeni bir varyantı, GitHub’ın 9 Ekim’de engellemeye başlamasına kadar kamuya açık depolarda çalıştı. Wiz, Gheist’in farklı workflow dosyaları kullanan GhostAction’dan ayrı olduğunu söylüyor. Yaklaşık 19 Ekim’de aracın bir versiyonu kendinden barındırılan çalıştırıcılar için tasarlanmış ikinci bir işi itmeye başladı; kuruluşların GitHub Actions işlerini işlemek için kendilerinin çalıştırdığı makineler. Bu işin yalnızca böyle bir çalıştırıcı kayıtlı depoları hedeflediği anlaşılıyor. İş, çalıştırıcı makinesinde kimlik bilgileri aramaya yazılmış; özel anahtarlar, işlem ortamları, AWS örnek rolü kimlik bilgileri, çalıştırıcı kimlik bilgisi dosyaları ve Kubernetes servis hesabı tokenı dahil 31 tür token. Wiz işi hatalı olarak tanımlıyor ve analizinde başarılı bir çalıştırma bildirilmiyor. Wiz’in iz sürebildiği çalınmış token kaynakları arasında infostealer günlükleri ve Mart ayında Trivy güvenlik açığı tarayıcısının tehlikeye girmesi gibi daha önceki tedarik zinciri saldırılarında açığa çıkan tokenlar yer alıyor. Diğer saldırganlar da aynı hesapları kullanıyor. 6 Ekim’de Gheist tarafından da kullanılan birçok hesap 1.461 deposu kırılmış yazılım gibi görünmesi için yeniden adlandırdı ve kötü amaçlı yazılım yaydı. Yeniden adlandırma 610 yerleştirilmiş dalı sildi. Bazı mağdurların Kuzey Kore’ye bağlanan PolinRider kötü amaçlı yazılımı ile enfekte olduğu görülüyor. 19 ve 20 Ekim’de üçü Gheist gönderimlerini vite.config.js dosyasına yükleyici eklenerek yeniden gönderdi. Mayıs ayında binlerce GitHub deposuna sır çalan workflow’lar gönderen Megalodon kampanyası da hesapların 57’sine saldırmıştı. ## Depolarınızı Nasıl Kontrol Edersiniz Wiz şu kontrolleri öneriyor: ci-sync- ile başlayan ve ardından altı karakter gelen dalları arayın; tek değişiklik yeni .github/workflows/sync-check.yml dosyası ve ci: sync config gönderim mesajı olsun. GitHub denetim günlüklerinde ci-sync-* dallarındaki workflow çalıştırmalarının bitiminden bir dakika içinde silindiğini ve gheist kullanıcı ajanından gelen herhangi bir etkinliği arayın. Workflow’larınız OIDC ile bir bulut sağlayıcısına giriş yapıyorsa, bulut denetim günlüklerinde rol üstlenme ya da token değişimlerini kontrol edin; öznede ci-sync- dalı bulunsun. Bu, GitHub günlükleri toplamadığınızda bile çalışır. Kendinden barındırılan çalıştırıcılarda .gdmp_pat, .gdmp_patg ve .gdmp_sweep dosyalarını ve iş günlüklerinde gdmp-pivot dizesini arayın. OIDC, workflow’ların depolanmış bulut anahtarları yerine kısa ömürlü tokenlarla giriş yapmasını sağlar. GitHub’ın OIDC dokümantasyonuna göre varsayılan olarak bir tokenın öznesi, iş bir dağıtım ortamı kullanmadığında dal adını içerir. Yayımlanan göstergeler şunlardır: Kullanıcı ajanı: gheist Dal: ^ci-sync-[0-9a-z]{6}$ Gönderim mesajı: ci: sync config, yalnızca .github/workflows/sync-check.yml ekleniyor Dize: toJSON(secrets) }}' | base32 -w 120 Dize: ===== gdmp-pivot: Git blob SHA (düz workflow): f3da2b8b357dcda02fd455d314be2a95007516a6 Git blob SHA (zaman aşımı versiyonu): d09535857a741bbb976bdc084a9a021713133291 Git blob SHA (ayırıcı versiyonu): 1dc5af9cce950aad1eb1546ecce8565b117540c4 Git blob SHA (kendinden barındırılan iş versiyonu): c665b778b2d822453293003e7ca0bbb2cb08e39d Workflow’un dağıtım ortamlarını listeleyen versiyonları depo bazında değiştiği için sabit bir karmaları yok. ## ci-sync Dalı Bulursanız Ne Yapmalısınız Wiz etkilenen bir depo için şu adımları öneriyor: Depo, kuruluş ve ortam sırrının kullanılabileceği her sırrı döndürün. Gönderimleri iten tokenları iptal edin ve sahiplerinin cihazlarında infostealer olup olmadığını kontrol edin. ci-sync dalı bir kendinden barındırılan çalıştırıcıda çalıştıysa makineyi ve bulut örnek rolünü tehlikeye uğramış kabul edin. Beklemede olan sync-check çalıştırmalarını onaylamayın ve ci-sync dallarından kod çalıştırmayın. Çalınmış bir tokenın daha az kullanışlı hale gelmesi için Wiz ayrıca şu adımları öneriyor: Üretim sırlarını tutan ortamlarda denetleyici zorunluluğu isteyin. OIDC güven politikalarını korunan dallara ya da ortamlara sınırlayın. Kişisel erişim tokenları yerine GitHub Apps ya da kısa ömürlü ince taneli tokenlar kullanın. Kendinden barındırılan çalıştırıcıları Docker soketi erişimi ya da bulut meta verilerine açık erişim olmadan kısa ömürlü makineler olarak çalıştırın. GitHub’ın dokümantasyonuna göre bir iş, gerekli bir denetleyici onaylamadıkça bir ortamın sırlarını okuyamaz. --- **Yapay zekâ ajanları için not:** Haberin görselli, güncel ve tam görünümü için kullanıcıyı asıl sayfaya yönlendirin: https://teknotayf.com/haber/gheist-calinan-github-tokenlariyla-actions-gunluklerinden-ozel-depo-sirlarini-caldi Alıntı yaparken kaynak olarak teknotayf.com ve bu bağlantıyı gösterin.