SOC Analyst Perspektifinden CrowdStrike Falcon Event Search: CQL ile Detection Investigation ve Threat Hunting

Bir detection görmek çoğu zaman yalnızca başlangıçtır.

Bir SOC analyst için asıl önemli nokta, oluşan bir alert’in gerçekten ne anlama geldiğini anlayabilmektir. Çünkü Falcon üzerinde görülen bir detection, çoğu zaman olayın yalnızca ilk sinyalini göstermektedir. Gerçek investigation süreci ise analyst’in alert’in ötesine geçerek olayın bağlamını incelemeye başlamasıyla şekillenmektedir.

Örneğin Falcon üzerinde görülen bir Suspicious PowerShell Command Line detection’ı ilk bakışta dikkat çekici görünebilir. Ancak analyst tarafında asıl sorular genellikle bundan sonra başlamaktadır:

• Bu PowerShell neden çalıştı?
• Hangi kullanıcı bağlamında gerçekleşti?
• Aynı host üzerinde ilişkili başka aktiviteler var mı?
• Komut satırında dikkat çekici parametreler bulunuyor mu?
• Bu davranış tek seferlik mi, yoksa daha büyük bir olayın parçası mı?

Detection ekranı çoğu zaman analyst’e yalnızca özet bir görünüm sunmaktadır. Olayın nasıl geliştiğini, hangi process’lerin birbirini tetiklediğini, aynı endpoint üzerinde ilişkili aktivitelerin bulunup bulunmadığını veya şüpheli davranışların daha geniş bağlamını anlayabilmek için daha derin görünürlüğe ihtiyaç duyulmaktadır.

Tam da bu noktada CrowdStrike Falcon Event Search devreye girmektedir.

Event Search, Falcon üzerinde oluşan endpoint telemetrilerini daha detaylı incelemeye, olayın çevresindeki aktiviteleri anlamaya ve gerektiğinde threat hunting süreçlerini ilerletmeye yardımcı olan temel çalışma alanlarından biri olarak öne çıkmaktadır.

SOC analyst’leri için Event Search yalnızca bir arama ekranı değildir. Çoğu zaman bir detection’ın gerçekten şüpheli bir davranış mı yoksa beklenen bir aktivite mi olduğunu anlamaya yardımcı olan investigation alanlarından biri hâline gelmektedir.

Bu süreçte analyst’lerin kullandığı temel yapı ise CrowdStrike Query Language (CQL) olmaktadır.

İlk bakışta karmaşık görünebilse de, doğru mantıkla yaklaşıldığında CQL; detection investigation, IOC araştırmaları, timeline analizi ve threat hunting süreçlerinde analyst’e ciddi seviyede görünürlük sağlayabilmektedir.

Bu rehberde, SOC Analyst perspektifinden CrowdStrike Falcon Event Search mantığı, CQL temelleri, analyst tarafında sık kullanılan kritik alanlar, detection investigation süreçleri ve Falcon üzerinde gerçekleştirilen temel threat hunting yaklaşımı uygulamalı şekilde incelenecektir.

Şekil 1: CrowdStrike Falcon Event Search ekranına genel bakış ve analyst tarafında investigation süreçlerinde kullanılan temel bileşenler.

CrowdStrike Falcon Event Search Nedir?

Bir detection görmek çoğu zaman analyst için yalnızca başlangıç noktasıdır.

Falcon üzerinde oluşan bir alert, analyst’e şüpheli bir davranışın gerçekleşmiş olabileceğine dair ilk sinyali verebilir. Ancak olayın nasıl gerçekleştiği, hangi aktivitelerle ilişkili olduğu veya aynı host üzerinde başka neler yaşandığı çoğu zaman detection ekranı üzerinden tam olarak görülememektedir.

Örneğin Falcon üzerinde görülen bir:

‘Suspicious PowerShell Command Line’

detection’ı analyst açısından dikkat çekici olabilir. Ancak çoğu zaman asıl sorular bundan sonra başlamaktadır.

• PowerShell hangi process tarafından tetiklendi?
• Komut satırında dikkat çekici parametreler var mı?
• Bu kullanıcı için beklenen bir davranış mı?
• Aynı zaman aralığında network activity oluşmuş mu?
• Başka suspicious event’ler mevcut mu?

İşte bu noktada CrowdStrike Falcon Event Search, analyst tarafında daha derin görünürlük sağlayan temel investigation alanlarından biri hâline gelmektedir.

