PSRansom Hazırlık Testi: Sıkılaştırılmış Windows 11 Endpoint'te MDE'yi Aşmak

Yönetici Özeti

Bu yazı, Netlore Security Red Team tarafından orta büyüklükte bir finansal hizmetler müşterisi için gerçekleştirilen ransomware hazırlık değerlendirmesini belgelemektedir. Testin amacı netti: Tamamen yamalı, kurumsal düzeyde sıkılaştırılmış bir ortamda PowerShell tabanlı bir ransomware aracının çalışan verisini başarıyla şifreleyip şifreleyemeyeceğini belirlemek ve varsa her kontrol açığını ortaya koymak.

Test öncesi müşteri endpoint durumu:

Bileşen	Sürüm / Yapılandırma
İşletim Sistemi	Windows 11 22H2 (Eylül 2025 itibarıyla tam yamalı)
EDR	Microsoft Defender for Endpoint (E5 lisansı)
Bulut	Microsoft 365 (Entra ID üyesi, Intune yönetimli)
PowerShell	Hem 5.1 hem 7.4 yüklü
Script Block Logging	GPO ile etkin
AMSI	Aktif, bulut tabanlı koruma AÇIK
Ağ çıkışı	Palo Alto NGFW, SSL denetimi etkin

Hedef araç: PSRansom — GitHub'da açık kaynaklı, PowerShell tabanlı bir ransomware simülatörü; hazırlık tatbikatlarında yaygın olarak kullanılıyor.

Sonuç: Dört farklı bypass katmanından geçtikten sonra PSRansom, test iş istasyonundaki 847 dosyayı (4,2 GB) başarıyla şifreleyebildi. MDE tüm süreç boyunca 11 uyarı üretti, ancak yalnızca 3 tanesi şifreleme tamamlanmadan önce tetiklendi. Kalan 8 uyarı, otomatik müdahale için çok geç olan süreç sonrasında geldi.

---

Kapsam ve Operasyon Kuralları

Müşteri, standart çalışan build'ini yansıtan, domain'e bağlı tek bir Windows 11 iş istasyonu sağladı. Önceden hazırlanmış kimlik bilgisi yoktu. Test, saldırganın phishing payload'u aracılığıyla kod yürütmeyi zaten elde ettiği bir senaryoyu simüle ediyordu — başlangıç noktamız, domain kullanıcısı olarak çalışan etkileşimli bir PowerShell oturumuydu.

Kapsam dışı bırakılan faaliyetler:

• Tek iş istasyonunun ötesine yanal hareket
• Gerçek iş verisinin dışarı çıkarılması
• Yeniden başlatmadan sonra hayatta kalan herhangi bir kalıcılık mekanizması
• Her türlü üretim sistemi

Tüm faaliyetler, tam paket yakalamalı izole bir VLAN'da gerçekleştirildi.

---

Faz 1 — Endpoint Keşfi

Herhangi bir payload'a dokunmadan önce savunma yüzeyini anlamak için zaman harcadık. Standart numaralandırma:

Get-MpPreferenceGet-MpComputerStatusGet-ExecutionPolicy -ListGet-AppLockerPolicyGet-ItemProperty HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\

Bu fazdan elde edilen temel bulgular:

• Constrained Language Mode (CLM): Intune policy ile aktif. Endpoint'teki en etkili tek kontrol bu — PowerShell'in doğrudan oluşturabileceği .NET tiplerini kısıtlayarak yansıma tabanlı saldırıları ciddi ölçüde sınırlıyor.
• AMSI: Bulut aramaları etkin şekilde aktif. MpCmdRun.exe -SignatureUpdate ile imza tanımlarının günün tarihinde güncel olduğu doğrulandı.
• Script Block Logging: Etkin. PowerShell 5.1'de yürütülen her script bloğu Windows Olay Günlüğü'ne (Event ID 4104) kaydediliyor ve MDE'nin telemetri hattına iletiliyor.
• Saldırı Yüzeyini Azaltma (ASR) kuralları: Önerilen 16 kuralın 12'si Zorlama modunda. Dikkat çekici istisnalar: Office makrolarının alt süreç oluşturmasını engelleyen kural Denetleme modundaydı; LSASS kimlik bilgisi çalmayı engelleyen kural da Denetleme modundaydı.
• Tamper Protection: Etkin. Bu, Defender ayarlarının standart kayıt defteri anahtarları veya PowerShell cmdlet'leri aracılığıyla doğrudan değiştirilmesini engelliyor.

