Son zamanlarda müşterilerimizin talebi üzerine gerçekleştirdiğimiz EDR testlerinde ortaya çıkan ilginç sonuçlar üzerine böyle bir yazıyı kaleme almak istedim. Zira ekipçe elde ettiğimiz çıktılar bu devasa endüstriyi ciddi anlamda sorgulamamıza neden oldu. İstemci başına binlerce dolarlık fiyatlandırmayla sunulan EDR ürünleri, kapsamlı koruma vaadiyle çeşitli kurum ve kuruluşlarda yer ediniyor.

Bununla beraber potansiyel alıcılara fikir vermesi bakımından birçok bağımsız (!) güvenlik çözümü derecelendirme ve test kuruluşu, MITRE ATT&CK gibi frameworklerde yer alan teknikleri kullanarak EDR çözümlerini test ediyor ve kurumsal pazarlamada referans olacak çıktılar üretiyor. Peki ya bağımsız olduğu iddia edilen bu test kuruluşlarının ve pazarlama ekiplerinin söyledikleri ne kadar doğru? Ürünler gerçekten kurumsal düzeyde bir koruma sağlayacak şekilde vaat edileni sunabiliyor mu yoksa yetersiz mi? Günümüzde oldukça dile getirilen yapay zeka teknolojisi gerçekten zararlı yazılım inceleme alanında ne kadar etkin kullanılıyor?

Secunnix bünyesindeki “Zararlı Yazılım Araştırmaları” ekibimiz bu doğrultuda piyasada en bilinen bazı EDR çözümlerini edinerek kendisine özgü saldırgan metodlarla çeşitli denemeler gerçekleştirdi. Testler kapsamında geliştirdiğimiz deneysel zararlıların yanı sıra ransomware gruplarının bir sunucuyu ele geçirdiğinde EDR çözümlerini atlatmak/bypass etmek için nasıl teknikler kullandığını da simüle ettik.

Zira bu bir kedi fare oyunu ve saldıran yerine koruyan taraftaysanız, işiniz zaten saldırgandan önce saldırganın yapabileceklerini, izlediği metodları düşünerek gereken önlemleri almak diyebiliriz. Haliyle bu blog yazısı boyunca EDR’ların ne olduğundan kısaca bahsedip saldırganlar tarafından bunları atlatmak amacıyla kullanılan birtakım metodlara ve testler esnasında neler yaptığımıza yer vereceğiz.

EDR Nedir?

Endpoint Detection and Response veya daha kısa bir deyişle EDR çözümleri, bir organizasyon içerisinde yer alan uç nokta cihazları sürekli izleyip, herhangi bir tehdit gördüğünde içerisindeki teknolojiler yardımıyla gerçek zamanlı olarak müdahale edebilen bilgisayar yazılımları denilebilir. Çalışma mantıkları antivirüs yazılımlarına benzerken, aynı zamanda daha fazla izlenebilirlik, özelleştirilmiş koruma ve kapsam sağlarlar.

Büyükçe bir organizasyonu yönetiyorsanız kullanıcılarınızın zararlı mail ekini açıp açmayacağını, önüne her gelen linke tıklayıp tıklamayacağını, yanlış bir dosya yükleyip yüklemeyeceğini bilemezsiniz. Olumsuz bir durumda bunu hızlıca tespit edip aksiyon alabilmek bakımından kuruluşunuzun büyüklüğüne uygun SIEM ve EDR çözümlerine ihtiyacınız var.

Çalışma mantığını ise kısaca açıklayacak olursak, EDR’lar klasik güvenlik çözümlerinin aksine “sensor” adı verilen özelliklere sahiptirler. Sensörler sistemlerdeki anomalileri tespit edip engellenmesi için gereken aksiyonun alınmasını sağlarken, aynı zamanda kontrol sunucusuna da gereken raporlama işlemlerini gerçekleştirirler. EDR bypass etmek isterken yapmaya çalıştığımız şey de genellikle bu sensörlerin dikkatini çekmeyecek şekilde zararlılar geliştirmek ya da çeşitli yöntemlerle bu sensörün kendisini kör etmekten ibaret.

EDR Atlatma Sürecinde Değerlendirme Mekanizmasına Yönelik Araştırmalar

A. Dosya Repütasyonu ve Dosya Yapısının Sürece Etkisi