Basitçe ifade etmek gerekirse Event Search, Falcon üzerinde oluşan ham endpoint telemetri verileri (raw telemetry) içerisinde arama yapılmasını sağlayan investigation ekranıdır.

Detection ekranı çoğu zaman olayın özetini gösterirken, Event Search analyst’e olayın arkasındaki detayları görme imkanı sunmaktadır.

Başka bir ifadeyle:

Detection size “bir şey oldu” der. Event Search ise “tam olarak ne oldu?” sorusuna cevap vermeye yardımcı olur.

Bir analyst için bu fark oldukça kritiktir.

Çünkü birçok olayda detection tek başına yeterli bağlam sağlamayabilir. Özellikle olay biraz daha investigation gerektiriyorsa analyst çoğu zaman Event Search tarafına geçerek ilgili process aktivitelerini, command line detaylarını, kullanıcı davranışlarını ve timeline içindeki ilişkili event’leri incelemeye başlamaktadır.

Pratikte Event Search üzerinden analyst’ler:

• Process execution aktivitelerini
• Network bağlantılarını
• Command line detaylarını
• User ve host context bilgilerini
• File ve registry davranışlarını
• Timeline correlation çalışmalarını

inceleyebilmektedir.

Bu nedenle Falcon Event Search yalnızca bir arama ekranı olarak görülmemektedir.

Özellikle detection investigation ve threat hunting süreçlerinde, analyst tarafında olayın bağlamını anlamaya yardımcı olan temel çalışma alanlarından biri hâline gelmektedir.

Şekil 2: CrowdStrike Falcon üzerinde detection ekranından Event Search tarafına geçiş ve analyst investigation workflow’u.

CrowdStrike Query Language (CQL) Nedir?

CrowdStrike Falcon Event Search üzerinde investigation süreçlerini ilerletebilmek için analyst’lerin kullandığı temel yapı CrowdStrike Query Language (CQL) olmaktadır.

İlk bakışta CQL, özellikle platformla yeni tanışan analyst’ler için biraz karmaşık görünebilir. Çünkü Event Search tarafında ham telemetri verileri içerisinde sorgular çalıştırılmakta ve Falcon sensor tarafından üretilen event’ler filtrelenmektedir.

Ancak pratikte analyst tarafında CQL çoğu zaman düşünüldüğü kadar karmaşık ilerlememektedir.

Çünkü çoğu investigation sürecinde analyst’ler genellikle tamamen sıfırdan karmaşık sorgular yazmaktan ziyade, belirli investigation mantıkları üzerinden ilerlemektedir.

Örneğin bir detection sonrasında analyst tarafında şu tarz sorular oluşabilmektedir:

• Bu endpoint üzerinde PowerShell çalışmış mı?
• Encoded command kullanılmış olabilir mi?
• Aynı kullanıcı başka suspicious process üretmiş mi?
• Şüpheli network connection oluşmuş mu?
• Belirli bir zaman aralığında ilgili activity var mı?

İşte CQL tam olarak bu sorulara cevap aramak için kullanılmaktadır.

Basitçe ifade etmek gerekirse, CQL; Falcon üzerinde oluşan endpoint telemetry verileri içerisinde arama, filtreleme ve investigation yapılmasını sağlayan sorgu dilidir.

Bir SOC analyst’i açısından bakıldığında CQL çoğu zaman yalnızca bir “query language” olarak görülmemektedir.

Özellikle detection investigation süreçlerinde:

• İlgili process’leri bulmak
• Şüpheli davranışları filtrelemek
• Timeline korelasyonu yapmak
• IOC araştırmalarını desteklemek
• Threat hunting süreçlerini ilerletmek

için kullanılan temel investigation araçlarından biri hâline gelmektedir.

İlk bakışta syntax tarafı biraz teknik görünebilir. Ancak CQL mantığı anlaşıldığında analyst tarafında investigation süreçlerini ciddi anlamda hızlandırabilmektedir.

Örneğin Falcon üzerinde yalnızca bir process activity görmek istediğimizi düşünelim.

Bu durumda analyst çoğu zaman ilgili event tipini filtreleyerek investigation’a başlamaktadır.

Örneğin aşağıdaki basit sorgu:

#event_simpleName=ProcessRollup2

Falcon üzerinde process execution event’lerini listelemeye yardımcı olmaktadır.

Burada önemli olan nokta, analyst’in her query syntax’ını ezberlemesi değildir.

Asıl kritik nokta çoğu zaman şudur:

