Linux için Windows Alt Sistemi (WSL), Windows’taki geliştirici deneyimini dönüştürdü. Ancak aynı zamanda saldırganlar için sessizce güçlü bir saklanma yeri de yarattı.
WSL2 ile Microsoft, hafif çeviriden tam bir sanal makine (VM) modeline geçti. Bu mimari değişiklik, rakiplere Hyper‑V içinde çalışan ve geleneksel uç nokta güvenlik araçları tarafından nadiren izlenen yarı yalıtılmış bir Linux ortamı sağlıyor.
Kırmızı takım oyuncuları ve gerçek dünyadaki hücum oyuncuları için bu bir hediyedir. WSL2’ye sahip bir Windows ana bilgisayarı, genellikle EDR’den çok az görünürlükle veya hiç görünürlük olmadan, işlemleri çalıştırabilen, dosyalara erişebilen ve dahili ağa erişebilen ikinci bir işletim sistemini etkili bir şekilde içerir.
Uygulamada, operatörler bunu yoğun şekilde izlenen Windows oturumlarından WSL2’ye geçmek ve ardından bu bölgeden özgürce çalışmak için kullandılar; araçları çalıştırıyor, yükleri hazırlıyor ve minimum tespit riskiyle veri ve kimlik bilgilerini topluyorlar.
Pek çok geliştirici iş istasyonunda, WSL dağıtımları yararlı ganimetlerle doludur: korumasız SSH anahtarları, belirteçler ve kabuk yapılandırma dosyalarındaki ve ortam değişkenlerindeki kimlik bilgileri ve üretim hizmetlerini etkileyen komut dosyaları.
Bir saldırgan Windows tarafında kod yürütmeye başladığında WSL2, erişimi derinleştirmek ve tespit alanını azaltmak için doğal bir sonraki adım haline gelir.
Bir Windows implantından WSL’ye ulaşmanın bariz yolu, CreateProcess’i saran Beacon Nesne Dosyası (BOF) gibi bir şeyi kullanarak doğrudan wsl.exe’yi çağırmaktır.
WSL2 Neden Saldırganlara Çekici Geliyor?
Bu, operatörün C2 aracısından seçilen bir WSL dağıtımında komutları başlatmasına olanak tanır. Bu “yarım yamalak WSL komutu” yaklaşımı işe yarıyor ve şu ana kadar nadiren işaretleniyor olsa da, rahatsız edici eserler bırakıyor: rastgele bir süreçten wsl.exe üreten şüpheli bir komut satırı, tespitler yakalandığında savunucuların kolayca girebileceği bir şey.
Microsoft, WslApi.dll dosyasındaki WslLaunch aracılığıyla, WSL içinde doğrudan programlı yürütme olanağı sunduğu görünen, daha kullanıcı dostu bir API kullanıma sunuyor.

Ancak bu DLL dosyasının derlenmesi, WslLaunch’un bir komut dizesini biçimlendirdiğini ve perde arkasında wsl.exe’yi CreateProcess aracılığıyla oluşturduğunu ortaya koyuyor.
Başka bir deyişle, “resmi” API, kırmızı ekip üyelerinin zaten yaptığı şeyin aynısını yapıyor ve aynı süreç eserlerini bırakıyor.
Bu, bu modelde neden çok az statik algılama olabileceğini açıklıyor: birçok yasal uygulama zaten bu şekilde davranıyor.
Araştırmacılar, daha gizli ve daha esnek bir şey elde etmek için WSL hizmetini destekleyen WSL2 Bileşen Nesne Modeli (COM) arayüzüne yöneldiler.
Microsoft, açık kaynaklı WSL’ye sahiptir ve wslservice.idl dosyası, wsl.exe’yi oluşturmak yerine Linux işlemlerini COM aracılığıyla başlatabilen CreateLxProcess gibi alt düzey işlevleri açığa çıkaran bir arabirimi belgelemektedir.
Teorik olarak, bir BOF, WSL örneklerini numaralandırmak ve wsl.exe alt işlemi olmadan komutları yürütmek için doğrudan COM’u kullanabilir.

Uygulamada COM katmanının dağınık olduğu ortaya çıktı. WSL2 COM arayüzü, aynı CLSID’nin yeniden kullanılması nedeniyle zaman içinde ciddi biçimde değişti.
Bağımsız değişkenler eklendi ve kaldırıldı, işlevler eklendi ve silindi ve vtable düzenleri sürümler arasında kaydırıldı.
Gerçek Dünyadaki Kötüye Kullanım
Mevcut IDL’den oluşturulan bir istemci yalnızca en yeni WSL yapılarında çalışıyordu; eski sistemlerde sıralama uyumsuzlukları nedeniyle çöküyordu ve hatta tamamen yanlış yöntemlerin çağrılmasıyla sonuçlanıyordu.
Bunu çözmek için araştırmacılar, her WSL sürümüyle birlikte gönderilen proxy saplama DLL’sinden (WslServiceProxyStub.dll) IDL tanımlarını dinamik olarak yeniden oluşturmak için James Forshaw’un OleView.Net’inden yararlandı.
Dahili ProxyFileList yapısını ayrıştırarak sürüm açısından doğru IDL’ler ve ardından başlıklar oluşturdular, arayüzlerin nasıl geliştiğini haritaladılar ve tek bir BOF’da birden fazla arayüz varyantını uyguladılar.

Çalışma zamanında BOF, kayıt defterinden WSL sürümünü okur (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss\MSI) ve eşleşen arayüz uygulamasını seçer.
Sonuç, WSL2 örneklerini numaralandırabilen ve wsl.exe’yi açıkça oluşturmadan birden fazla WSL2 sürümünde COM aracılığıyla içlerindeki komutları yürütebilen bir Cobalt Strike BOF olan “tek WSL BOF” oldu.
Kod çirkin ve koşullu ağırdır ve gelecekteki WSL sürümleri uyumluluğu tekrar bozabilir, ancak WSL2’yi kırmızı takımlar için birinci sınıf bir pivot mekanizmasına dönüştürür.
Savunmacılar için sonuç çok açık: WSL2’yi yaygın olarak kullanan herhangi bir Windows mülkü, ana bilgisayarla sıkı bir şekilde entegre edilmiş, kötü izlenen bir yürütme ortamını açığa çıkarıyor.
Güvenlik ekipleri, wsl.exe kullanımını izlemek, WSL dosya sistemlerini incelemek ve WSL hizmetlerini hedef alan şüpheli COM etkinliğini izlemek de dahil olmak üzere WSL2’yi saldırı yüzeyinin bir parçası olarak ele almaya başlamalıdır.
Saldırganlar zaten WSL2’yi gizli bir saklanma yeri olarak görüyor; savunucuların yetişmesi gerekiyor.
Anında Güncellemeler Almak ve GBH’yi Google’da Tercih Edilen Kaynak Olarak Ayarlamak için bizi Google Haberler, LinkedIn ve X’te takip edin.