Hem CLM hem AMSI aktif olduğunda PSRansom doğrudan çalıştırılamaz. Araç, CLM'nin engellediği [System.Reflection.Assembly]::Load() ve diğer .NET çağrılarına dayanıyor. AMSI katmanı bu çağrılar çalışmadan önce oturumu sonlandırırdı.

---

Faz 2 — AMSI Sorunu

AMSI (Antimalware Scan Interface), PowerShell, VBScript, JScript, WSH gibi script motorlarının içeriği yürütmeden önce kayıtlı güvenlik sağlayıcısına (bu durumda MDE) iletmesine olanak tanıyan bir Windows API'sidir. Kritik nokta: AMSI yalnızca dosya hash'lerini değil, içeriği tarar. Bir script gizlenmiş veya bellekten yükleniyor olsa bile, AMSI yürütme anında gizleme çözülmüş içeriği görür.

PowerShell 5.1 için tarama hattı kabaca şöyle çalışır:

Kullanıcı komut girer
    ↓
PowerShell tokenize eder ve AST oluşturur
    ↓
AmsiScanBuffer() script içeriğiyle çağrılır
    ↓
[MDE bulut araması + yerel imzalar]
    ↓
Tespit edildi? → AMSI_RESULT_DETECTED → oturum sonlandırılır
Temiz? → yürütme devam eder

AMSI iki modu eş zamanlı çalıştırır: imza tabanlı (bilinen zararlı string'leri ve byte kalıplarını eşleştirme) ve davranışsal (script'in yapısına ve amacına dayalı sezgisel puanlama). PSRansom her ikisini de tetikliyor: PSRansom.ps1 dosya adı, Invoke-PSRansom gibi fonksiyon isimleri ve AES-256 encryption gibi string değişmezlerin tamamı imzalara eşleşiyor. Bunlar yeniden adlandırıldığında bile davranışsal model, dosya numaralandırma ve şifreleme döngüsü kalıbını yüksek güvenle işaretliyor.

Sadece değişken adlarını değiştirmek yeterli değil.

---

Faz 3 — AMSI Bypass

İki bypass tekniği değerlendirildi. Her ikisi de amsi.dll'nin PowerShell sürecinin adres alanına yüklendiği ve tarama fonksiyonunun yamalanabilmesi için yazılabilir bellekte bulunması gerektiği gerçeğini istismar ediyor.

Teknik A: AmsiScanBuffer Bellek Yaması

AmsiScanBuffer, birincil AMSI fonksiyonudur. Bir içerik tamponu kabul eder, tarar ve sonuç kodu döndürür. Bu fonksiyonun ilk birkaç byte'ını AMSI_RESULT_CLEAN (değer 1) döndüren bir ret talimatıyla üzerine yazabilirsek, o süreçten gelen tüm sonraki çağrılar temiz döner.

Teknik:

1. Geçerli süreçte amsi.dll taban adresini çöz
2. AmsiScanBuffer'ın ofseti için dışa aktarım tablosunu dolaş
3. VirtualProtect aracılığıyla bellek sayfası izinlerini PAGE_EXECUTE_READWRITE olarak değiştir
4. Fonksiyon giriş noktasına yama byte'larını yaz
5. Orijinal izinleri geri yükle