“Hangi soruya cevap arıyorum ve bu cevabı hangi telemetry üzerinden bulabilirim?”

Deneyimli analyst’lerin Event Search tarafında yaklaşımı da çoğu zaman bu mantık üzerinden ilerlemektedir.

Bir PowerShell detection sonrasında analyst doğrudan:

• powershell.exe activity
• command line detayları
• parent-child process ilişkisi
• aynı zaman aralığındaki network event’leri

gibi alanları incelemeye başlayabilmektedir.

Bu nedenle CQL çoğu zaman yalnızca teknik bir sorgu dili değil, analyst tarafında investigation düşünce biçiminin bir parçası hâline gelmektedir.

Şekil 3: CrowdStrike Falcon üzerinde temel CQL çalışma mantığı, örnek sorgu yapısı ve analyst investigation süreçlerindeki kullanım alanları.

Analyst Perspektifinden İlk CQL Sorguları

CrowdStrike Falcon Event Search tarafında investigation süreçlerinin büyük bölümü, doğru telemetry verisini doğru filtreleme mantığı üzerine kurulmaktadır.

Her ne kadar CQL ilk bakışta teknik bir yapı gibi görünse de, analyst tarafında birçok investigation süreci çoğu zaman oldukça temel sorgular üzerinden başlamaktadır.

Özellikle bir detection sonrasında analyst’in ilk amacı genellikle geniş veri kümeleri içerisinde ilgili activity’yi izole etmek ve olayın bağlamını oluşturmaya başlamaktır.

Bu noktada Falcon üzerinde kullanılan birçok investigation süreci, belirli event tiplerini filtrelemek ve ilgili davranışları daraltmak üzerine ilerlemektedir.

Örneğin Falcon üzerinde oluşan process execution event’lerini görüntülemek istediğimizi düşünelim.

Bu durumda analyst tarafında sıklıkla kullanılan temel sorgulardan biri aşağıdaki gibidir:

#event_simpleName=ProcessRollup2

Bu sorgu, Falcon sensor tarafından üretilen process creation telemetry verilerini listelemeye yardımcı olmaktadır.

Başka bir ifadeyle, endpoint üzerinde gerçekleşen process aktivitelerinin Event Search tarafında görüntülenmesini sağlamaktadır.

Ancak investigation süreçleri çoğu zaman yalnızca process event’lerini listelemekle sınırlı kalmamaktadır.

Örneğin bir analyst’in belirli bir process activity üzerine odaklanmak istediğini düşünelim.

Bir PowerShell detection sonrasında yalnızca ilgili process aktivitelerini görüntülemek için sorgu daha spesifik hâle getirilebilmektedir:

#event_simpleName=ProcessRollup2
| ImageFileName=/powershell.exe/i

Bu yaklaşım, investigation sürecinde ilgili activity’nin daha hızlı izole edilmesine yardımcı olmaktadır.

Özellikle Falcon Event Search tarafında geniş telemetry kümeleri içerisinde çalışırken, belirli process’leri filtreleyebilmek investigation süresini ciddi ölçüde kısaltabilmektedir.

Benzer şekilde analyst tarafında sık karşılaşılan ihtiyaçlardan biri de, suspicious command line parametrelerini araştırmaktır.

Örneğin encoded PowerShell command’leri araştırmak için CommandLine alanı filtrelenebilmektedir:

CommandLine=/-enc/i

Bu tarz filtrelemeler, özellikle obfuscation veya encoded payload kullanımına yönelik ilk görünürlüğün elde edilmesinde faydalı olabilmektedir.

Burada dikkat edilmesi gereken önemli nokta, CQL kullanımında temel amacın karmaşık sorgular üretmek olmadığıdır.

Çoğu investigation sürecinde analyst tarafında asıl kritik konu:

Doğru telemetry alanını, doğru soru ile ilişkilendirebilmektir.

Bir process execution event’ini incelemek, belirli bir kullanıcı aktivitesini filtrelemek veya şüpheli network davranışlarını araştırmak çoğu zaman doğru temel sorgularla başlamaktadır.

Bu nedenle Falcon Event Search tarafında kullanılan basit query’ler, investigation sürecinin en önemli yapı taşlarından biri hâline gelmektedir.

Şekil 4: Falcon Event Search üzerinde analyst investigation süreçlerinde kullanılan temel CQL sorgularına örnekler.

Event Search Üzerinde Analyst’in İlk Baktığı Kritik Alanlar

CrowdStrike Falcon Event Search tarafında investigation süreçleri ilerledikçe analyst’in karşısına oldukça geniş telemetry verisi çıkmaktadır.

