<![CDATA[TurkTeam | Türk Siber Güvenlik Topluluğu

<![CDATA[TurkTeam | Türk Siber Güvenlik Topluluğu - Adli Bilişim (Forensics)]]> https://www.turkteam.org/ Sun, 25 Oct 2026 18:48:37 +0000 MyBB <![CDATA[Velociraptor Quickstart: Self-Signed Labda DFIR Sunucu ve Windows Client]]> https://www.turkteam.org/konu-velociraptor-quickstart-self-signed-labda-dfir-sunucu-ve-windows-client.html Wed, 21 Oct 2026 11:27:19 +0300 BilgeKagan]]> https://www.turkteam.org/konu-velociraptor-quickstart-self-signed-labda-dfir-sunucu-ve-windows-client.html [Resim: attachment.php?aid=330]

Selam,

Velociraptor, uç noktalardan hızlı DFIR telemetrisi toplamak için güçlü bir araç. Resmi quickstart self-signed SSL + Basic auth ile kısa süreli lab/IR kurulumu anlatıyor. Üretimde SSO önerilir; bu yazı değerlendirme labı içindir.

Mimari varsayımlar (quickstart)

Linux sunucu (Ubuntu + systemd tercih)
Client port 8000, GUI 8889
Aynı lab ağında, NAT karmaşası yok
GUI'yi internete açmayın (Basic auth brute-force'a açık)

Sunucu iskeleti

Kod:
mkdir ~/velociraptor_setup && cd ~/velociraptor_setup
wget -O velociraptor https://github.com/Velocidex/velociraptor/releases/download/v0.75/velociraptor-v0.75.6-linux-amd64
chmod +x velociraptor
./velociraptor config generate -i
# Self Signed SSL seçin; admin kullanıcı ekleyin
# Frontend/GUI bind_address lab ihtiyacına göre 0.0.0.0
./velociraptor debian server --config ./server.config.yaml
sudo dpkg -i velociraptor_server_*.deb
sudo systemctl status velociraptor_server.service

GUI: https://127.0.0.1:8889 — sertifika uyarısı normal (self-signed).

Windows client MSI
GUI'den Server Artifacts -> Server.Utils.CreateMSI çalıştırın; resmi MSI indirilip sizin client config ile repack edilir. Uploaded Files'tan alın, lab Windows'a kurun (yönetici). Servis adıyla "Velociraptor" görünür; sunucuda Search clients ile kaydı doğrulayın.

İlk artifact
Welcome ekranından Import Extra Artifacts (Sigma, Exchange, Registry Hunter vb.) ile topluluğu zenginleştirin. Sonra tek bir Windows client'ta düşük riskli bir collection (ör. ağ bağlantı listesi) çalıştırıp akışı öğrenin.

Yasal uyarı
Endpoint ajanı kurmak sahiplik/izin ister. Gizlice izleme suçtur. TCK 243-245 ve KVKK'ya dikkat.

Kaynaklar

IR'de kullanım
Hızlı triyaj artifact'leri (process, netstat, prefretch benzeri) ile başlayın; tüm disk imajı her zaman ilk adım olmak zorunda değil. Self-signed labı prod'a taşımayın; SSO ve sertifika planını ayrı proje yapın.

Uygulamada sık gördüğüm hatalar
Birçok ekip yamayı "planlandı" diye işaretleyip internete açık yüzeyde günlerce bekletiyor. İkinci sık hata: yalnızca CVE numarasına bakıp zincir etkisini görmemek. Üçüncü hata: yama sonrası log ve dosya bütünlüğüne bakmamak; oysa yama öncesi sömürü olmuş olabilir. Bu üç noktayı kendi kontrol listenize eklemenizi öneririm.

Ekip içi iletişim şablonu
Yönetime veya müşteriye yazarken teknik jargonu azaltın: hangi varlık etkilendi, internete açık mı, yama var mı, geçici azaltma ne, doğrulama nasıl yapılacak. Tek paragrafta risk + eylem + sahiplik yazmak, uzun CVE özetinden daha hızlı karar aldırır.

Lab not defteri
Bu konuyu kendi defterime şu başlıklarla işliyorum: tarih, kaynak URL, etkilenen ürün/sürüm, internete açık mı, yama komutu, geri alma planı, IOC listesi, kime haber verildi. Siz de benzer basit bir şablon tutarsanız bir ay sonra "ne yapmıştık?" sorusu cevapsız kalmaz.

İzleme ve doğrulama
Değişiklikten sonra en az bir negatif ve bir pozitif kontrol tanımlayın. Negatif: alarm boş yere düşmemeli. Pozitif: bilinen kötü örneği veya beklenen log satırını yakalamalı. İkisini de kaydedin; aksi halde "sanırım düzeldi" ile yetinirsiniz.

Sonuç
Özetle: kaynağı okuyun, kendi envanterinize bağlayın, yama veya azaltmayı uygulayın, sonra doğrulayın. TurkTeam'de yorumlarda kendi ortamınızdan (ürün adı ve sürüm yeter, hassas IP yazmayın) kısa deneyim paylaşırsanız herkes faydalanır.

Adım adım kontrol listesi (kopyala-yapıştır)

Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).
Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.
İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.
Yama veya yapılandırma azaltmasını stagingde deneyin.
Üretim penceresinde uygulayın; değişiklik kaydı açın.
Servis sağlık kontrolü + log doğrulaması yapın.
Gerekliyse IOC avı veya compromise assessment planlayın.
Kapanış notunu yazın: sürüm, tarih, kim onayladı.

