May 11, 2026

IMDS İstismarı Nedir?

Siber Güvenlik Araştırması IMDS İstismarı Nedir | Bulut Metadata Servisi Tehditleri ve Savunma Taktikleri

Nesil Teknoloji A.Ş.

7 min read

Instance Metadata Service, modern bulut mimarilerinde arka planda çalışan kritik servislerden biridir. Sanal makinelere kimlik bilgisi ve yapılandırma verisi sağlar. Normal şartlarda bu yapı operasyonu kolaylaştırır. Ancak yanlış yapılandırma ya da uygulama katmanındaki bir zafiyetle birleştiğinde, saldırganın bulut altyapısında yetki kazanmasına neden olabilir. Burada en sık yapılan hata, IMDS'yi yalnızca teknik bir yardımcı servis gibi görmek ve güvenlik mimarisine dahil etmemektir.

2025 yılında Wiz araştırmacıları tarafından keşfedilen Pandoc CVE-2025–51591 zafiyeti, küçük görünen bir yardımcı aracın bile ciddi bir bulut güvenliği problemine dönüşebileceğini gösterdi. Saldırganlar, IMDS'ye yapılan SSRF çağrılarıyla geçici IAM anahtarlarını ele geçirebilir ve AWS, Azure ya da GCP ortamlarında yanal hareket edebilir. Bu tür senaryolarda çoğu zaman şu tablo ortaya çıkar: uygulamadaki basit bir URL çağırma özelliği, bulut hesabındaki hassas yetkilere açılan kapıya dönüşür.

  1. Instance Metadata Service Nedir ve Neden Kritiktir

Instance Metadata Service (IMDS), AWS, Azure ve Google Cloud Platform gibi büyük bulut sağlayıcılarında her sanal makine örneğinde çalışan özel bir servistir. Bu servis; VM'e ait yapılandırma bilgilerini, ağ ayarlarını, SSH anahtarlarını ve en önemlisi o VM'e atanmış geçici erişim kimlik bilgilerini sunar. Bu bilgiler IAM rolü veya yönetilen kimlik token'ları olabilir. IMDS'ye yalnızca VM'nin iç ağından, bağlantı-local adres olan 169.254.169.254 üzerinden erişilebilir.

Bu tasarımın amacı, uygulamaların kimlik bilgilerini kod içinde veya yapılandırma dosyalarında saklamadan bulut kaynaklarına erişebilmesini sağlamaktır. Örneğin AWS EC2 üzerinde çalışan bir web uygulamasının S3 bucket'ına yazma izni varsa, uygulama IMDS'ye giderek ilgili IAM rolünün geçici anahtarlarını alır. Böylece uzun ömürlü ve sızma riski yüksek statik anahtarlar kullanılmaz. Bu mimari doğru kurulduğunda güvenliği artırır; yanlış kurgulandığında ise ciddi bir saldırı yüzeyi doğurur.

Risk tam olarak burada başlar. Saldırgan, VM üzerinde çalışan bir uygulamayı bu özel adrese istek yapmaya zorlayabilirse, VM'in sahip olduğu bulut izinlerini ele geçirebilir. Aşırı ayrıcalıklı rollerin atandığı makinelerde bu durum tüm bulut hesabının veya aboneliğin ele geçirilmesine kadar gidebilir. Wiz tarafından yapılan bir araştırma, IMDS istismarının bir VM'den başlayarak 40 dakikadan kısa sürede tüm alan adı hakimiyetine yol açabileceğini göstermiştir. Bu nedenle bulut ortamlarında sızma testi hizmetleri yalnızca uygulama katmanını değil, metadata servislerine erişim yollarını da kapsamalıdır.

IMDS'nin kritik yapısı, ona yönelik saldırıların da sürekli gelişmesine neden olur. İlk nesil IMDSv1 yalnızca GET isteklerini kabul ederken, IMDSv2 PUT isteğiyle session token alınmasını zorunlu kılar. Ancak Typebot zafiyetinde (CVE-2025–64709) görüldüğü gibi, IMDSv2 bile özel başlık enjeksiyonu gibi gelişmiş tekniklerle aşılabilir. Burada en sık yapılan hata, IMDSv2'ye geçince riskin tamamen ortadan kalktığını varsaymaktır.

