PEN-200 Serisi, Bölüm 1: Puan Kazandıran Not Tutma ve Rapor Yazımı#

Bu yazı, PEN-200 modül sırasını baştan sona izleyen bir serinin ilk bölümü — planın tamamı OSCP+ hazırlık rehberinde. Bir teknik modül yerine not tutmayla başlamak, sınav saati 20'ye gelip ikinci makinede shell'i hangi curl flag'iyle aldığını hatırlamaya çalışana kadar tersmiş gibi görünüyor. Dokümantasyon da diğer her şey gibi puanlanıyor ve resmi kurallar bu konuda net:

"Dokümantasyonun, teknik olarak yetkin bir okuyucunun saldırılarını adım adım tekrar üretebileceği kadar kapsamlı olmalı. [...] yetersiz dokümantasyon, azaltılmış ya da sıfır puan verilmesine yol açar."

Bu, OSCP+ Exam Guide'ın dokümantasyon gereksinimleri bölümünden. Bu yazı, PEN-200 boyunca bir not tutma alışkanlığı kurmakla ilgili; öyle ki sınav günü o cümle hiç sorun olmasın.

Anda ne kaydedilmeli#

Önemli olan her komut için dört şey:

1. Komutun kendisi, kopyala-yapıştır; sonradan hafızadan yeniden yazılmış değil.
2. Tam çıktı, ya da önemli olan kısmı, bağlamıyla birlikte.
3. Neden çalıştırdığına dair tek satır — ne bekliyordun, ne çıktı.
4. Sınav kılavuzunun özellikle istediği anlarda ekran görüntüsü: her makinede ilk erişim ve yetki yükseltme, her ikisinde de kanıt dosyasının içeriği ve hedefin IP'si aynı karede.

"Neden" kısmını yazmak insanların atladığı kısım, ve raporu aylar sonra okunabilir kılan da tam olarak bu. "robots.txt'deki disallow girdisi buraya işaret ettiği için çalıştırdım" tek cümle ve seni 24 saatlik rapor penceresinde, yorgunken ve metodolojiyi hafızadan çıkarmak zorundayken kendi mantığını yeniden kurmaktan kurtarıyor.

Komutları hafızadan notlarına yeniden yazma — terminali kaydet#

Komutları sonradan hafızadan yeniden yazmak, raporların ince şekilde yanlış çıkmasının sebebi: bir flag düşer, bir IP yanlış yazılır ve rapor artık tekrar üretilemez. Bir oturumu anında kaydetmenin, Kali kurulumunda hazır gelen iki yolu:

script — tüm bir shell oturumunu bir typescript dosyasına sarar:

script -t 2> timing.log session.log
# ... tüm işini bu shell'de yap ...
exit
# sonra orijinal hızında tekrar oynat:
scriptreplay -t timing.log session.log

tmux pipe-pane — shell'i sarmadan tek bir paneli sürekli loglar, şu an içinde olduğun bir panede bile çalışır:

tmux pipe-pane -o -t 0 'cat >> ~/notes/pane-0.log'

İkisinden biri, rapor yazmaya oturduğunda çalıştırdığın tam komutun hafızanda değil bir dosyada olması demek. Birini seç ve alışkanlığı şimdiden her pratik makinede kur — 12 haftalık planın 11. haftasında değil, o zaman otomatikleşmesi için artık geç.

Kaydedilmiş bir oturumu otomatik olarak rapor metnine çevirmek#

script ile kaydedilmiş bir log tam ama aynı zamanda gürültülü: Script started on... başlığı, her satırda tekrar eden shell prompt'u, Script done on... alt satırı. Bunu olduğu gibi rapora yapıştırmak okunabilir ama çirkin. Küçük bir ayrıştırıcı bunu saniyeler içinde temiz bir fenced bloğa çeviriyor — işte gerçek script çıktısına karşı test edilmiş biri:

#!/usr/bin/env python3
"""`script` ile kaydedilmiş bir terminal oturumunu Markdown komut bloklarına çevirir.
 
Kullanım: python3 log2md.py session.log > session.md
"""
import re
import sys
 