Sık sorulanlar
Sadece okumak yeter mi? Hayır. Okuduktan sonra envanter satırına bağlanmayan bilgi operasyonel değildir.
PoC çalıştırmalı mıyım? Yalnızca izole lab ve yazılı izinle. İnternette rastgele deneme hem etik dışı hem yasadışı olabilir.
WAF / EDR tek başına kurtarır mı? Katmanlı savunma işe yarar ama yamanın yerini tutmaz; özellikle kimlik doğrulamasız RCE sınıflarında.
Ne zaman yönetime çıkmalıyım? İnternete açık kritik yüzey, aktif sömürü istihbaratı veya veri sızıntısı şüphesi varsa gecikmeden.

Örnek komut defteri

Kod:
# Tarih damgası ve ortam notu
date -Is
hostnamectl 2>/dev/null | head -5 || true
# Ağ dinleme özeti (lab)
ss -lntp | head -30
# Son reboot / güncelleme ipucu (systemd)
who -b 2>/dev/null || true

Bu komutlar tanı koymaz; değişiklik öncesi/sonrası basline almak için kullanın.

İlgili TurkTeam bölümleri
Bu yazıyı okuduktan sonra aynı kategorideki komşu konulara ve Soru-Cevap bölümüne kendi lab çıktınızı (hassas veri olmadan) taşıyabilirsiniz. Kısa ekran görüntüsü veya komut çıktısı, uzun teoriden daha çok işe yarar.

Kapanış ve yasal çerçeve
TurkTeam white-hat bir topluluktur. Anlatılan teknikler eğitim, savunma ve izinli test içindir. Başkalarının sistemlerinde izinsiz tarama, sömürü, veri çalma veya "hack hizmeti" sunmak forum kurallarına ve TCK 243, 244, 245 maddelerine aykırıdır. Kendi laboratuvarınızı izolasyonla kurun; üretim verisi kullanmayın. Kaynaklardaki bağlantıları birincil referans kabul edin; bu yazı özet ve yol göstericidir, üretici duyurusunun yerini tutmaz.

Kişisel deneyim notu
Ben benzer konuları işlerken önce resmi duyuruyu iki kez okuyup sonra labda en küçük yeniden üretilebilir adımı arıyorum. Yeniden üretemiyorsam bile envanter ve yama doğrulamasını aynı gün bitirmeye çalışıyorum. Siz de "bugün tek iş" diye bir satır seçin: ya yamayı uygulayın ya da etkilenen varlık olmadığını kanıtlayın. İkisi de geçerli kapanıştır.

Okuma listesi

Üretici / araştırmacı birincil yazısı (kaynakçada)
CISA KEV veya CERT duyurusu varsa o
Kendi iç runbook'unuzun ilgili maddesi

Üçünden fazlasını aynı anda açmak yerine birini bitirip not alın; aksi halde tab kaybı başlar.

.png

13-b03-velo.png (Dosya Boyutu: 113.74 KB / İndirme Sayısı: 10) ]]> [Resim: attachment.php?aid=330]

Linux sunucu (Ubuntu + systemd tercih)
Client port 8000, GUI 8889
Aynı lab ağında, NAT karmaşası yok
GUI'yi internete açmayın (Basic auth brute-force'a açık)

Sunucu iskeleti