2. IMDS İstismar Teknikleri ve Gerçek Dünya Vakaları

IMDS'ye dış ağdan doğrudan erişmek mümkün değildir. Saldırganlar bu servise ulaşmak için dolaylı yollar arar. En sık görülen iki istismar vektörü, sunucu taraflı istek sahteciliği ve kod enjeksiyonudur. Pratikte bu durum genelde şöyle karşımıza çıkar: saldırgan metadata servisine erişmez; uygulamanın kendi yetkili isteğini aracı olarak kullanır.

2.1 Sunucu Taraflı İstek Sahteciliği (SSRF)

SSRF, bir web uygulamasının kullanıcı tarafından verilen URL'yi yeterince doğrulamadan çağırmasıyla ortaya çıkar. Saldırgan, uygulamaya 169.254.169.254 adresini çağırtarak IMDS'den hassas verileri toplar. Pandoc CVE-2025–51591 örneğinde olduğu gibi, küçük yardımcı programlar bile bu zincirin parçası haline gelebilir. Pandoc'taki zafiyet, özel hazırlanmış bir HTML iframe etiketiyle SSRF isteğini tetiklemiş ve saldırganların EC2 IAM kimlik bilgilerini dışarı sızdırmasına yol açmıştır.

ClickHouse veritabanındaki SELECT * FROM url özelliği de benzer şekilde IMDS'ye erişmek için kullanılmıştır. Bu tür zafiyetlerde uygulama, HTTP isteklerini adeta proxy gibi çalıştırır. Eğer ortamda IMDSv1 kullanılıyorsa, token sızdırma işlemi çok daha doğrudan gerçekleşir. Bu nokta çoğu zaman gözden kaçıyor; sorun yalnızca web uygulamasında değil, o uygulamanın bulut içinde hangi yetkilerle çalıştığında da gizlidir.

2.2 Kod Enjeksiyonu ve Yanlış Yapılandırma

SQL enjeksiyonu, komut enjeksiyonu veya gereğinden fazla ağ iznine sahip yanlış yapılandırılmış iş yükleri, saldırganın VM üzerinde rastgele kod çalıştırmasına imkan verir. Bu durumda saldırgan, shell bağlantısı üzerinden IMDS'ye curl veya Invoke-RestMethod benzeri komutlarla erişebilir. Azure ortamında yapılan bir araştırma, VM'de kod çalıştırmayı başaran saldırganın aşağıdaki PowerShell komutuyla yönetilen kimlik token'ını ele geçirebileceğini göstermektedir:

Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/" | Select-Object -ExpandProperty access_token

Bu token ile saldırgan Azure Resource Manager API'lerini kullanabilir. Key Vault sırlarını okuyabilir, diğer VM'lerde komut çalıştırabilir veya yeni kaynaklar oluşturabilir. Guardz tarafından belgelenen bir saldırı zincirinde, ele geçirilen token ile RBAC üzerinden Global Administrator yetkisine ulaşılmış ve tüm Microsoft 365 kiracısı ele geçirilmiştir. Bu nedenle penetrasyon testi senaryolarında yalnızca açık doğrulaması değil, token sonrası etki analizi de yapılmalıdır.

2.3 GCP Metadata Sunucusu İstismarı

GCP tarafında da benzer bir risk vardır. Saldırganlar, Dataproc kümesine kötü amaçlı bir iş göndererek metadata sunucusundan hizmet hesabına ait token'ı sızdırabilir. Aşağıdaki Python kodu bu işlemin temel mantığını özetler:

import requests
metadata_url = "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"
headers = {"Metadata-Flavor": "Google"}
response = requests.get(metadata_url, headers=headers, timeout=5)
token = response.json().get("access_token", "")
print(f"Leaked Token: {token}")