Geliştirdiğimiz zararlılarda ağırlıklı olarak üzerinde çalıştığımız şey, hedef EDR çözümünün neye göre bir programı ve dosyayı (en azından statik olarak) zararlı işaretlediğini bulmaktı. Bu süreçlerin bir bütününe biz dosya repütasyonu demeyi tercih ediyoruz. Her çözümün yapmış olduğu analiz ve değerlendirme mekanizması farklı olduğu için başarısı sizin araştırmanıza bağlı olarak değişiyor.

Daha önceden X(Twitter)'dan paylaştığımız gönderiden de testlerini izleyebileceğiniz gibi, örnekte geliştirdiğimiz zararlı; SentinelOne, Trellix, ESET gibi sektörde en bilinen ürünleri başarıyla atlatmayı başardı ve bu ürünlerden ne yazık ki aylarca aynı sonucu elde ettik. Binlerce dolara satılan bu ürünleri rahatlıkla geçebilmemizi sağlayan tek şey, EDR sensörlerinin çalışma mantığını anlamış olmamızdı.

#sentinelone EDR evasion test 🤷‍♂️
Remnants of red team operation pic.twitter.com/4Zqsfe9QbE

— Secunnix (@secunnix) May 13, 2023

Günümüzde birçok EDR çözümü, yeni nesil veya daha farklı bir tabirle egzotik dillerle geliştirilmiş ikili dosyaları düzgün bir şekilde analiz edememekte. Güvenlik yazılımlarında bulunan antivirüs modülleri genellikle C, C++ ve C# gibi dillerle yazılmış zararlıların statik analizine yönelik geliştirildiği için, bunlardan çok uzak yapıya sahip şekilde hazırlanmış bir dosyayla karşılaştıklarında haliyle tespit edemiyor.

Örneğimizi sadece Rust ile geliştirdik ve hiçbir ekstra atlatma tekniği kullanmadık. Hatta hedefimizden “command shell” oturumu almak için doğrudan açtığımız soket bağlantısı bile EDR sensörleri tarafından anormal bir etkinlik olarak algılanmadı. “scantime” evresinde tespit edilemeyen zararlımız, “runtime”da da başarılı oldu.

Şimdi burada sorgulanması gereken nokta, mühendislik anlamında iyi bir güvenlik yazılımının sadede statik analiz sürecine ve imza tabanlı çalışmaya güvenmesini beklemezsiniz/beklememelisiniz. Davranışsal tespit modelleri bir soket bağlantısı açıldığında, en azından daha önceden karşılaşılmamış bir şeyse buna karşı alarm üretmesi gerekiyor.

B. Normalizasyon ve Doğallık

EDR bypass süreçlerinde en çok dikkat edilmesi gereken bir diğer husus, programın ne kadar normal göründüğüdür. Dosya repütasyonuyla da kısmen ilgili olan normalizasyon, undetection teknikleri arasında oldukça önemli bir yer edinir. Bunun için gerek APT grupları, gerek de red teaming senaryolarında oldukça sık kullanılan AutoIt scripting dili ile basit bir MsgBox çıkaran program yazdık ve VirusTotal kullanarak bazı deneyler yaptık.

Yaptığımız incelemelerde birçok EDR çözümünde dosyanın 32-bit mi yoksa 64-bit mi olduğuna göre tespit oranlarında değişiklikler yaşanırken, dosyanın bir simgeye sahip olup olmamasının da etkili olduğunu gördük. Bir simgeye sahip ve 64-bit olarak derlenen yazılımlar daha az şüpheli görünürken, 32-bit olup ve simgesiz olarak derlenen yazılımlar daha riskli olarak kabul edildi.

32-bit simgesiz:

64-bit simgeli:

Özellikle günümüzde “AI powered” şeklinde sunulan güvenlik çözümlerinin değerlendirme kriterleri arasında dosyanın oluşturulma biçiminin bile ne kadar etkili olduğunu buradan anlayabiliriz. Programımız aslında zararsızdı, herhangi bir risk teşkil etmiyordu fakat onu zararlı olarak işaretleten şey repütasyon dediğimiz şeydi.

Şu ana kadar keşfettiğimiz kadarıyla tespit oranını düşürmek için yapılabilecek en basit şeyler aşağıdakiler olabilir:

Sonuncu hususunda, oldukça sıkça rastlanan bir teknik olmasına karşın halen işe yaradığını doğrulayabiliriz. Normalde doğrudan uzak bir hedefe soket bağlantısı açtığınızda bu zararlınızın antivirüs çözümü karşısındaki risk seviyesini yükseltirken, sıradan bir mesajlaşma programına bağlantı yapılması veya güvenilir bir web adresine HTTP istekleri çıkması nispeten daha kabul edilebilirdir.

Secunnix Zararlı Araştırmaları Ekibi olarak, komuta kontrol sunucusu olarak Telegram kullanan basit bir deneysel RAT (remote access trojan/remote administration tool) geliştirdik. Basitçe mantığını açıklayacak olursak, hedef sistemde çalıştırıldığında Telegram bot API adresine ufak bir mesaj iletiyor ve operatörden gelecek komutları beklemeye koyuluyor. Gelen komutları uygun şekilde ayıklıyor ve işlemleri yerine getiriyor.

Sadece bu teknik yardımıyla en popüler bilinen ve testlerde listelerin üst sıralarını paylaşan birkaç güvenlik çözümünü başarıyla geçmeyi başardık ve geliştirdiğimiz RAT’ın aktiviteleri bu çözümler tarafından hiçbir zaman zararlı kabul edilmedi. Zira gelen ve giden veri bir Telegram adresinden ibaret. Zararlımız bir mesajlaşma istemcisi gibi çalışıyordu.

C. Dijital İmzalara Olan Güvenin Getirdiği Riskler

Maalesef günümüzde halen birçok EDR ve antivirüs çözümü tarafından dijital imzası olan bir program, özellikle analiz edilip kötü amaçlı olarak veritabanına eklenmediyse gayet güvenilir gibi kabul ediliyor.

Teknik olarak bakıldığında, dijital imzaların amacı bir programın istenmeyen değişikliklere maruz kalmadığını ve doğrudan geliştiriciden geldiğini gösteren bir doğrulama mekanizması olması. Dış kaynaklar (örneğin bir saldırgan) tarafından yapılan değişiklikler dosyanın bütünlüğünü bozduğu için imzası da geçersiz hale geliyor ve güvenilmemesi gerektiğini gösteriyor.

Fakat iş, dijital imzanın gerçekten amacının ne olduğundan ziyade; bu sertifikayı edinmenin ücretli olması nedeniyle zararlı geliştiricilerinin bunu almasının uzak olduğu düşünülerek yapay bir güvenilirlik mekanizması inşa etmeye dönüşmüş durumda. Script kiddie adını verdiğimiz, acemi geliştiricilere karşı bu yeterli bir önlem olsa bile, oldukça büyük bütçelerle çalışan -ransomware grupları, APT’ler?- saldırganlar parası neyse verip neredeyse sıfır denetimle imza alabiliyorlar.

Örneğin aşağıda dünyanın en büyük sertifika sağlayıcılarından biri olan DigiCert’in kod imzalama fiyatlarını görüyorsunuz. 1 yıllık “EV/Extended Validation” tipi sertifikayı 755 dolara alabiliyorsunuz.

Daha kötüsü, saldırganlar artık imza satın almakla da uğraşmıyor doğrudan imzalı programları amaçları doğrultusunda kullanıyor. Örneğin aşağıda dijital imzalı bir “rootkit temizleyici” olan TDSSKiller kullanılarak EDR çözümlerinin nasıl devre dışı bırakıldığını görüyorsunuz.

Ne yazık ki gerçekleştirdiğimiz testlerde en büyüklerden 4 EDR ailesi saldırıyı engellemek bir yana, kendisini bile koruyamadı ve servisleri TDSSKiller tarafından kolayca herhangi bir alarmla karşılaşmadan kaldırıldı. Birçok ransomware grubu tarafından da kötüye kullanılan bu araç, “local administrator” yetkileriyle sistemde çalıştırıldığında ve “-dcsvc” parametresiyle hedef servis kendisine verildiğinde başarıyla istenileni yerine getiriyor.

İşin ilginç tarafı TDSSKiller, çeşitli rootkitlerin kendisini tespit etmemesi için virüslere benzer bir çalışma şekline sahip. TLS Callback’lerin kullanılması, kendisine özgü bir packer kullanması, yoğun ve riskli kabul edilebilecek WinAPI’lerden yararlanması gibi yürüttüğü süreçler potansiyel olarak zararlı kabul edilmesi gerekirken muhtemelen sadece dijital imzası var olduğu için EDR çözümleri tarafından görmezden gelindi. Nerede “tamper protection” modülleri?