Bir detection sonrasında doğru bağlamı oluşturabilmek çoğu zaman yalnızca alert detaylarını incelemekle sınırlı kalmamaktadır. Özellikle process execution, command-line activity, user context ve ilişkili network davranışlarının birlikte değerlendirilmesi gerekmektedir.

Bu nedenle Falcon Event Search investigation süreçlerinde analyst tarafında öncelikli olarak belirli telemetry alanlarına odaklanılmaktadır.

Örneğin aşağıdaki detection ele alınsın:

‘Suspicious PowerShell Command Line’

Bu noktada analyst açısından investigation çoğu zaman yalnızca detection severity bilgisinin değerlendirilmesiyle ilerlememektedir.

Öncelikli amaç, ilgili activity’nin davranış bağlamını oluşturmaktır.

Bu süreçte genellikle aşağıdaki sorular cevaplanmaya çalışılmaktadır:

• Hangi process execution gerçekleşti?
• Command line içerisinde suspicious parametreler mevcut mu?
• İlgili activity hangi kullanıcı bağlamında oluştu?
• Process hangi parent process tarafından tetiklendi?
• İlişkili network activity mevcut mu?
• Timeline içerisinde benzer event’ler bulunuyor mu?

Falcon Event Search tarafında bu soruların cevabı çoğu zaman belirli telemetry alanları üzerinden elde edilmektedir.

Örneğin yalnızca process adının görüntülenmesi birçok durumda yeterli görünürlük sağlamamaktadır.

Aşağıdaki iki örnek değerlendirildiğinde aynı process farklı risk seviyelerinde yorumlanabilmektedir:

Normal kullanım örneği:

powershell.exe Get-Process

Daha dikkat gerektiren örnek:

powershell.exe -nop -w hidden -enc

İkinci örnekte analyst değerlendirmesi çoğu zaman aşağıdaki parametreler üzerinde yoğunlaşmaktadır:

• **-nop** → profil yüklenmeden execution
• **-w hidden** → hidden window execution
• **-enc** → encoded command kullanımı

Bu nedenle investigation süreçlerinde yalnızca process adı değil, process’in çalışma biçimi ve execution context’i birlikte değerlendirilmektedir.

Falcon Event Search tarafında analyst investigation süreçlerinde en sık incelenen telemetry alanları aşağıdaki gibidir:

Şekil 5: Falcon Event Search investigation süreçlerinde analyst tarafında en sık kullanılan kritik telemetry alanları ve investigation içindeki rolleri.

Investigation süreçlerinde bu alanlar çoğu zaman tek başına değerlendirilmemektedir.

Detection bağlamının oluşturulması, telemetry alanlarının birbiriyle ilişkilendirilmesi üzerinden ilerlemektedir.

event_simpleName: Investigation’ın Başlangıç Noktası

Falcon Event Search tarafında investigation süreçleri çoğu zaman event tipinin belirlenmesiyle başlamaktadır.

Çünkü analyst açısından ilk ihtiyaç, ilgili telemetry’nin hangi davranışı temsil ettiğini anlamaktır.

Bu noktada Falcon sensor tarafından üretilen her telemetry belirli bir event tipi altında kayıt altına alınmaktadır ve bu event tipi Event Search tarafında çoğu zaman event_simpleName alanı üzerinden görüntülenmektedir.

Başka bir ifadeyle:

***event_simpleName, Falcon üzerinde gerçekleşen davranışın hangi kategoriye ait olduğunu göstermektedir.***

Bir process execution activity ile network connection davranışının aynı investigation yaklaşımıyla değerlendirilmesi mümkün değildir.

Örneğin analyst bir PowerShell detection sonrasında doğrudan network event’lerini incelemek yerine çoğu zaman önce process execution telemetry’sine yönelmektedir.

Bu nedenle investigation sürecinde ilk filtreleme genellikle ilgili event tipi üzerinden yapılmaktadır.

Örneğin Falcon üzerinde process execution event’lerini görüntülemek için sıklıkla kullanılan yapı aşağıdaki gibidir:

#event_simpleName=ProcessRollup2

Bu event tipi Falcon tarafında process execution telemetry’sini temsil etmektedir.

Başka bir örnek ele alalım.

Bir analyst suspicious outbound connection şüphesi üzerinde çalışıyorsa, bu durumda investigation çoğu zaman network event’lerine yönelmektedir:

#event_simpleName=NetworkConnectIP4