Bu token ile saldırgan GCP ortamında yanal hareket edebilir, Cloud Storage bucket'larına erişebilir veya Compute Engine API'leri üzerinden yeni kaynaklar oluşturabilir. Tenable tarafından yapılan bir analiz, GCP'nin varsayılan hizmet hesaplarının sıkça aşırı ayrıcalıklı olduğunu ve bunun "toksik kombinasyon" olarak adlandırılan güvenlik riskine yol açtığını ortaya koymuştur. Burada en sık yapılan hata, varsayılan servis hesaplarını üretim ortamında aynen bırakmaktır.

2.4 Gerçek Dünya Saldırılarından Öğrenilen Dersler

Saldırı ÖrneğiKullanılan ZafiyetEtkiÇözüm/ÖnlemPandoc CVE-2025–51591SSRF (iframe enjeksiyonu)EC2 IAM kimlik bilgilerinin sızdırılmasıIMDSv2 zorunlu kılınması, Pandoc güncellenmesiTypebot CVE-2025–64709SSRF + IMDSv2 başlık enjeksiyonuEKS düğüm rolünün tamamen ele geçirilmesiWebhook giriş doğrulaması, en az ayrıcalık ilkesiAzure Managed IdentityKod enjeksiyonu + IMDS token talebiRBAC yükseltmesi ile Global Admin yetkisiEn az ayrıcalık, PIM, IMDS izlemeGCP DataprocKötü amaçlı iş yükü + metadata erişimiHizmet hesabı token sızıntısıÖzel hizmet hesapları, metadata erişim kısıtlaması

3. IMDSv1 vs IMDSv2 Teknik Karşılaştırması ve Geçiş Stratejileri

AWS, IMDS kaynaklı riskleri azaltmak için Kasım 2019'da IMDSv2'yi duyurdu. IMDSv1 ile IMDSv2 arasındaki temel fark kimlik doğrulama mekanizmasıdır. IMDSv1'de herhangi bir kimlik doğrulama şartı yoktur; yalnızca GET isteği yeterlidir. Bu yapı SSRF zafiyetlerinin doğrudan istismar edilmesini kolaylaştırır. IMDSv2 ise iki aşamalı bir model sunar. Önce PUT isteğiyle geçici session token alınır, ardından bu token X-aws-ec2-metadata-token başlığında taşınarak GET istekleri yapılır.

Bu yaklaşım SSRF saldırılarına karşı önemli direnç sağlar. Çünkü çoğu SSRF zafiyeti yalnızca GET isteklerini destekler. Ancak Typebot örneğinde görüldüğü gibi, saldırganlar özel başlık enjeksiyonu ile IMDSv2 korumasını aşabilir. Bu nedenle IMDSv2 değerli bir güvenlik kontrolüdür ama tek başına yeterli değildir. Bu tür senaryolarda çoğu zaman şu tablo ortaya çıkar:ortam IMDSv2'ye geçmiştir, fakat uygulama hâlâ kontrolsüz dış istek yapabildiği için risk devam eder.

AWS, IMDSv2'nin zorunlu kılınmasını önerir. Ancak Datadog'un 2024 raporuna göre EC2 örneklerinin yalnızca %32'sinde IMDSv2 zorunlu tutulmuştur. Azure ve GCP de kendi metadata hizmetlerinin güncel güvenlik seçeneklerini sunar. Azure'da Managed Identity kullanılırken IMDS'nin doğru yapılandırılması ve aşırı ayrıcalıklı rollerden kaçınılması kritik önem taşır. Bu kapsam, kurumsal siber güvenlik hizmetleri içinde düzenli bulut konfigürasyon denetimiyle takip edilmelidir.

IMDSv2'ye geçiş için adımlar:

  • Mevcut IMDSv1 kullanan örnekleri tespit etmek için CSPM araçları veya AWS Config kuralları kullanılmalıdır.
  • Test ortamlarında IMDSv2 zorunlu kılınarak uygulama uyumluluğu doğrulanmalıdır.
  • AWS CLI veya CloudFormation ile metadata-options parametresinde http-token: required ayarı yapılmalıdır.
  • Azure'da az vm update --set osProfile.secrets[].sourceVault.id benzeri komutlarla IMDS erişim politikaları güncellenmelidir.
  • GCP'de gcloud compute instances add-metadata ile metadata sunucusuna erişimi kısıtlayan özel etiketler eklenmelidir.