2 – EDR Atlatma Sürecinde Tasarımsal Zafiyetler

EDR sensörleri, temelde tipik olarak birer rootkit gibi çalışırlar. Yaptıkları şey, çalıştırılan her programı çeşitli ajanlarla takip edip riskli işlemleri veya daha önceden imzası eklenmiş zararlı kod parçacıklarının yürütülmesini engellemekten ibaret. Sistemde kurulu olan EDR yazılımı ve sürücüleri, her bir program çalışırken “API Hooking” veya “Process Injection” dediğimiz teknikleri uygulayarak yürütme sürecinin kendi üzerlerinden gerçekleştirilmesini sağlar. Böylece ilgili programı takip edebilir ve gerekirse sonlandırabilirler.

Bir Windows PE (Portable Executable) programı çalışırken işlevini yerine getirebilmesi için çeşitli kütüphaneler ve API’lara ihtiyaç duyar. Bu API’ları bulma sürecini genellikle “ntdll.dll” adını verdiğimiz bir yapıyla gerçekleştirirler. Program ilk çalıştığında “ntdll.dll” aracılığıyla IAT (Import Address Table) yapısında yer alan Native API’ları bulup sunar.

EDR ürünleri tam bu sırada araya girer ve kendisini de programa inject eder ve artık olaylar çözümün “kanca” DLL’i üzerinden devam eder. Eğer program masumsa çalışmasına izin verir, değilse belirli bir kod döndürerek çıkış yapar.

Örneğin Windows Defender kullanılan sistemlerde birçok red teamer’ın da bildiği gibi, potansiyel olarak riskli processlere (powershell.exe, cmd.exe vb.) Amsi.dll eklenerek süreç kontrol edilir. Bunu atlatmak için AmsiOpenSession metodunun çalışması bozularak Amsi.dll’in hatalı parametre kodu döndürmesi sağlanır.

Birçok antivirüsün genel yapısını incelemek ve hangi süreçleri kullandığını öğrenmek için etheral_vx tarafından yaklaşık 2 sene önce yazılan Antivirus Artifact III dökümanına da ayrıca göz atabilirsiniz.

https://github.com/ethereal-vx/Antivirus-Artifacts

EDR sensörlerini atlatmak bu kadar basit olmadığı için user mode tarafında genellikle daha gelişmiş bir teknik kullanılır. Doğrudan Sistem Çağrıları (Direct Syscall) ve Dolaylı Sistem Çağrıları (Indirect Syscall).

A. Doğrudan Sistem Çağrıları (Direct Syscall)

En basit haliyle doğrudan sistem cağrıları tekniği, EDR sensörlerinin kanca atmasını (hook) -Türkçe terimleri kullanmayı seviyorum- engellemek için, zararlıda kullanılacak olan API’ları “ntdll.dll” aracılığıyla almak yerine kodun içerisinde Assembly komutlarıyla uygulamak denilebilir.

Bu sayede program “ntdll.dll”e başvurmaz ve ihtiyacı olan API’ları doğrudan kullanır. “ntdll.dll” çağırılmadığı için haliyle EDR sensörleri de sürece kendilerini enjekte etmedikleri için kör olacaktır. Bu tekniğe yönelik birçok PoC mevcuttur, örneğin Hells Gate, Halo’s Gate, Syswhispers2 ve 3; direct syscall’ın uygulanışını ispatlayan başarılı çalışmalardır.

Maalesef ilk zamanlarda oldukça efektif olan bu metod; sistem çağrılarının “ntdll.dll” dışında yürütülmesi ve “RET” komutunun direct syscall uygulanan programın doğrudan bellek alanında yer alması nedeniyle, bazı EDR çözümleri tarafından kernel callback’ler aracılığıyla tespit edilebilir hale gelmiştir. Zira normal programlar böyle davranışlarda bulunmazlar. Anlayacağınız üzere iş yine normalizasyon ve repütasyon başlığında anlattıklarımıza geliyor.

B. Dolaylı Sistem Çağrıları (Indirect Syscall)

Dolaylı sistem çağrıları çalışma mantığı bakımından doğrudan sistem çağrıları tekniğiyle benzerdir. Fakat bunun da ötesinde sistem çağrılarının işlenmesi bakımında ufak birkaç farklılıklara sahiptir.