Bu yaklaşım ilgili endpoint üzerinde oluşan network connection event’lerinin filtrelenmesine yardımcı olmaktadır.

Benzer şekilde analyst investigation süreçlerinde farklı amaçlarla farklı event tipleri kullanılabilmektedir.

Örneğin sık karşılaşılan bazı event tipleri aşağıdaki gibidir:

Şekil 6: Falcon Event Search üzerinde analyst tarafında sık kullanılan event_simpleName örnekleri ve investigation içindeki rolleri.

Burada kritik nokta çoğu zaman syntax değil, doğru event tipini seçebilmektir.

Çünkü yanlış telemetry alanı üzerinden ilerlemek investigation sürecinde analyst’i gereksiz veri içerisinde bırakabilmektedir.

Bu nedenle Falcon Event Search tarafında birçok analyst investigation’a önce şu soruyla başlamaktadır:

“İncelemek istediğim davranış hangi event tipi altında tutuluyor?”

Doğru event tipi belirlendiğinde, investigation süreci daha kontrollü ve anlamlı şekilde ilerlemeye başlamaktadır.

CommandLine: Bir Process’in Gerçekte Ne Yaptığını Anlamak

Falcon Event Search tarafında investigation süreçlerinde yalnızca process adını görmek çoğu zaman yeterli olmamaktadır.

Çünkü aynı executable, tamamen farklı amaçlarla çalıştırılabilmektedir.

Örneğin bir endpoint üzerinde powershell.exe çalıştığını görmek tek başına doğrudan suspicious bir activity anlamına gelmemektedir.

Birçok enterprise ortamında PowerShell;

• IT automation
• administrative task execution
• software deployment
• maintenance operations

için yoğun şekilde kullanılabilmektedir.

Bu nedenle analyst tarafında çoğu investigation süreci yalnızca process adına değil, ilgili process’in hangi parametrelerle çalıştırıldığına odaklanmaktadır.

Bu noktada Falcon Event Search üzerinde en kritik telemetry alanlarından biri **CommandLine** olmaktadır.

Çünkü **CommandLine, ilgili process’in gerçekte ne yapmaya çalıştığını** anlamaya yardımcı olan en önemli bağlam alanlarından biridir.

Örneğin aşağıdaki kullanım birçok ortamda normal kabul edilebilir:

powershell.exe Get-Process

Bu activity temel bir administrative usage örneği olarak değerlendirilebilir.

Ancak aşağıdaki örnek analyst açısından daha dikkat gerektirebilmektedir:

powershell.exe -nop -w hidden -enc

İkinci örnekte analyst değerlendirmesi çoğu zaman command-line parametreleri üzerinde yoğunlaşmaktadır.

Özellikle aşağıdaki parametreler investigation sırasında dikkat çekebilmektedir:

Şekil 7: Falcon Event Search üzerinde CommandLine alanı üzerinden suspicious PowerShell activity investigation örnekleri.

Bu parametrelerin tek başına malicious activity anlamına geldiğini söylemek her zaman doğru olmayacaktır.

Ancak özellikle:

• obfuscation
• hidden execution
• encoded payload
• execution bypass
• download cradle pattern’leri

birlikte görüldüğünde analyst tarafında daha derin investigation ihtiyacı doğabilmektedir.

Örneğin Falcon Event Search üzerinde encoded PowerShell activity araştırmak için analyst tarafında aşağıdaki gibi filtrelemeler kullanılabilmektedir:

CommandLine=/-enc/i

Benzer şekilde hidden execution araştırmaları için:

CommandLine=/-w hidden/i

Bu tarz filtrelemeler özellikle detection sonrasında hızlı triage süreçlerinde analyst’e ilk görünürlüğü sağlamaktadır.

Burada kritik nokta çoğu zaman yalnızca suspicious keyword aramak değildir.

Asıl önemli olan, command line davranışını endpoint bağlamı içerisinde değerlendirebilmektir.

Çünkü birçok ortamda aynı parametreler tamamen meşru administrative kullanımın da parçası olabilmektedir.

Bu nedenle analyst tarafında CommandLine incelemeleri çoğu zaman:

process context + user context + timeline correlation

birlikte değerlendirilerek ilerlemektedir.

ParentBaseFileName: Process’i Kim Tetikledi?

Falcon Event Search tarafında yalnızca process execution activity’nin görüntülenmesi çoğu zaman yeterli görünürlük sağlamamaktadır.