4. Tespit, Tehdit Avcılığı ve Savunma Derinliği

IMDS istismarlarını tespit etmek, proaktif güvenlik yaklaşımının kritik parçalarından biridir. Wiz araştırma ekibi, normalde IMDS'ye erişmeyen süreçlerin aniden bu erişimi yapmasını izleyerek sıfırıncı gün zafiyetlerini keşfetmiştir. Bu yöntem anomali tespiti olarak bilinir ve özellikle büyük ölçekli bulut ortamlarında etkilidir. Bu noktada sık karşılaşılan eksik yaklaşım IMDS erişimini normal sistem trafiği gibi görüp ayrıca izlememektir.

4.1 Tespit Yöntemleri

  • Ağ Trafiği Analizi: 169.254.169.254 adresine yapılan tüm istekleri loglamak ve bu istekleri yapan süreçleri ilişkilendirmek gerekir.
  • Bulut Sağlayıcı Günlükleri: AWS CloudTrail, Azure Monitor ve GCP Audit Logs üzerinden IMDS erişimlerini izlemek mümkündür. Özellikle GetCallerIdentity veya AssumeRole gibi API çağrıları anormal kaynaklardan geliyorsa dikkatle incelenmelidir.
  • Host Tabanlı Algılama: EDR çözümleri, IMDS'ye yapılan curl, wget veya Invoke-RestMethod çağrılarını tespit edebilir.

4.2 Savunma Derinliği Stratejileri

Tek bir önlem IMDS istismarlarını tamamen engellemeye yetmez. Bu nedenle katmanlı savunma yaklaşımı kullanılmalıdır. Pratikte bu durum genelde şöyle karşımıza çıkar: IMDSv2 açıktır, ancak aşırı yetkili IAM rolü ve zayıf SSRF kontrolü nedeniyle saldırı hâlâ ciddi etki yaratır.

  • IMDSv2 Zorunluluğu: Tüm yeni ve mevcut örneklerde IMDSv1 devre dışı bırakılmalıdır. AWS bu ayarı modify-instance-metadata-options CLI komutu ile yapmayı sağlar.
  • En Az Ayrıcalık Prensibi: Bir VM'e atanan IAM rolü veya yönetilen kimlik, sadece kesinlikle ihtiyaç duyulan izinlere sahip olmalıdır. Aşırı ayrıcalıklı roller (örneğin Contributor veya Owner) bir istismar durumunda hasarın büyük olmasına neden olur.
  • SSRF Koruması: Web uygulamalarında kullanıcı tarafından sağlanan URL'ler mutlaka doğrulanmalı ve izin listesi (allowlist) kullanılmalıdır. WAF (Web Application Firewall) kuralları ile 169.254.169.254 gibi özel adreslere yapılan istekler engellenebilir.
  • CSPM ve IaC Taraması: Cloud Security Posture Management araçları, IMDSv2'nin zorunlu olmadığı örnekleri ve aşırı ayrıcalıklı rolleri sürekli olarak tarar. Infrastructure as Code (IaC) tarama araçları ise bu yanlış yapılandırmaları dağıtım öncesinde engeller.
  • Yapay Zeka Destekli Tehdit Avcılığı: Gigamon Insights gibi yeni nesil platformlar, ağ telemetrisini yapay zeka ile analiz ederek IMDS'ye yönelik anormal istekleri gerçek zamanlı olarak tespit edebilir ve otomatik müdahale önerebilir.

4.3 TSE A Sınıfı Sızma Testi Yetkisi ile Nesil Teknoloji Farkı