Direct syscall tekniğinde “ntdll.dll”e ait süreç tamamen olayın dışındayken ve “RET” komutları bu DLL yerine programın kendisindeyken, indirect syscall söz konusu olduğunda çağrılar “ntdll.dll” aracılığıyla yürütüldüğünden EDR süreçleri tarafından normal algılanır. Peki o halde nasıl da EDR “hook” işlemini gerçekleştiremiyor derseniz mantık basit aslında. Zararlı kodun yürütülmesi esnasında JMP komutu “ntdll.dll”in entrypoint (başlangıç noktasını) işaret etmek yerine sistem çağrısının olduğu bloğa gider. Böylece “ntdll.dll”den habersiz bir “execution” süreci söz konusu olmadığından tespit edilmesi biraz daha zordur.

Her iki teknik de halen işe yaramasına karşın, indirect syscall yöntemi daha az tespit edilebilir zararlılar geliştirmeye yardımcı olabilir. Dikkat edilmesi gereken şey, bunlar user mode hooking’ten kaçınma yöntemleridir. Kernel mode hooking yapan bir güvenlik çözümüyle karşı karşıyaysanız bu teknikler tespit edilebilir.

Ayrıca Microsoft tarafından Windows sistemler için sunulan Event Tracing for Windows (ETW) yapısı da bazı EDR’lar tarafından kullanılarak çağrıların söz konusu olduğu stack yapıları kontrol edilebilmektedir. Her iki tekniğin de oldukça temiz bir şekilde uygulanışını görmek istiyorsanız aşağıdaki yazıyı da tavsiye edebiliriz.

https://redops.at/en/blog/direct-syscalls-vs-indirect-syscalls

3 – EDR Devre Dışı Bırakma Sürecinde Kernel Mode Yöntemler

EDR atlatma sürecinde edindiğimiz tecrübeler ve yaptığımız testlerden yola çıkarak vardığımız çıkarım, kernel mode tarafındaki teknikler kullanılarak gerçekleştirilen çalışmalar daha başarılı bir sonuç vermekte. Zira özel zararlı geliştirmek, dosyanın gerekli repütasyona sahip olmasını sağlamak oldukça efor isteyen bir süreç. Birçok saldırgan ise “zaman=kazanç” prensibinden hareketle, daha önceden geliştirdikleri zararlıları defalarca farklı sistemlerde kullanmak zorundalar.

Birçok ransomware grubu, hedef sisteme sızdığında gördüğümüz kadarıyla encryption işlemini yapacak zararlının kendisini tespit edilemez yapmak yerine doğrudan EDR’ı kaldırmaya veya sensörünü kör etmeye odaklanıyor. Daha sonrasında ise rahatlıkla zararlısını sistemde yürütüyor. Burada ağırlıklı olarak kernel mode uygulamaların zafiyetlerinden yararlanmak oluyor. Örneğin zafiyetli sürücüleri, kernel’ın kendisinden kaynaklı tasarımsal problemler gibi.

Bring Your Own Vulnerable Driver (BYOVD) ve PPLFault (GodFault) aracılığyla EDR SandBlast kullanımı başarıyla çalışan tekniklerden en bilinenleridir.

A. Bring Your Own Vulnerable Driver (BYOVD)

Hatırlarsanız yazının başlarında güven ilişkisinin suistimaline uzun uzadıya değinmiştik. Bilindiği gibi, yeni nesil Windows sistemlerde Driver Signature Enforcement (DSE) güvenlik özelliği nedeniyle imzasız sürücüler “test ve hata ayıklama modu” açılmadan kurulamamakta. Yani her sürücünün zorunlu olarak bir dijital imzaya sahip olması gerekiyor. Sürücüler söz konusu olduğunda ise dijital imza almak normal programlara kıyasla çok daha zor elbette.

Dijital imzaya sahip olan sürücüler, haliyle kernel mode yani sistemde en yetkili ve kritik süreçler olarak çalışmaktalar. BYOVD tekniği, halihazırdaki masum ve güvenli kabul edilen bir sürücünün üzerinde var olabilecek çeşitli güvenlik açıklarının tespit edilip bunun EDR/antivirüsleri kaldırmak veya devre dışı bırakmak amacıyla kullanılması denilebilir. Böylece hem güven sağlanır, hem de kernel seviyesinde süreçlere müdahale edilebilir.