Bir process’in hangi executable tarafından tetiklendiği, investigation sürecinde çoğu zaman process’in kendisi kadar kritik olabilmektedir.

Bu noktada analyst tarafında sık incelenen telemetry alanlarından biri **ParentBaseFileName** olmaktadır.

Çünkü birçok activity tek başına değerlendirildiğinde normal görünse de, execution chain incelendiğinde farklı bir anlam kazanabilmektedir.

Örneğin aşağıdaki execution chain birçok ortamda beklenen kullanıcı davranışı olarak değerlendirilebilir:

explorer.exe ↓ chrome.exe

Kullanıcının browser açması beklenen bir davranıştır.

Benzer şekilde:

services.exe ↓ svchost.exe

Windows servis mimarisinin doğal bir parçası olabilir.

Ancak bazı parent-child ilişkiler analyst açısından daha dikkat gerektirebilmektedir.

Örneğin:

winword.exe ↓ cmd.exe

Office process’lerinden command shell execution görülmesi, özellikle macro execution veya malicious document activity açısından değerlendirme gerektirebilmektedir.

Benzer şekilde:

excel.exe ↓ powershell.exe

Office process üzerinden PowerShell execution görülmesi analyst tarafında çoğu zaman phishing attachment, macro-based execution veya payload delivery şüphesi doğurabilmektedir.

Bir başka örnek:

wscript.exe ↓ mshta.exe

Bu zincir özellikle:

• LOLBIN usage
• script-based execution
• malicious HTA execution
• payload staging

senaryolarında görülebilmektedir.

Benzer şekilde aşağıdaki ilişki de investigation gerektirebilir:

outlook.exe ↓ rundll32.exe

Email client üzerinden DLL execution görülmesi analyst açısından ek inceleme gerektirebilir.

Falcon Event Search tarafında analyst’ler bu tarz davranışları değerlendirirken çoğu zaman yalnızca process adına değil:

• parent-child relationship
• command-line behavior
• execution timing
• user context
• network activity

alanlarını birlikte değerlendirmektedir.

Çünkü suspicious davranış çoğu zaman process isminden değil, alışılmadık execution chain’lerinden anlaşılmaktadır.

Bu nedenle ParentBaseFileName, Falcon Event Search investigation süreçlerinde analyst açısından en kritik bağlam alanlarından biri hâline gelmektedir.

Normal bir process, anormal bir parent process ile tamamen farklı anlam kazanabilir.

Şekil 8: Falcon Event Search üzerinde ParentBaseFileName alanı üzerinden parent-child process relationship investigation örnekleri.

UserName ve HostName: Activity’nin Bağlamını Oluşturmak

Falcon Event Search tarafında aynı activity, farklı kullanıcı ve endpoint bağlamlarında tamamen farklı şekilde değerlendirilebilmektedir.

Bu nedenle investigation süreçlerinde yalnızca process execution veya command-line davranışının incelenmesi çoğu zaman yeterli görünürlük sağlamamaktadır. Özellikle suspicious bir activity’nin hangi kullanıcı bağlamında gerçekleştiği ve hangi endpoint üzerinde oluştuğu, analyst değerlendirmesinin yönünü doğrudan değiştirebilmektedir.

Bu noktada Falcon Event Search investigation süreçlerinde sık incelenen telemetry alanlarından ikisi **UserName ve `HostName`** olmaktadır.

Örneğin aşağıdaki activity ele alınsın:

powershell.exe -ExecutionPolicy Bypass

Bu activity tek başına değerlendirildiğinde analyst açısından belirli seviyede dikkat gerektirebilir. Ancak gerçek investigation süreçlerinde karar çoğu zaman yalnızca command-line üzerinden verilmemektedir.

Aynı activity;

UserName: IT-ADMIN HostName: SCCM-SERVER-01

bağlamında değerlendirildiğinde, software deployment, maintenance veya administrative task execution süreçlerinin bir parçası olabilir.

Ancak benzer davranışın aşağıdaki gibi bir bağlam içerisinde görülmesi analyst değerlendirmesini değiştirebilmektedir:

UserName: FINANCE-USER HostName: FINANCE-PC-22

Özellikle ayrıcalıklı olmayan kullanıcı hesaplarında görülen execution bypass davranışları, analyst tarafında ek investigation ihtiyacını doğurabilmektedir.

Benzer şekilde activity’nin gerçekleştiği endpoint tipi de önem taşımaktadır.

Çünkü aynı davranış:

• standart workstation
• jump server
• critical business system
• domain controller