Operasyonel implementasyon (kritik byte'lar maskelendi):

$amsiDll = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer(
    (****),  # çözümlenen fonksiyon işaretçisi — maskelendi
    (****)
)

$patchBytes = [Byte[]] (****) # yama payload'u — maskelendi

$****  # VirtualProtect çağrısı — maskelendi
[System.Runtime.InteropServices.Marshal]::Copy($patchBytes, 0, $funcPtr, $patchBytes.Length)
$****  # izin geri yükleme — maskelendi

Bu yama sürecin ömrü boyunca geçerli kalır. Yeni bir PowerShell oturumu amsi.dll'yi temiz olarak yeniden yükler.

MDE yanıtı: Uyarı yok. Bellek yazma işleminin kendisi işaretlenmiyor. MDE yalnızca AMSI çıktısını izliyor, yamalama eylemini değil — bilinen bir görünürlük açığı.

Teknik B: amsiInitFailed Üzerinden Yansıma

Alternatif bir yaklaşım, System.Management.Automation.AmsiUtils sınıfının özel amsiInitFailed alanını yansıma yoluyla true olarak ayarlar. Bu, PowerShell'in AMSI başlatmasının başarısız olduğuna inanmasına ve sonraki tüm taramaları atlamasına neden olur.

$amsiUtils = [Ref].Assembly.GetType('System.Management.Automation.****')  # sınıf adı maskelendi
$field = $amsiUtils.GetField('****', [Reflection.BindingFlags]'NonPublic,Static')  # alan adı maskelendi
$field.SetValue($null, $true)

Bu daha temizdir ve bellek manipülasyonu gerektirmez, ancak Constrained Language Mode bunu tamamen engeller — CLM altında özel bağlama bayraklarıyla [Ref].Assembly.GetType() kısıtlı bir işlemdir.

Sonuç: Teknik A seçildi. CLM, önceden yüklü bir derlenmiş yardımcı aracılığıyla yürütüldüğünde Teknik A'nın kullandığı P/Invoke stili işaretçi işlemlerini engellemez.

---

Faz 4 — ETW Bypass

AMSI yamalamasına rağmen PowerShell Script Block Logging aktif kalmaya devam ediyordu. Oturumda yürütülen her gizleme çözülmüş script bloğu, ETW'ye (Event Tracing for Windows) yazılıyor ve MDE'ye iletiliyordu. Bu, saldırı zincirini neredeyse gerçek zamanlı olarak SOC'a ifşa ederdi.

PowerShell için ETW, ntdll.dll içindeki EtwEventWrite üzerinden akar. Yaklaşım, AMSI yamasını yansıtır:

1. Geçerli süreçte EtwEventWrite'ı çöz
2. İlk byte'ların üzerine ret 14h talimatı yaz; bu, fonksiyonun herhangi bir olay yazmadan hemen dönmesine neden olur

Operasyonel yama (maskelendi):

$etwFunc = (****) # ntdll!EtwEventWrite işaretçi çözümlemesi — maskelendi
$patch   = [Byte[]](****) # ret talimatı byte'ları — maskelendi
$****    # VirtualProtect + Copy + geri yükleme — maskelendi

Etki: Bu noktadan itibaren hiçbir PowerShell script bloğu olayı (Event ID 4104) yazılmıyor. MDE'nin PowerShell telemetrisi bu oturum için karanlığa gömülüyor.

MDE yanıtı: Yine uyarı yok. ETW yaması Defender'ın izlediği katmanın altında çalıştığından doğrudan gözlemlenemiyor.

Defender Görünürlük Notu: MDE, daha önce aktif olan bir oturumdan beklenen telemetrinin yokluğunu anomali olarak tespit edebilir, ancak bu, müşterinin uygulamadığı ince ayarlı bir özel tespit kuralı gerektirir. Bu açık, katılım raporunda Bulgu #2 olarak belgelendi.

---

Faz 5 — PowerShell Gizleme Zinciri

AMSI ve ETW'nin ikisi de etkisiz hale getirilmesine rağmen PSRansom yine de doğrudan yüklenemiyordu — düz metin kaynağı diske yazıldığında Defender'ın gerçek zamanlı dosya taramasını tetiklerdi. Bellekten yükleme, içeriğin çağrı anında AMSI'den geçmesini gerektirdi (yamayı uygulamadan önce), bu nedenle bypass ve payload'un tek bir gizlenmiş birim olarak iletilmesi gerekiyordu.

Gizleme zinciri üç katman kullandı:

Katman 1 — String Tersine Çevirme + Karakter Dizisi Değiştirme

Fonksiyon isimleri ve string değişmezleri tersine çevrilir ve çalışma zamanında yeniden oluşturulur:

$r = 'rebmaNnoitcnuF'[-1..-14] -join ''
# Yeniden oluşturur: 'FunctionNombre' — gerçek hedef maskelendi

Katman 2 — Base64 Kodlama

Yeniden birleştirilen script Base64 ile kodlanır ve çalışma zamanında çözülür:

$b = '****'  # base64 blobu — maskelendi
$d = [System.Text.Encoding]::Unicode.GetString([Convert]::FromBase64String($b))

Katman 3 — Değişken Yönlendirmesi ile IEX

Invoke-Expression veya takma adı iex'in doğrudan kullanımı, string içinde bile AMSI imzalarını tetikler. Yönlendirme bunu önler:

$exec = (Get-Item 'Variable:****').Value  # IEX referansını alır — maskelendi
& $exec $d

Yaklaşık 4KB boyutundaki son gizlenmiş yükleyici, AMSI'den temiz geçer (yama sonrası) ve PSRansom payload'unu diske dokunmadan belleğe iletir.

---

Faz 6 — Firewall / C2 Anahtar Değişimi Sorunu

Bu, testin en teknik açıdan ilginç fazıydı. PSRansom'un varsayılan tasarımı yerel olarak rastgele bir AES-256 anahtarı üretir, dosyaları şifreler ve anahtarı daha sonra geri almak üzere HTTP üzerinden cleartext olarak C2 sunucusuna iletir ("fidyeyi öde, anahtarı al" senaryosunu simüle ederek).

Sorun: Müşterinin Palo Alto firewall'u giden trafiğe tam SSL denetimi uyguluyor. Bilinmeyen bir dış IP'ye yönelik HTTP/HTTPS bağlantıları:

1. Yakalanıp şifresi çözülecekti
2. URL filtreleme motoru tarafından incelenecekti
3. Hedef onaylı bir kategoride değilse engellenecekti

Test C2 sunucumuzun IP'sinin URL kategorisi yoktu ve hemen engellendi. AES anahtarı bize hiç ulaşmadı. Anahtar olmadan simülasyon kalıcı olarak kurtarılamaz dosyalar üretirdi — yetkili bir testde kabul edilemez bir sonuç.

Çözüm: RSA-2048 asimetrik anahtar sarmalama — C2 gerekmiyor.

AES anahtarını iletmek yerine:

1. RSA-2048 genel anahtarımızı payload'a gömdük
2. PSRansom'u AES oturum anahtarını RSA genel anahtarıyla şifreleyecek şekilde değiştirdik
3. RSA ile şifrelenmiş anahtar blobunu iş istasyonunda yerel bir dosyaya yazdık (RECOVERY_KEY.bin)
4. Bu blobu çözmek için yalnızca çevrimdışı tutulan RSA özel anahtarımız kullanılabilirdi

# Anahtar sarmalama — kavramsal (implementasyon maskelendi)
$aesKey      = (****) # rastgele 256-bit anahtar
$rsaPubKey   = (****) # gömülü RSA-2048 genel anahtarı — maskelendi
$wrappedKey  = $rsaPubKey.Encrypt($aesKey, [System.Security.Cryptography.RSAEncryptionPadding]::****)
[IO.File]::WriteAllBytes('C:\Users\Public\RECOVERY_KEY.bin', $wrappedKey)

Bu, ana anahtarın hiçbir zaman ağ üzerinden cleartext geçmediği modern ransomware davranışını (örn. LockBit 3.0, BlackCat/ALPHV) doğru şekilde modelliyor. Firewall tünelleme yoluyla değil, ağ bağımlılığı tamamen ortadan kaldırılarak tamamen atlandı.

---

Faz 7 — PSRansom Özelleştirmesi ve Çalıştırılması

PSRansom kullanılmadan önce çatallandı ve aşağıdaki şekillerde değiştirildi:

Değişiklik	Amaç
Değişken yeniden adlandırma (tüm değişkenler)	İmza tabanlı tespiti geçersiz kıl
Fonksiyon takma adı verme	Fonksiyon adı eşleştirmesini önle
Ölü kod enjeksiyonu (~200 satır)	Entropi artır, statik analizi karıştır
C2 iletiminin kaldırılması	Faz 6'daki RSA anahtar sarmalama ile değiştirildi
Şifreli string sabitleri	Defender'ın statik string eşleştirmesini önle
Rastgele dosya uzantısı	Varsayılan .psransom yerine .[rastgele 5 karakter]

Çalıştırma, gizlenmiş yükleyici zincirinden (Faz 5) başlatıldı. PSRansom şu hedefleri seçti:

• C:\Users\[kurban]\Documents
• C:\Users\[kurban]\Desktop
• C:\Users\[kurban]\Downloads
• Eşlenen ağ sürücüleri (test iş istasyonunda mevcut değildi)

Çalıştırma sırasında oluşturulan MDE Uyarıları:

Uyarı	Ne Zaman Tetiklendi	Önem Derecesi
Şüpheli PowerShell script yürütmesi	IEX'ten 4 saniye sonra	Orta
Olası ransomware davranışı tespit edildi	Şifrelemeden 47 saniye sonra	Yüksek
Toplu dosya değiştirme aktivitesi	2 dakika 11 saniye	Yüksek
Script block logging açığı tespit edildi	Yürütme sonrası (manuel inceleme)	Orta
Defender müdahale girişimi (süreç belleği)	Yürütme sonrası (adli)	Yüksek
... 6 ek yürütme sonrası uyarı	Şifreleme tamamlandıktan sonra	Çeşitli

Şifreleme 3 dakika 42 saniyede tamamlandı. İlk Yüksek önem dereceli uyarı (ransomware davranışı) 47. saniyede tetiklendi — şifreleme bitmeden 2 dakika 55 saniye önce. Ancak otomatik izolasyon (müşterinin yapılandırılmış yanıt eylemi) tetiklenmeden önce iki Yüksek uyarı gerektiriyor. İkinci Yüksek uyarı (toplu dosya değiştirme) 2:11'de tetiklendi ve yaklaşık 2:20'de otomatik izolasyon başladı.

Net sonuç: İzolasyon tetikleyicisinden sonra 22 saniye daha şifreleme devam etti. Bu pencerede yaklaşık 180 dosya şifrelendi.

---

Faz 8 — Simülasyon Sonuçları

Metrik	Değer
Şifrelenen toplam dosya	847
Şifrelenen toplam veri	4,2 GB
Şifreleme süresi	3 dak 42 sn
İlk MDE uyarısına kadar geçen süre	4 saniye (Orta)
İlk Yüksek uyarıya kadar geçen süre	47 saniye
Otomatik izolasyona kadar geçen süre	~2 dak 20 sn
İzolasyon tetikleyicisinden sonra şifrelenen dosyalar	~180
Oluşturulan toplam MDE uyarısı	11
Şifreleme tamamlanmadan önce tetiklenen uyarılar	3
Şifreleme tamamlandıktan sonra tetiklenen uyarılar	8
AMSI tespitleri	0
Yakalanan ETW/Script Block Log girişleri	0

---

MITRE ATT&CK Eşleştirmesi

Taktik	Teknik	Alt Teknik	Faz
Savunmadan Kaçınma	T1562	T1562.001 — Araçları Devre Dışı Bırak veya Değiştir	Faz 3 (AMSI)
Savunmadan Kaçınma	T1562	T1562.006 — Gösterge Engelleme	Faz 4 (ETW)
Savunmadan Kaçınma	T1027	T1027.010 — Komut Gizleme	Faz 5
Savunmadan Kaçınma	T1140	— Dosyaların Gizlemesini Çöz/Kodunu Çöz	Faz 5
Yürütme	T1059	T1059.001 — PowerShell	Faz 5, 7
Savunmadan Kaçınma	T1620	— Yansımalı Kod Yükleme	Faz 3
Etki	T1486	— Etki İçin Veri Şifreleme	Faz 7
Komuta ve Kontrol	T1573	T1573.002 — Asimetrik Kriptografi	Faz 6
Toplama	T1005	— Yerel Sistemden Veri	Faz 7

---

Kritik Bulgular ve Risk Değerlendirmesi

Bulgu #1 — Süreç İçi Bellek Yaması ile AMSI Bypass

Risk: Kritik | CVSS 3.1: 8,8 (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)

Microsoft Defender for Endpoint, çalışan bir süreç içinde amsi.dll'yi yamalama eyleminde uyarı üretmiyor. Bir kez yamalandığında, AMSI tarama katmanı o sürecin ömrü boyunca tamamen etkisiz hale geliyor. Tamper Protection yalnızca Defender'ın kendi ayarlarının değiştirilmesini engelliyor — bellek içi AMSI DLL bütünlüğünü korumaktan sorumlu değil.

Çözüm: MDE'nin kernel modu süreç enjeksiyon tespitini etkinleştirin. AMSI DLL bütünlüğü için Credential Guard benzeri korumalar dağıtmayı değerlendirin.

Bulgu #2 — ETW Kör Noktası SOC Telemetri Açığı Oluşturuyor

Risk: Yüksek | CVSS 3.1: 7,5 (AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:H)

Bir PowerShell sürecinde EtwEventWrite'ı yamalamanın, o oturum için tüm Script Block Logging'i ortadan kaldırıyor. MDE'nin PowerShell görünürlüğü büyük ölçüde ETW'ye dayanıyor. Müşterinin aktif bir oturumdan "beklenen telemetri yokluğu" için özel tespit kuralı yoktu.

Çözüm: Bilinen aktif bir PowerShell süreci 4104 olayı üretmeyi bıraktığında uyaran özel bir MDE tespit kuralı uygulayın. Denetim günlüğü bütünlük izlemeyi zorunlu kılın.

Bulgu #3 — Otomatik İzolasyon Yanıt Penceresi

Risk: Yüksek | CVSS 3.1: 7,3

Müşterinin otomatik izolasyon politikası, endpoint'i izole etmeden önce iki Yüksek önem dereceli uyarı gerektiriyordu. Birinci ve ikinci Yüksek uyarılar arasındaki boşluk (~84 saniye), şifrelemenin önemli ölçüde devam etmesine izin verdi.

Çözüm: Otomatik izolasyonu tek bir Yüksek önem dereceli ransomware uyarısında tetiklenecek şekilde yapılandırın. Eşiği düşürün veya toplu dosya değiştirme olayları için özel bir kural oluşturun.

Bulgu #4 — ASR Kuralları Tam Olarak Zorlanmıyor

Risk: Orta | CVSS 3.1: 6,1

İki kritik ASR kuralı — Office makro alt süreç oluşturma ve LSASS kimlik bilgisi erişimi — Zorlama modunda değil, Denetleme modundaydı. Bu testte doğrudan istismar edilmese de, ilk erişim vektörleri için önemli risk teşkil ediyorlar.

Çözüm: Önerilen tüm ASR kurallarını Denetleme'den Zorlama moduna alın. Zorlama öncesinde çakışmaları belirlemek için meşru iş uygulamalarında regresyon testi yapın.

---

Düzeltme Yol Haritası

Acil (0–30 gün)

• İlk Yüksek önem dereceli ransomware uyarısında otomatik endpoint izolasyonunu etkinleştirin
• Kalan ASR kurallarını Denetleme'den Zorlama moduna alın
• ETW telemetri açıkları için özel MDE tespit kuralı dağıtın
• PowerShell Constrained Language Mode istisnalarını gözden geçirin ve kısıtlayın

Kısa Vadeli (1–3 ay)

• Süreç içi DLL bütünlüğü için MDE Kernel modu koruma ayarlarını değerlendirin
• AppLocker veya WDAC aracılığıyla PowerShell scriptleri için uygulama izin listesi uygulayın
• Erken ransomware tespiti için kullanıcı dizinlerine canary dosyalar (tuzak belgeler) dağıtın
• Bu katılımı senaryo olarak kullanarak SOC ekibi ile masa başı tatbikatı gerçekleştirin

Orta Vadeli (3–6 ay)

• Değişmez yedekleme çözümü uygulayın (çevrimdışı/hava boşluklu kopya ile 3-2-1 kuralı)
• İç segmentlerde ağ düzeyi aldatma teknolojisi (honeypot) dağıtın
• Yönetici kullanıcılar için ayrıcalıklı erişim iş istasyonu (PAW) mimarisini değerlendirin
• Kontroller sertleştirildikten sonra takip değerlendirmesi komisyonu oluşturun

---

Sonuç

Bu test, iyi belgelenmiş bypass teknikleriyle güçlendirilmiş hazır ransomware araçlarının, MDE E5 dağıtılmış olsa bile modern kurumsal Windows 11 endpoint'inde başarıyla çalışabildiğini ortaya koyuyor. Kontroller işe yarıyor — ancak doğru yapılandırma, uygun yanıt eşikleri ve açıkların bulunduğu yerlerde telafi edici kontroller gerektiriyor.

En etkili bulgu teknik değil, operasyonel. MDE, yürütmeden 47 saniye sonra Yüksek önem dereceli bir ransomware uyarısı üretti. Bu uyarı hemen otomatik izolasyonu tetikleseydi, şifreleme nihai kapsamın küçük bir bölümüyle sınırlı kalırdı. Belirleyici etken kapasite değil, yapılandırmaydı.

Temel çıkarımlar:

• Bellek yaması yoluyla AMSI bypass, MDE tarafından tespit edilemiyor — bu, Microsoft'un EDR katmanında kapatmadığı bilinen bir açık
• ETW yaması PowerShell telemetrisini ortadan kaldırıyor — SOC görünürlüğü, saldırganın kapatabildiği kontrollere bağlı
• Otomatik yanıt eşikleri son derece önemli — tek bir yapılandırma değişikliği (ilk Yüksek uyarıda izole et), bu simülasyonu 100 dosyanın altında tutardı
• Firewall SSL denetimi yeterli değil — modern ransomware, asimetrik anahtar sarmalama yoluyla C2 bağımlılığını tamamen ortadan kaldırıyor

IOC'leri, ham MDE uyarı zaman çizelgesini ve kayıt defteri/artefakt bulguları içeren tam teknik ek, NDA kapsamında müşteriye teslim edildi.