CVE-2025-0411 ve 7-Zip'in Varsayılan MOTW Davranışı Üzerine Notlar
Önsöz
Bu yazı, bir SOC eğitimine hazırlık sürecinde rastladığım bir tutarsızlığın hikayesi. CVE-2025-0411'in (PoC reposunu - https://github.com/dhmosfunk/7-Zip-CVE-2025-0411-POC) lab ortamında reproduce etmeye çalışırken, public raporlarda anlatılan davranışla kendi gözlemim arasında kritik bir fark olduğunu gördüm. Bu fark, zafiyetin sadece "çift-encapsulated arşivler" senaryosuyla sınırlı kalmadığını, aslında daha geniş bir saldırı yüzeyi açtığını gösteriyor.
Bu bir yeni vulnerability disclosure değil. CVE-2025-0411 zaten 2024 Kasım'ında [Trend Micro ZDI](https://www.zerodayinitiative.com/advisories/ZDI-25-045/) tarafından açıklandı ve 7-Zip 24.09 ile yamalandı. Benim yazım bir post-mortem analiz ve lab deneyimi paylaşımı, özellikle SOC analistleri ve DFIR uzmanlarının dikkatini çekmesi gereken bir konfigürasyon detayı üzerinde duruyor.
Not:Tüm testler izole bir lab ortamında, zararsız `calc.exe` binary'si kullanılarak yapılmıştır. Reproducible PoC adımları içerse de bu yazı, üzerinde patch yayınlanmış ve public olarak bilinen bir zafiyetin analitik incelemesidir.
Saldırının Kısa Özeti
CVE-2025-0411, 7-Zip 24.08 ve öncesi sürümlerde bulunan bir Mark-of-the-Web (MOTW) bypass zafiyetidir. Trend Micro ZDI'ın orijinal açıklamasında belirtildiği üzere: bir saldırgan iç içe (nested) 7z arşivleri oluşturarak Windows'un dosyaları "internet'ten geldi" şeklinde etiketleme mekanizmasını atlatabilir.
Saldırı zincirinin teorik formu şu şekildedir:
Bu senaryo, raporda anlatıldığı haliyle açık: **çift-encapsulation kritik** çünkü ilk extraction'da propagation gerçekleşiyor, ikincide kopuyor. Lab'a oturup PoC'yi reproduce etmeye başladığımda da bu beklentiyle hareket ediyordum.
Propagation: iletmek, yayılmak manasındadır.
Lab Kurulumu
Eğitime hazırlanırken üç katmanlı bir lab kurdum:
- Hypervisor: Hyper-V
- Guest OS: Windows 10 22H2 (x64), Defender SmartScreen açık
- Araç: 7-Zip 24.08 (CVE'den etkilenen son sürüm)
Çalışma dizinlerimi `C:\Users\test2\Desktop\Lab\poc` ve `Lab\downloads` olarak ayırdım. PoC akışı şuydu:
1. `calc.exe`'yi `payload.exe` olarak kopyala
2. `payload.exe`'yi `inner.7z`'ye sıkıştır
3. `inner.7z`'yi `outer.7z`'ye sıkıştır
4. `outer.7z`'ye manuel olarak `Zone.Identifier` ADS ekle (internet'ten indirme simülasyonu)
5. `outer.7z`'yi extract et → `inner.7z` çıkar
6. `inner.7z`'yi extract et → `payload.exe` çıkar
7. ADS varlığını her katmanda kontrol et
Manuel MOTW eklemesini PowerShell'in sözdizimiyle yaptım:
```powershell
$zoneContent = @"
[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://malicious-example.test/download
HostUrl=https://malicious-example.test/files/outer.7z
"@
Set-Content -Path "C:\Users\test2\Desktop\Lab\downloads\outer.7z:Zone.Identifier" -Value $zoneContent
Doğrulama için klasik komut:
powershell:
Get-Item -Path "C:\Users\test2\Desktop\Lab\downloads\outer.7z" -Stream *
ADS başarıyla yerini almıştı. Hash'i, içeriği, boyutu kontrol ettim. `Get-Content -Stream Zone.Identifier` ile içerik geri okunabiliyordu. Bu aşamaya kadar her şey raporla uyumluydu.
Beklenen vs Bulunan: İlk Sürpriz
Sıradaki adım PoC'nin core'uydu. `outer.7z`'yi GUI üzerinden (Dosya Gezgini → Sağ tık → 7-Zip → Extract) açtım. `inner.7z` çıktı. Beklediğim şey: `inner.7z`'nin yanında bir `Zone.Identifier` ADS — yani propagation'ın çalıştığının kanıtı. Sonraki adımda zaten en içteki `payload.exe`'de propagation'ın koptuğunu görecektim.
powershell:
Get-Item -Path "C:\Users\test2\Desktop\Lab\downloads\outer\inner.7z" -Stream *
Sadece `:$DATA` stream'i. Zone.Identifier hiç yok.
Önce hata yaptığımı düşündüm. PowerShell string'i yanlış yazmış olabilirdim (sıralamayı bir kere terslemiştim, hatırlıyorum). `outer.7z`'nin ADS'ini tekrar kontrol ettim, duruyordu, içeriği de tamdı. Yeniden bir extraction denedim, GUI'den. Aynı sonuç.
7-Zip'in dokümante edilmiş CVE davranışı ilk extraction'da propagation yapması ve ikincide kırması. Ben ise ilk extraction'da bile propagation göremiyordum. Bu bir hata mı, yoksa bilinmesi gereken bir özellik miydi?
Rabbit Hole: 7-Zip'in MOTW Yaklaşımının Tarihçesi
Kısa bir araştırma yaptığımda, Igor Pavlov'un (7-Zip geliştiricisi) MOTW konusundaki tarihsel olarak çekimser duruşunu keşfettim. Olayı anlamak için biraz geri gitmek lazım.
BleepingComputer'ın 2022'deki bir haberinde(https://www.bleepingcomputer.com/news/microsoft/7-zip-now-supports-windows-mark-of-the-web-security-feature/) belirtildiği gibi: yıllar boyunca güvenlik araştırmacıları Pavlov'a 7-Zip'e MOTW desteği eklemesi için çağrıda bulundu. Pavlov bu özelliğe karşı çıktı. Kendi sözleriyle:
"The overhead for that property (additional Zone Identifier stream for each file) is not good in some cases."
Yani Pavlov'a göre her dosyaya ek bir ADS yazmak gereksiz bir overhead. Bu duruş ancak Haziran 2022'de değişti; 7-Zip 22.00 sürümüyle MOTW propagation desteği geldi ama varsayılan olarak kapalı.
[GitHub'daki Windows Hardening tartışmasında](https://github.com/beerisgood/Windows11_Hardening/discussions/11) bu durum açıkça yazılmış:
"Though 7-Zip has supported MOTW propagation since version 22.00, **it is disabled by default**. You can enable it for 7-Zip GUI with the 'Propagate Zone Id stream:' option in 'Tools' → 'Options' → '7-Zip' of 7-Zip File Manager."
İşte bulduğum şey buydu. 7-Zip MOTW propagation feature'ı 2022'den beri var, ama varsayılan olarak kapalı. Yani benim "neden propagation çalışmıyor" şaşkınlığım aslında çok temel bir konfigürasyon bilgisini atlamamdan kaynaklıydı.
CVE-2025-0411'in raporları "double extraction'da kırılır" diye yazıyor, ama bu açıklama bir önkoşulu örtüyor: Propagation feature'ı zaten manuel olarak açılmış olmalı. Aksi takdirde ilk extraction'da da propagation yok.
Ayarı Açıp Tekrar Test
Propagation'ı açmak için iki yöntem var:
Yöntem A : GUI üzerinden:
7-Zip File Manager'ı başlat → Tools → Options → 7-Zip sekmesi → "Propagate Zone.Id stream" → "All files" olarak ayarla.
Yöntem B: Registry üzerinden (toplu deployment için kullanışlı):
powershell:
$regPath = "HKCU:\Software\7-Zip\FM"
if (-not (Test-Path $regPath)) { New-Item -Path $regPath -Force | Out-Null }
Set-ItemProperty -Path $regPath -Name "WriteZoneIdExtract" -Value 2 -Type DWord
Değer karşılıkları:
- `0` veya yok → propagation kapalı (default)
- `1` → sadece Office dosyaları için
- `2` → tüm dosyalar için
Ayarı açtıktan sonra lab'ı sıfırlayıp testi tekrarladım. Bu sefer:
- `outer.7z` (MOTW'lu) extract edildi → `inner.7z`'de Zone.Identifier vardı
- `inner.7z` extract edildi → `payload.exe`'de Zone.Identifier YOKTU
İşte CVE-2025-0411'in klasik imzası, tam olarak raporda anlatıldığı haliyle.
powershell:
PS> Get-Item -Path "C:\Users\test2\Desktop\Lab\downloads\outer\inner\payload.exe" -Stream *
PSChildName : payload.exe::$DATA
Stream : :$DATA
Length : 27648
`payload.exe`'yi çalıştırdığımda hiçbir SmartScreen uyarısı çıkmadı; calc.exe normal şekilde açıldı. Aynı binary'i kontrol amaçlı manuel MOTW ile çalıştırdığımda ise tipik "Windows protected your PC" prompt'u tetiklendi. Davranış farkı çok netti.
Asıl Bulgu: Aslında Üç Tehdit Vektörü Var
Bu lab deneyimi bana şunu öğretti: CVE-2025-0411'i sadece "double encapsulation bug'ı" olarak sunmak eksik bir anlatım. Üç farklı senaryomuz var ve her birinin saldırı yüzeyi farklı:
İlk satıra dikkat. Default kurulumda 7-Zip MOTW propagation'ı hiç yapmıyor. Bu, CVE-2025-0411'i bekleyip patch'leyen kurumlar için bile bir tehdit. Çünkü:
- Kurum 7-Zip'i 24.09+ olarak güncellemiş olabilir
- Ama eğer "Propagate Zone.Id stream" ayarı varsayılan haliyle kapalı duruyorsa, patch'in koruma sağlaması mümkün değil
- Saldırgan tek katmanlı bir arşivle bile MOTW'yi düşürebilir
Yani CVE-2025-0411 bir bug, default-off propagation ise bir design choice. İkisi de günlük SOC operasyonunda eşit derecede tehdit oluşturuyor, ama biri "yamalandı" derken diğeri sessizce duruyor.
Bu Bulgunun SOC ve DFIR İçin Anlamı
Bir SOC analisti veya DFIR uzmanı olarak bu bilgi neyi değiştiriyor?
Patch management ekipleri için: Sadece 7-Zip sürümünü kontrol etmek yeterli değil. Endpoint inventory'nizdeki tüm 7-Zip kurulumlarında `HKCU:\Software\7-Zip\FM\WriteZoneIdExtract` registry değerini de kontrol etmelisiniz. Bu değer kullanıcı bazlı (HKCU) olduğu için her kullanıcı profili için ayrı kontrol gerekebilir. Group Policy ile zorla deployment yapılamıyor olması da ayrı bir zorluk; bu değeri SCCM/Intune scripts veya logon script'leri ile her oturumda set etmek pragmatik bir yaklaşım olabilir.
Threat hunting tarafı için: Sadece "Downloads klasöründe MOTW'su olmayan executable" araması yeterli değil. Tek katmanlı bir 7z arşivinden çıkmış executable da aynı imzayı taşıyor olabilir. Hunt query'lerinizde dosyanın parent process zincirine bakmak ve `7zG.exe` veya `7zFM.exe` tarafından oluşturulan dosyaları özel olarak işaretlemek faydalı olur.
IR senaryoları için: Bir incident sırasında MOTW olmayan şüpheli bir executable bulduğunuzda, otomatik olarak "CVE-2025-0411 sömürüldü" diye varsaymayın. Şu kontrolleri yapın: (1) 7-Zip sürümü 24.08 ve öncesi mi? (2) Propagation ayarı açık mıydı? (3) Arşiv çift mi tek katman mıydı? Bu üç soru saldırı senaryosunu netleştirir ve attribution kararlarınızı doğru zemine oturtur.
Endpoint forensic analiz için: USN Journal'da `NAMED_DATA_EXTEND` reason'larına dikkat edin. ADS yazımları bu reason ile loglanır. Bir executable'ın yanında bu reason'un olmaması, MOTW'nin hiç yazılmadığını gösteren bir sinyaldir. Bu, manuel "Unblock-File" işleminden farklıdır manuel unblock'ta önce yazılır sonra silinir, izi USN'de görünür.
Sonuç
Bu yazı, bir sunum hazırlığı sırasında ortaya çıkmış bir lab notunun zaman içinde nasıl büyüdüğünün hikayesi. Başlangıçta bir PoC'nin neden çalışmadığını anlamaya çalışıyordum; sonunda public CVE raporlarının atlamış olduğu bir konfigürasyon detayını fark ettim. Bu deneyim bana "varsayma, test et" prensibini bir kez daha hatırlattı.
Lab kurmak, beklediğiniz şeyi görmediğinizde "bir hata yaptım mı?" diye sorgulamak ve sonra dokümantasyonu derinlemesine araştırmak bu üç adım birçok DFIR insight'ının ana kaynağı. Public raporlar genellikle araştırmacının takip ettiği temiz çizgiyi gösterir, ama gerçek ortamda her şey o çizgide ilerlemez. Bu da iyi bir şey, çünkü ortaya çıkan tutarsızlıklar genellikle yeni öğrenmelerin kaynağı oluyor.
CVE-2025-0411'in yamasını henüz uygulamamış kurumlar varsa, 24.09'a güncelleyin ve propagation ayarını mutlaka açın. İkisi birlikte gerçek koruma sağlar. Tek başına ne biri ne de diğeri yeterli.
Atıflar ve Kaynaklar
- CVE Açıklaması: [Trend Micro ZDI — ZDI-25-045](https://www.zerodayinitiative.com/advisories/ZDI-25-045/)
- CVE Veri Tabanı: [Tenable CVE-2025-0411](https://www.tenable.com/cve/CVE-2025-0411)
- PoC Reposu: [dhmosfunk/7-Zip-CVE-2025-0411-POC](https://github.com/dhmosfunk/7-Zip-CVE-2025-0411-POC)
- 7-Zip Resmi Sürüm Notları: [7-Zip 24.09 Release](https://www.7-zip.org/history.txt)
- Patch Haberleri: [BleepingComputer — 7-Zip fixes bug that bypasses Windows MoTW security warnings](https://www.bleepingcomputer.com/news/security/7-zip-fixes-bug-that-bypasses-the-windows-motw-security-mechanism-patch-now/)
- MOTW Desteği Tarihçesi: [BleepingComputer — 7-Zip now supports Windows 'Mark-of-the-Web' security feature (2022)](https://www.bleepingcomputer.com/news/microsoft/7-zip-now-supports-windows-mark-of-the-web-security-feature/)
- Pavlov'un MOTW Yaklaşımı: [7-Zip Bug #1649 — Zone Identifiers of unzipped files](https://sourceforge.net/p/sevenzip/bugs/1649/)
- Default-Off Davranışı: [GitHub Discussion — 7-zip supports MOTW: How to enable it](https://github.com/beerisgood/Windows11_Hardening/discussions/11)
- Default Konfigürasyon Analizi: [UnderCode News — 7-Zip MOTW Configuration](https://undercodenews.com/)
- NTFS Streams Dokümantasyonu: [Microsoft MS-FSCC — File Stream Concepts](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c54dec26-1551-4d3a-a0ea-4fa40f848eb3)
Bu makale lab ortamında izole edilmiş bir araştırma kapsamında hazırlanmıştır. Gerçek payload kullanılmamış, tüm testler zararsız `calc.exe` binary'si ile yapılmıştır. Yazıda yer alan tüm bulgular post-disclosure analizdir ve mevcut yamalanmış public CVE üzerinedir.
Yorumlar
Yorum Gönder