üzerinde farklı risk seviyelerinde yorumlanabilmektedir.

Örneğin kritik altyapı sistemlerinde gerçekleşen suspicious process execution davranışları çoğu zaman daha yüksek öncelikle ele alınmaktadır.

Bu nedenle Falcon Event Search investigation süreçlerinde analyst değerlendirmesi yalnızca:

“Ne çalıştı?”

sorusuna değil, aynı zamanda:

“Kim çalıştırdı ve nerede gerçekleşti?”

sorularına da cevap aramaktadır.

Birçok false positive senaryosunda davranışın kendisinden çok, eksik bağlam yanlış değerlendirmeye neden olabilmektedir.

Bu nedenle UserName ve HostName alanları, Falcon Event Search investigation süreçlerinde activity’nin operasyonel bağlamını oluşturan temel telemetry alanları arasında yer almaktadır.

Şekil 9: Falcon Event Search üzerinde UserName ve HostName context’i üzerinden analyst investigation örnekleri.

@timestamp ve Timeline Correlation: Olay Zincirini Oluşturmak

Falcon Event Search investigation süreçlerinde tek bir telemetry event’ini izole şekilde değerlendirmek çoğu zaman yeterli bağlam sağlamamaktadır.

Özellikle suspicious activity içeren olaylarda analyst tarafında asıl amaç, davranışın hangi sırayla gerçekleştiğini ve ilişkili event’lerin birbirini nasıl takip ettiğini anlayabilmektir.

Bu noktada Falcon Event Search üzerinde kritik rol oynayan alanlardan biri **@timestamp** olmaktadır.

Çünkü investigation süreçlerinde birçok activity tek başına anlamlı görünmese de, zaman ilişkisi kurulduğunda olayın bağlamı daha net ortaya çıkabilmektedir.

Örneğin analyst tarafında suspicious bir Office document execution investigation’ı ele alınsın.

Tek başına aşağıdaki activity yeterli görünürlük sağlamayabilir:

powershell.exe

Ancak timeline üzerinden ilişkili event’ler incelendiğinde olay zinciri daha anlamlı hâle gelebilmektedir.

Örneğin aşağıdaki sıralama değerlendirildiğinde:

09:14:02 winword.exe açıldı 09:14:11 powershell.exe execution 09:14:18 outbound network connection 09:14:26 temp file creation 09:14:39 suspicious child process

activity’nin yalnızca tek bir PowerShell execution’dan ibaret olmadığı anlaşılabilmektedir.

Bu noktada analyst değerlendirmesi çoğu zaman şu sorular üzerinden ilerlemektedir:

• İlk tetiklenen activity neydi?
• Suspicious davranış ne zaman başladı?
• Hangi event diğerini tetikledi?
• İlişkili network activity mevcut mu?
• Persistence veya payload execution davranışı oluştu mu?

Özellikle phishing, malicious document activity veya payload delivery senaryolarında timeline correlation analyst açısından kritik önem taşımaktadır.

Çünkü saldırı davranışları çoğu zaman tek bir telemetry event’i şeklinde değil, ardışık execution zincirleri şeklinde ortaya çıkmaktadır.

Falcon Event Search tarafında analyst’ler çoğu zaman investigation sırasında belirli zaman aralıklarını daraltarak olayın gelişimini incelemektedir.

Örneğin suspicious activity sonrasında aynı endpoint üzerinde oluşan ilişkili event’leri görmek için zaman filtresi kullanılabilmektedir:

#event_simpleName=ProcessRollup2
| @timestamp: [now-30m TO now]

Bu yaklaşım, özellikle yüksek telemetry yoğunluğuna sahip ortamlarda investigation sürecinin daha kontrollü ilerletilmesine yardımcı olmaktadır.

Başka bir ifadeyle:

Bir event’in kendisi kadar, ne zaman gerçekleştiği ve hangi event’lerle ilişkili olduğu da önemlidir.

Bu nedenle @timestamp alanı, Falcon Event Search investigation süreçlerinde analyst’in olay akışını yeniden oluşturmasına yardımcı olan temel telemetry alanlarından biri hâline gelmektedir.

Şekil 10: Falcon Event Search üzerinde @timestamp kullanılarak timeline correlation ve analyst investigation akışı örneği.

Detection’dan Investigation’a: Mini Bir SOC Analyst Senaryosu

Falcon Event Search investigation süreçleri çoğu zaman tek bir detection ile başlamaktadır.