HEADER_RE = re.compile(r'^(Script (started|done) on|COMMAND(_EXIT_CODE)?=)')
PROMPT_RE = re.compile(r'^\S+@\S+:\S+[#$]\s?')
 
def clean(lines):
    out = []
    for line in lines:
        if HEADER_RE.search(line):
            continue
        out.append(PROMPT_RE.sub('', line.rstrip('\n')))
    return out
 
def main():
    path = sys.argv[1] if len(sys.argv) > 1 else '/dev/stdin'
    with open(path, errors='replace') as f:
        lines = clean(f.readlines())
    text = '\n'.join(lines).strip('\n')
    text = re.sub(r'\n{3,}', '\n\n', text)
    print('```bash')
    print(text)
    print('```')
 
if __name__ == '__main__':
    main()

Gerçek bir kayıtlı oturuma karşı çalıştır:

$ cat fake-session.log
Script started on 2026-10-15 22:42:19+00:00 [COMMAND="bash" <not executed on terminal>]
root@kali:~# whoami
root
root@kali:~# id
uid=0(root) gid=0(root) groups=0(root)
root@kali:~# exit
Script done on 2026-10-15 22:42:30+00:00 [COMMAND_EXIT_CODE="0"]

$ python3 log2md.py fake-session.log

yukarıdaki bölümdeki rapor şablonuna yapıştırmaya hazır şunu üretiyor:

whoami
root
id
uid=0(root) gid=0(root) groups=0(root)
exit

Regex'ler bilerek basit tutuldu — farklı bir prompt formatı (zsh, özel bir PS1, farklı bir hostname kalıbı) PROMPT_RE'de tek satırlık bir ayar ister. Önemli olan da bu: kurup güvenmen gereken bir bağımlılık değil, sınav sırasında bir dakikada okuyup uyarlayabileceğin otuz satır. Her script logunu kaydettikten hemen sonra bunun üzerinden geçir; "Tekrar üretme adımları" bölümlerin, sen raporu bilinçli olarak yazmaya başlamadan büyük ölçüde yazılmış olur.

24 saat boyunca dayanan bir not tutma düzeni#

Önemli olan araç değil, yapı. Üç gerçek seçenek; PEN-200 modül notların ve sınav notların aynı formatta kalsın diye, modüllere başlamadan önce birini seç:

• CherryTree — kod blokları için düğüm bazlı syntax highlighting olan hiyerarşik bir not defteri. Ofansif güvenlik kurslarının uzun süredir varsayılanı, nedeni var: hızlı, çevrimdışı ve ağaç yapısı "hedef → servis → bulgu" üzerine doğal şekilde oturuyor.
• Obsidian — diskte düz Markdown dosyaları, yani sınav sırasında grep'lenebilir ve pratik makinelerin için git'te diff'lenebilir. CherryTree'den yapılandırması daha yavaş ama dosyalar araçtan daha uzun ömürlü.
• Düz bir Markdown dosya dizini, hedef başına bir dosya, hiç uygulama yok. Her yerde çalışır, hiçbir şeye mal olmaz ve tutarlı bir şablon konusunda disiplinliysen — ki önemli olan da bu, araç değil — gerçekten yeterli.

Hangisini seçersen seç, düğüm/dosya yapısı sınav kontrol panelini yansıtmalı: hedef başına bir üst seviye girdi, içinde sabit alt bölümler. Aşağıdaki şablon, bir sonraki bölümün nihai raporda istediğiyle eşleşiyor; böylece çalışma notaların rapor bölümlerine minimum yeniden yazımla dönüşür:

# HEDEF-ADI (10.10.X.X)
 
## Kapsam ve hedefler
-
 
## Enumerasyon
### Portlar
```
<!-- nmap çıktısı -->
```
 
### Servisler
-
 
## İstismar
### Zafiyet
-
 
### Exploit kodu
- Kaynak: <url>
- Değiştirildi mi: evet/hayır
- Yapılan değişiklikler ve nedeni:
 