Kod:
mkdir ~/velociraptor_setup && cd ~/velociraptor_setup
wget -O velociraptor https://github.com/Velocidex/velociraptor/releases/download/v0.75/velociraptor-v0.75.6-linux-amd64
chmod +x velociraptor
./velociraptor config generate -i
# Self Signed SSL seçin; admin kullanıcı ekleyin
# Frontend/GUI bind_address lab ihtiyacına göre 0.0.0.0
./velociraptor debian server --config ./server.config.yaml
sudo dpkg -i velociraptor_server_*.deb
sudo systemctl status velociraptor_server.service

Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).
Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.
İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.
Yama veya yapılandırma azaltmasını stagingde deneyin.
Üretim penceresinde uygulayın; değişiklik kaydı açın.
Servis sağlık kontrolü + log doğrulaması yapın.
Gerekliyse IOC avı veya compromise assessment planlayın.
Kapanış notunu yazın: sürüm, tarih, kim onayladı.

Kod:
# Tarih damgası ve ortam notu
date -Is
hostnamectl 2>/dev/null | head -5 || true
# Ağ dinleme özeti (lab)
ss -lntp | head -30
# Son reboot / güncelleme ipucu (systemd)
who -b 2>/dev/null || true

Üretici / araştırmacı birincil yazısı (kaynakçada)
CISA KEV veya CERT duyurusu varsa o
Kendi iç runbook'unuzun ilgili maddesi

Üçünden fazlasını aynı anda açmak yerine birini bitirip not alın; aksi halde tab kaybı başlar.

.png

13-b03-velo.png (Dosya Boyutu: 113.74 KB / İndirme Sayısı: 10) ]]> <![CDATA[Disk İmajı Alma: dd, dc3dd, Hash Doğrulama ve Zincir of Custody Notları]]> https://www.turkteam.org/konu-disk-imaji-alma-dd-dc3dd-hash-dogrulama-ve-zincir-of-custody-notlari.html Mon, 19 Oct 2026 00:23:57 +0300 KulTigin]]> https://www.turkteam.org/konu-disk-imaji-alma-dd-dc3dd-hash-dogrulama-ve-zincir-of-custody-notlari.html [Resim: attachment.php?aid=263]

Selam,

Adli bilişimde her şey imajla başlar. Yanlış alınan bir imaj, üzerine kurduğunuz tüm analizi zayıflatır. Bu yazıda Linux'ta dd ve dc3dd ile disk imajı alma, hash doğrulama ve basit zincir of custody (delil zinciri) notlarını paylaşıyorum. Senaryo: kendi lab diskim /dev/sdb (USB bellek).

Neden ham imaj?
Canlı diskte gezinmek delili değiştirir (atime vb.). Salt okunur bağlama ve bit-bit kopya (forensic image) standarttır. Hedef: kaynak ile imajın hash'inin aynı olması.

Hazırlık

Mümkünse donanım yazma engelleyici (write blocker) kullanın.
Yoksa kerneli salt okunur bağlayın:

Kod:
sudo hdparm -r1 /dev/sdb
# veya bind mount / blok cihazı RO
sudo blockdev --setro /dev/sdb

Cihaz adını doğrulayın; yanlış disk üzerine yazmak felakettir:

Kod:
lsblk -o NAME,SIZE,MODEL,SERIAL,MOUNTPOINT

Klasik dd

Kod:
sudo dd if=/dev/sdb of=/mnt/evidence/case01.dd bs=4M status=progress conv=sync,noerror

bs=4M: blok boyutu; çok küçük yavaşlatır.
conv=noerror: okuma hatalarında durma, devam et (kötü sektörler).
status=progress: ilerleme (GNU dd).

Bitince:

Kod:
sync
sha256sum /dev/sdb /mnt/evidence/case01.dd | tee /mnt/evidence/case01.sha256

dc3dd: adli bilişim için geliştirilmiş dd
dc3dd hash'i işin içine gömer, log üretir:

Kod:
sudo dc3dd if=/dev/sdb of=/mnt/evidence/case01.dc3dd hash=sha256 log=/mnt/evidence/case01.log

Logda başlangıç/bitiş zamanı, hash ve hata sayıları yer alır. Mahkeme veya kurum içi incelemede bu log hayat kurtarır.

Alternatif modern araç: dcfldd veya ewf-tools (E01 formatı). Kurumsal tarafta çoğu laboratuvar E01/AFF tercih eder; ham dd eğitim ve hızlı lab için yeterlidir.

Hash disiplini