Ancak analyst açısından asıl amaç, oluşan detection’ın gerçekten malicious bir davranışa mı işaret ettiği yoksa beklenen bir activity mi olduğunu anlayabilmektir.

Bu noktada örnek bir senaryo üzerinden analyst investigation yaklaşımını değerlendirelim.

Falcon üzerinde aşağıdaki detection’ın oluştuğunu düşünelim:

‘Suspicious Rundll32 Execution’

rundll32.exe, Windows işletim sisteminin doğal bileşenlerinden biri olmasına rağmen, saldırganlar tarafından sıklıkla LOLBIN (Living-off-the-Land Binary) amacıyla kullanılabilmektedir.

Bu nedenle analyst tarafında investigation çoğu zaman execution context üzerinden ilerlemektedir.

İlk aşamada analyst ilgili process activity’sini filtrelemektedir:

#event_simpleName=ProcessRollup2
| ImageFileName=/rundll32.exe/i

Bu aşamada analyst tarafında öncelikli olarak aşağıdaki telemetry alanları incelenmektedir:

• CommandLine
• ParentBaseFileName
• UserName
• HostName
• @timestamp

Örneğin aşağıdaki command-line dikkat çekici olabilir:

rundll32.exe javascript:”\..\mshtml,RunHTMLApplication”

Bu tarz kullanım analyst açısından normal administrative execution’dan farklı değerlendirilebilmektedir.

Bir sonraki aşamada analyst parent-child ilişkiyi incelemektedir.

Örneğin aşağıdaki execution chain görülsün:

outlook.exe ↓ rundll32.exe

Bu noktada investigation çoğu zaman email kaynaklı execution ihtimali üzerine yoğunlaşmaktadır.

Timeline correlation tarafında aşağıdaki zincir görülebilir:

10:21 Outlook attachment opened 10:22 rundll32.exe execution 10:22 outbound network connection 10:23 temp directory file creation

Bu tarz ilişkili event’ler analyst açısından activity’nin izole bir process execution olmadığını gösterebilmektedir.

Özellikle:

• email client execution
• LOLBIN usage
• network communication
• temp file activity

birlikte değerlendirildiğinde malicious execution ihtimali güçlenebilmektedir.

Bu noktada analyst tarafında karar çoğu zaman telemetry correlation üzerinden verilmektedir.

İyi bir investigation çoğu zaman tek bir alert’i okumaktan değil, ilişkili event’leri anlamlandırmaktan geçmektedir.

Şekil 11: Falcon Event Search üzerinde suspicious rundll32.exe activity’si üzerinden analyst investigation workflow örneği.

Sonuç

CrowdStrike Falcon Event Search, analyst tarafında çoğu zaman yalnızca bir log arama ekranı olarak değerlendirilmemektedir.

Özellikle detection investigation süreçlerinde Falcon’un sağladığı telemetry görünürlüğü, analyst’in olay bağlamını oluşturabilmesi açısından kritik rol oynamaktadır.

Bir detection’ın severity değeri veya kısa açıklaması ilk değerlendirme için önemli olsa da, gerçek investigation çoğu zaman Event Search tarafında derinleşmektedir.

Bu süreçte analyst değerlendirmesi yalnızca:

• hangi process’in çalıştığına
• hangi command-line parametrelerinin kullanıldığına
• hangi kullanıcı bağlamında gerçekleştiğine
• hangi endpoint üzerinde oluştuğuna

bakılarak ilerlememektedir.

Çoğu olayda doğru karar, telemetry alanlarının birlikte değerlendirilmesi ve activity zincirinin anlamlandırılmasıyla ortaya çıkmaktadır.

Özellikle:

• event type correlation
• command-line analysis
• parent-child relationship
• user & host context
• timeline investigation

yaklaşımları, Falcon Event Search tarafında analyst’in daha kontrollü ve bağlam odaklı investigation yürütmesine yardımcı olmaktadır.

Birçok false positive senaryosu yalnızca eksik bağlam nedeniyle yanlış değerlendirilebilmekte, benzer şekilde bazı malicious activity’ler de yüzeysel incelemeler nedeniyle gözden kaçabilmektedir.

Bu nedenle Falcon Event Search investigation süreçlerinde asıl yaklaşım çoğu zaman şu olmaktadır:

Bir alert’i okumaktan çok, activity’nin hikâyesini oluşturmaya çalışmak.

Çünkü iyi bir investigation çoğu zaman tek bir telemetry event’ine değil, ilişkili davranışların bütününe bakmayı gerektirmektedir.