### Tekrar üretme adımları
1.
 
### Kanıt — local.txt
```
<!-- ekran görüntüsü referansı + ip a çıktısı -->
```
 
## Yetki yükseltme
### Vektör
-
 
### Tekrar üretme adımları
1.
 
### Kanıt — proof.txt
```
<!-- ekran görüntüsü referansı + ip a çıktısı -->
```
 
## Düzeltme önerisi
-

Bunu canlı doldur, sonunda hafızadan değil. "Sonra düzgünce yazarım" demekle gerçekten yazmak arasındaki fark, puanların kaybolduğu yer — iş yapılmadığı için değil, iş taze haldeyken kaydedilmediği için.

Exploit kodu: kurallar gerçekte ne istiyor#

Burada insanlar takılıyor çünkü içgüdü her şeyi yapıştırmak. Resmi yönerge daha dar:

"Bir exploit'te hiçbir değişiklik yapmadıysan, yalnızca exploit'in bulunabileceği URL'yi ver. Değiştirilmemiş tam kodu, özellikle birkaç sayfa uzunluktaysa, dahil etme. [...] Bir exploit'i değiştirdiysen şunları dahil et: değiştirilmiş exploit kodu, orijinal exploit koduna URL, shellcode üretmek için kullanılan komut (varsa), yaptığın değişikliklerin vurgulanması ve bu değişikliklerin neden yapıldığının açıklaması."

Pratikte: çalıştırdığın her hazır exploit'in yanına tek satırlık bir not tut — tam URL ve dokunup dokunmadığın. Dokunduysan, notlarına yapıştırılmış bir diff (diff original.py modified.py) "vurgulanmış değişiklikler" kısmını, sonradan ekstra yazı yazmadan senin için halleder.

Rapor yapısı, puanlananla eşleştirilmiş#

OSCP+ bilgi tabanı, raporun gerekli parçalarını neredeyse birebir öğrenme hedefleri olarak listeliyor:

• Yönetici özeti — teknik olmayan, teknik bulguları hiç okumayacak birine yazılmış, iş etkisini ve genel riski belirten.
• Teknik özet — metodoloji, kapsam ve araçlar; teknik bir okuyucunun tek tek bulgulara dalmadan önce göz gezdirdiği seviyede.
• Hedef başına bulgular — zafiyet, kanıt, tam tekrar üretme adımları ve bir öneri, yukarıdaki yapıda.
• Ekler — ham tarama çıktısı, kullanılan kelime listeleri, bir bulguyu onu karmaşıklaştırmadan destekleyen her şey.

Resmi olarak iki şablon var: bir Word sürümü ve bir OpenOffice/LibreOffice sürümü. Aynı zemini kapsadığı sürece kendi şablonunu da kullanabilirsin — SysReptor ya da noraj'ın OSCP şablonu üzerinden render edilen bir Markdown şablonu işe yarıyor ve çoğu kişinin gerçekte yazdığı şey bu; çünkü Markdown-girdi, PDF-çıktı, 23. saatte 40 sayfalık bir Word dosyasını elle biçimlendirmekten çok daha iyi. Hangisini seçersen seç, bundan sonra her pratik makinede kullan — sadece üç sınav provası haftasında değil — böylece doldurmak rutin olur, sayaç çalışırken öğrendiğin yeni bir beceri değil.

Bu serinin geri kalanına ne kazandırıyor#

Bundan sonraki her modül, oturumu kaydettiğini ve notları canlı doldurduğunu varsayıyor; çünkü o notların içeriği sonraki yazıların üzerine inşa ettiği şey: enumerasyon çıktısı Bölüm 2'nin kanıtı oluyor, istismar adımları SQL injection ve client-side modüllerinin tekrar üretme adımları oluyor ve Active Directory gelip üç pratik makine önce nasıl kerberoast yaptığını hatırlaman gerektiğinde tüm dizin kendi aranabilir referansın oluyor.

Bölüm 2, bilgi toplamayı ele alıyor — notaların gerçekten dolmaya başladığı ilk modül.