Kaynak ve imaj hash'i birebir aynı olmalı.
Hash algoritması: en az SHA-256 (MD5 tek başına artık yeterli sayılmaz).
Hash dosyasını imajla birlikte, ayrı bir kanıt notuna yazın.
Sonradan imajı kopyalarsanız yeni kopyanın hash'ini de alın; orijinal hash değişmez.

Kod:
sha256sum -c case01.sha256

Zincir of custody (basit şablon)
Her teslimatta kim, ne zaman, neden aldı yazılmalı. Minimal alanlar:

Dava / olay no
Cihaz seri no, model
İmaj dosya adı, boyutu, SHA-256
Alım tarihi (Europe/Istanbul), alan kişi
Saklama yeri (şifreli disk, erişim listesi)

Örnek satır:

Kod:
2026-10-17 14:05 TRT | Ahmet Y. | /dev/sdb -> case01.dc3dd | SHA256=abc... | Lab-Kasa-2

İmajı bağlamak (analiz için)

Kod:
sudo losetup -fP --show /mnt/evidence/case01.dd
sudo mkdir -p /mnt/img
sudo mount -o ro,noexec,noload /dev/loop0p1 /mnt/img

Her zaman ro. Analiz bitince:

Kod:
sudo umount /mnt/img
sudo losetup -d /dev/loop0

Sık hatalar

if/of karıştırmak (hedef diski siler)
Hash almadan kopyayı dağıtmak
İmajı RW bağlamak
Canlı sistemde "temizlik" yapıp sonra imaj almak (çok geç)

Kaynaklar

NIST SP 800-86 (Guide to Integrating Forensic Techniques)
dc3dd / dd man sayfaları
SANS Forensics white paper'ları

Siz E01 mi yoksa ham dd mi tercih ediyorsunuz? Küçük lablar için deneyimlerinizi merak ediyorum.

Canlı sistemden toplama sırası
Disk imajı almadan önce (politika izin veriyorsa) uçucu kanıt: bellek (dumpit/winpmem/lime), ağ bağlantıları, oturum listesi. Klasik sıra: bellek -> ağ durumu -> disk. Tersi yapılırsa bellek içeriği değişir. Linux'ta LiME ile bellek, ardından disk dd. Her adımın hash ve zamanını deftere yazın.

Bulut diskleri
AWS EBS snapshot / Azure disk snapshot adli süreçte sık kullanılır. Snapshot'tan yeni volume yaratıp salt okunur bağlamak, çalışan instance'ı kapatmadan kanıt almayı sağlar. Snapshot ID, bölge ve IAM yetkisini zincir of custody'ye ekleyin.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.

.png

100-n05-f55cc3.png (Dosya Boyutu: 67.66 KB / İndirme Sayısı: 7)

.png

n05-inner.png (Dosya Boyutu: 22.7 KB / İndirme Sayısı: 7) ]]> [Resim: attachment.php?aid=263]

Mümkünse donanım yazma engelleyici (write blocker) kullanın.
Yoksa kerneli salt okunur bağlayın:

Kod:
sudo hdparm -r1 /dev/sdb
# veya bind mount / blok cihazı RO
sudo blockdev --setro /dev/sdb

Cihaz adını doğrulayın; yanlış disk üzerine yazmak felakettir:

Kod:
lsblk -o NAME,SIZE,MODEL,SERIAL,MOUNTPOINT

Klasik dd

Kod:
sudo dd if=/dev/sdb of=/mnt/evidence/case01.dd bs=4M status=progress conv=sync,noerror

bs=4M: blok boyutu; çok küçük yavaşlatır.
conv=noerror: okuma hatalarında durma, devam et (kötü sektörler).
status=progress: ilerleme (GNU dd).

Bitince:

Kod:
sync
sha256sum /dev/sdb /mnt/evidence/case01.dd | tee /mnt/evidence/case01.sha256

dc3dd: adli bilişim için geliştirilmiş dd
dc3dd hash'i işin içine gömer, log üretir:

Kod:
sudo dc3dd if=/dev/sdb of=/mnt/evidence/case01.dc3dd hash=sha256 log=/mnt/evidence/case01.log

Kaynak ve imaj hash'i birebir aynı olmalı.
Hash algoritması: en az SHA-256 (MD5 tek başına artık yeterli sayılmaz).
Hash dosyasını imajla birlikte, ayrı bir kanıt notuna yazın.
Sonradan imajı kopyalarsanız yeni kopyanın hash'ini de alın; orijinal hash değişmez.

Kod:
sha256sum -c case01.sha256

Zincir of custody (basit şablon)
Her teslimatta kim, ne zaman, neden aldı yazılmalı. Minimal alanlar:

Dava / olay no
Cihaz seri no, model
İmaj dosya adı, boyutu, SHA-256
Alım tarihi (Europe/Istanbul), alan kişi
Saklama yeri (şifreli disk, erişim listesi)

Örnek satır:

Kod:
2026-10-17 14:05 TRT | Ahmet Y. | /dev/sdb -> case01.dc3dd | SHA256=abc... | Lab-Kasa-2

İmajı bağlamak (analiz için)

Kod:
sudo losetup -fP --show /mnt/evidence/case01.dd
sudo mkdir -p /mnt/img
sudo mount -o ro,noexec,noload /dev/loop0p1 /mnt/img

Her zaman ro. Analiz bitince:

Kod:
sudo umount /mnt/img
sudo losetup -d /dev/loop0

Sık hatalar

if/of karıştırmak (hedef diski siler)
Hash almadan kopyayı dağıtmak
İmajı RW bağlamak
Canlı sistemde "temizlik" yapıp sonra imaj almak (çok geç)

Kaynaklar

NIST SP 800-86 (Guide to Integrating Forensic Techniques)
dc3dd / dd man sayfaları
SANS Forensics white paper'ları

100-n05-f55cc3.png (Dosya Boyutu: 67.66 KB / İndirme Sayısı: 7)

.png

n05-inner.png (Dosya Boyutu: 22.7 KB / İndirme Sayısı: 7) ]]> <![CDATA[Volatility 3 ile Bellek Adli Bilişimi: İlk Analiz Adımları]]> https://www.turkteam.org/konu-volatility-3-ile-bellek-adli-bilisimi-ilk-analiz-adimlari.html Fri, 16 Oct 2026 11:19:50 +0300 Tonyukuk]]> https://www.turkteam.org/konu-volatility-3-ile-bellek-adli-bilisimi-ilk-analiz-adimlari.html [Resim: attachment.php?aid=32]

Volatility 3 ile Bellek Adli Bilişimine Giriş

Selamlar,

Disk imajı her şeyi anlatmaz; bellek (RAM) çalışan süreçleri, ağ bağlantılarını ve bazen şifre çözülmüş verileri taşır. Volatility 3'ün v2.28.2 sürümü (Eylül 2026) ile kendi lab bellek dökümünüzü nasıl analiz edeceğinizi özetliyoruz.

Konuda Anlatılacaklar

Kurulum
Lab bellek dökümü alma
İlk eklentiler: pslist, netstat, cmdline
Şüpheli süreç avı
Kaynakça

1) Kurulum

Kod:
python3 -m venv volenv && source volenv/bin/activate
pip install volatility3==2.28.2
vol -h
# veya: python3 -m volatility3 -h

2) Lab Dökümü
Kendi VM'inizde (örnek):

Linux: /proc/kcore veya LiME gibi lab araçları (dokümantasyonuna uyun)
Windows lab: WinPmem / DumpIt gibi araçlarla ham bellek

Dökümü yalnızca sahip olduğunuz lab VM'sinden alın.

3) İlk Komutlar

Kod:
# Windows bellek dökümü örneği
vol -f lab.raw windows.info
vol -f lab.raw windows.pslist
vol -f lab.raw windows.pstree
vol -f lab.raw windows.netstat
vol -f lab.raw windows.cmdline
# Linux dökümü örneği
vol -f lab.raw linux.pslist
vol -f lab.raw linux.bash

4) Nelere Dikkat?

Ebeveyni olmayan veya garip yoldan çalışan süreçler
powershell/cmd üzerinden şüpheli uzun komut satırları
Dinleyen ama meşru olmayan portlar
pslist'te görünüp pstree'de kopuk kalan süreçler

5) Zincir

Kod:
vol -f lab.raw windows.pslist --output-file pslist.csv --output csv
# Sonra cmdline ve netstat çıktılarıyla korelasyon

Kaynakça

Görsel: TurkTeam özgün kapak görseli.

Alıntı:Yasal Uyarı: Bellek dökümü ve adli analiz yalnızca yetkili olduğunuz sistemlerde yapılmalıdır. İzinsiz erişim ve veri kopyalama TCK 243-245 kapsamında suçtur.

tonyukuk-20.jpg (Dosya Boyutu: 94.78 KB / İndirme Sayısı: 10) ]]> [Resim: attachment.php?aid=32]

Kurulum
Lab bellek dökümü alma
İlk eklentiler: pslist, netstat, cmdline
Şüpheli süreç avı
Kaynakça