Nesil Teknoloji, Türkiye'de TSE A Sınıfı Sızma Testi yetkisine sahip profesyonel bir siber güvenlik kurumudur. Bu yetki, hem ulusal hem de uluslararası standartlara uygun derinlemesine penetrasyon testleri gerçekleştirebilme kapasitesini gösterir. IMDS istismarı gibi karmaşık bulut güvenliği zafiyetlerinde sadece otomatik araçlarla ilerlemek yeterli değildir. Manuel keşif, özel senaryo analizi ve iş mantığı testleri gerekir. AWS, Azure ve GCP ortamlarında aşağıdaki hizmetler sunulur:

  • Kırmızı Takım (Red Team) Operasyonları: Gerçek dünya saldırganlarının taktik, teknik ve prosedürlerini (TTP) taklit ederek IMDS istismar vektörlerini test eder.
  • SSRF Zafiyet Taraması: Web uygulamalarında ve API'lerde SSRF açıklarını tespit eder, düzeltilmesi için somut öneriler sunar.
  • Bulut Güvenlik Duruşu Değerlendirmesi: Mevcut IMDS yapılandırmalarını, IAM politikalarını ve ağ güvenlik gruplarını analiz eder.
  • Uyumluluk Denetimi: NIST SP 800–53, ISO 27001 Ek A.9 ve KVKK gereksinimlerine uygunluğu değerlendirir.

KVKK kapsamında, kişisel veri işleyen sistemlerin bulutta barındırılması durumunda IMDS üzerinden sızan token'ların dolaylı olarak kişisel verilere erişim sağlayabileceği unutulmamalıdır. Bu nedenle KVKK'nın 12. maddesinde belirtilen teknik ve idari tedbirler arasında IMDS güvenliği de değerlendirilmelidir. Gerçek saldırgan davranışına yakın senaryolarla bu riskleri ölçmek için Red Team operasyonları özellikle bulut ortamlarında güçlü bir kontrol katmanı sağlar.

Sık Sorulan Sorular

Soru 1: IMDS istismarı sadece AWS'yi mi etkiler?

Hayır. IMDS benzeri hizmetler AWS, Azure ve GCP ortamlarında bulunur. Her üç platformda da SSRF veya kod enjeksiyonu yoluyla metadata token'ları sızdırılabilir. Burada en sık yapılan hata, riski yalnızca AWS özelinde değerlendirmektir. Oysa her sağlayıcının kendi metadata güvenliği yaklaşımı ve zayıf yapılandırma ihtimali vardır.

Soru 2: IMDSv2 zorunlu kılmak yeterli midir?

Hayır. Typebot örneğinde görüldüğü gibi IMDSv2 başlık enjeksiyonu ile aşılabilir. IMDSv2 güçlü bir kontrol sağlar ama tek başına yeterli değildir. En az ayrıcalık ilkesi, SSRF koruması ve sürekli izleme ile desteklenmelidir.

Soru 3: Nesil Teknoloji'nin TSE A Sınıfı yetkisi ne anlama gelir?

Bu yetki, Nesil Teknoloji'nin Türk Standardları Enstitüsü tarafından belirlenen üst düzey penetrasyon testi standartlarını karşıladığını gösterir. Kurum, ulusal mevzuata ve ISO 27001, PCI DSS gibi uluslararası standartlara uygun sızma testleri gerçekleştirebilir. Pratikte bu yetki, özellikle kamu ve kritik altyapı projelerinde güvenilir raporlama açısından önem taşır.

Soru 4: IMDS istismarını nasıl tespit edebilirim?

Anormal süreç davranışlarını izleyerek, CloudTrail/Azure Monitor loglarını analiz ederek ve EDR çözümleriyle 169.254.169.254 adresine yapılan istekleri takip ederek tespit edebilirsiniz. Ayrıca CSPM araçları, IMDSv1 kullanan örnekleri otomatik olarak raporlar. Bu nokta çoğu zaman gözden kaçıyor; log vardır ama IMDS odaklı korelasyon yapılmadığı için saldırı geç fark edilir.

Soru 5: KVKK kapsamında IMDS istismarı hangi yükümlülükleri doğurur?

KVKK'nın 12. maddesi, veri sorumlularını uygun güvenlik düzeyini temin etmeye mecbur kılar. IMDS üzerinden sızan token'lar ile kişisel verilere erişilmesi durumunda veri ihlali bildirimi gündeme gelebilir. Bu nedenle IMDS güvenliği, bulut güvenliği kadar KVKK uyumu açısından da dikkate alınmalıdır.