Çeşitli ransomware grupları ve devlet destekli siber aktörler (APT) bu yöntemi oldukça fazla kullanırlar. Ne yazık ki, EDR’ların birçoğu bu tekniğe “signature-based” bir şekilde karşı koymakta. Yani daha önceden başkaları tarafından zafiyetli olduğu tespit edilmemiş, başkaları tarafından da kullanılmamış bir sürücüye sahipseniz çoğunlukla hedefteki güvenlik çözümlerini başarıyla hızlı bir şekilde devre dışı bırakabilirsiniz.

B. PPLFault Aracılığıyla EDR Sandblast

BlackHat Asia 2023’te konferansta sunulan PPLFault tekniği, Windows Code Integrity modülünde bulunan bir TOCTOU zafiyeti aracılığıyla kod yürütmeye imkan tanıyor. Bunu güvenlik araştırmacıları EDR SandBlast ile birleştirerek, herhangi zafiyetli sürücü kullanmadan sadece Windows bileşenlerindeki tasarımsal hatalar sayesinde tamamen EDR süreçleri ve ETW’den arındırılmış bir “cmd” oturumu elde etmemize imkan tanıyan bir araç haline getirmişler.

Araştırmalarımız esnasında oldukça ilgi çekici bulduğumuzdan bu yöntemi de EDR’lar üzerinde uyguladık. Ne yazık ki 5 çözümden yalnızca 2’si engelleyebildi. Geriye kalanlarda başarıyla EDR sensörleri tarafından takip edilmeyen komut satırı elde edebildik. Bu durum ilgili çözümlerin mühendisliklerini oldukça sorgulamamıza neden oldu zira ne dijital imza var ne de BYOVD, yürütülen süreçlerin davranışları da risk seviyesi yüksek hareketler olmasına rağmen tespit konusunda başarısız oldular.

Başarıyla engelleyebilen diğer 2 EDR çözümü ise, yine davranışsal değil imza tabanlı bir şekilde gerçekleştirdi. Yeni nesil ve yapay zeka tabanlı olduğu söylenen çözümleri atlatmayı başardık ve halen birçoğunda EDR Sandblast with GodFault (PPLFault) işe yaramakta.

4 – Sonuç

Yazı boyunca incelediğimiz teknikler ve yaptığımız testler sonucunda “EDR” ve güvenlik çözümleri sektörü hakkında elde ettiğimiz çıkarımları madde madde özetleyecek olursak:

•EDR çözümlerinin kurumun güvenliği hususunda oldukça etkili olduğu fakat çizilen güvenlik mimarisinin temel yapı taşı olmaması gerektiğini

•Sektörde uzun geçmişiyle bilinen, normal kullanıcıya hitap eden antivirüs şirketlerinin geliştirmiş olduğu EDR çözümlerinin, “yapay zeka destekli” olduğu iddia edilen fakat öyle olmayan yazılımlara kıyasla daha başarılı olduğu

•EDR çözümleri konvansiyonel zararlı tehditlere karşı başarıyla koruma sağlarken, konvansiyonel olmayan ve güven ilişkisini suistimal eden saldırılara karşı oldukça zayıf kaldığı

•Çeşitli test kuruluşları tarafından açıklanan sonuçların ve koruma yüzdelerinin birçoğunun gerçeği yansıtmadığını ve genellikle pazarlama amaçlı olduğunu

•Kurum ve kuruluşların güvenlik mimarisi tasarlanırken sadece EDR’lara işi bırakmak yerine, bunlarla beraber ekstra çözümlerin yanı sıra sıkılaştırmaların ve SIEM çözümlerinin de kullanılması gerektiğini

söyleyebiliriz. Secunnix olarak müşterilerimizin güvenliğini oldukça ciddiye alıyoruz ve pazarlama amaçlı realiteden uzak söylemler yerine doğru ve çözüme yönelik stratejiler uygulamaya çalışıyoruz. Aynı zamanda siber güvenlik söz konusu olduğunda hepimiz aynı gemideyiz, hepimizin birçok verisi dijital ortamda yer alıyor ve bunun farkındayız. Bu sebeple gerek zararlı araştırmaları ekibimiz olsun, gerek de blue team ve red team alanında çalışmalar yürüten diğer ekiplerimiz olsun sizleri blogumuzda aktif bir şekilde bilgilendirmeye ve yazılar yazmaya devam edeceğiz.

Sağlıcakla kalın.