Kendi Yapay Zeka Ajanınızı Yapın!

Merhaba bu yazıda, adım adım giderek birlikte kendi yapay zeka ajanımızı yapacağız. Ben uzmanlık alanım olan IoT cihazlar hakkında yapmayı seçmiş olsamda size bırakacağım github linkinden siz, size uygun olan yapay zeka ajanını seçebilir ve kendi alanınıza göre geliştirebilirsiniz. Uzatmadan konuya girmek gerekirse:

Bölüm 1: Briefing — Siber Güvenlikte “Zeka” Paradigması

2026 yılında siber güvenlik operasyonları, geleneksel imza tabanlı tespitlerden ve reaktif savunma mekanizmalarından tamamen koptu. Yapay zeka artık bir “yardımcı araç” olmanın ötesine geçerek; tehdit modellemeden firmware analizine, karmaşık log korelasyonundan otonom olay müdahalesine kadar tüm analitik altyapının merkezi sinir sistemi haline geldi. Ancak bu derin entegrasyon, Red Team operasyonlarında kritik bir stratejik soruyu doğuruyor: Bu zekayı nerede çalıştırıyorsunuz?

Siber güvenlikte hız, çoğu zaman gizliliğin (OpSec) önüne geçtiğinde bir zafiyete dönüşür. Hassas bir firmware dökümünü veya ağ topolojisini bulut tabanlı bir modele emanet etmek, sadece bir teknik tercih değil, operasyonel bir egemenlik devridir.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Llama 4: IoT Firmware Analizinde Neden Yeni Standart?

2026 itibarıyla Meta’nın Llama 4 model ailesi, açık kaynak dünyasındaki en gelişmiş akıl yürütme (reasoning) kapasitesini temsil ediyor. Bir IoT analisti için Llama 4, sadece bir dil modeli değil; saniyeler içinde binlerce satırlık karmaşık kod bloğunu anlamlandırabilen dijital bir iş ortağıdır. Bu modeli IoT zafiyet analizinde vazgeçilmez kılan üç teknik sütun şunlardır:

1 — IoT cihazları, özellikle gömülü sistemler söz konusu olduğunda, binlerce satırlık “strings” çıktısı ve karmaşık dosya sistemleri üretir.

• Teknik Derinlik: Sıkıştırılmamış bir firmware görüntüsü on binlerce satırlık veri barındırabilir. Llama 4'ün 2026 standartlarındaki geniş bağlam penceresi (32K — 128K+ token), analistin veriyi parçalara bölüp bağlamı (context) kaybetme riskini ortadan kaldırır.
• Analitik Avantaj: Model, firmware’in başındaki bir yapılandırma dosyası ile sonundaki bir binary çağrısı arasındaki korelasyonu tek bir oturumda kurabilir.

2 — Çok Katmanlı Kod Muhakemesi

IoT analizi, sadece metin okumak değildir; assembly seviyesinden yüksek seviyeli shell script’lere kadar çok katmanlı bir dilden anlama yeteneği gerektirir.

• Teknik Derinlik: Llama 4; düşük seviyeli C kodlarını, kriptografik sabitleri ve donanım sürücüsü mantığını bir bütün olarak değerlendirir.
• Analitik Avantaj: Model, sadece “bir şifre bulundu” demez; bu şifrenin hangi fonksiyon tarafından, hangi hashing algoritmasıyla (örneğin MD5 veya SHA-256) işlendiğini ve sömürülebilirlik (exploitability) potansiyelini teknik derinliğiyle sunar.

3 — Tam Determinizm ve Parametre Kontrolü

Siber güvenlik analizinde “belki”lere yer yoktur. Analizin doğrulanabilir ve tekrarlanabilir olması bir zorunluluktur.

• Teknik Derinlik: Yerel bir Llama 4 kurulumu; temperature, top_p ve seed gibi parametrelerin analist tarafından %100 kontrol edilmesini sağlar.
• Analitik Avantaj: Ticari bulut API’larında bu parametreler genellikle kapalı bir kutu gibi yönetilir ve model zamanla değişebilir (model drift). Yerel kurulumda ise aynı firmware dosyasını aylar sonra analiz etseniz bile aynı kesin sonuçları alırsınız. Bu, adli bilişim (forensics) ve denetim (audit) süreçleri için hayati önem taşır.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Bölüm 2: Verinin Kutsallığı ve Zero-Trust Paradigması

Siber güvenlik analizinde veri, korunması gereken pasif bir varlık değil; operasyonun başarısını belirleyen aktif bir “kutsal emanettir”. Bu bölümde, analizin yapıldığı ortamın neden analizin sonucu kadar kritik olduğunu ve bulut tabanlı zekanın yarattığı operasyonel körlüğü inceleyeceğiz.

IoT Neden Kritik? 2026’nın Genişleyen Saldırı Yüzeyi

2026 sonu itibarıyla dünya genelinde bağlı IoT cihaz sayısı 18 milyarı aşmış durumdadır. Bu sayı sadece niceliksel bir artışı değil, kritik altyapıların derinlemesine dijitalleşmesini temsil eder:

• Kritik Ekosistemler: Endüstriyel kontrol sistemleri (ICS), gelişmiş medikal cihazlar, ulusal enerji altyapısı bileşenleri ve akıllı bina yönetim sistemleri artık aynı ağ dokusunun birer parçasıdır.
• Firmware’in Gizli Dünyası: Bu cihazların firmware’leri; gömülü kimlik bilgileri, özel kriptografik anahtarlar, üreticiye ait dahili API endpoint’leri ve çoğu zaman yıllardır yamalanmamış kritik zafiyetler (CVE’ler) barındıran birer “kara kutu” niteliğindedir.
• Analistin Sorumluluğu: Bir güvenlik analisti için bu firmware’leri incelemek, modern kalelerimizin en zayıf halkalarını deşifre etmektir. Ancak bu deşifre işlemi sırasında kullanılan araçlar, zafiyetin kendisinden daha büyük bir risk yaratmamalıdır.

OpSec Riski: Bulut API’lerine Veri İhracatı

Bir firmware binary’sini veya ondan türetilmiş strings çıktısını OpenAI, Anthropic ya da benzer bir bulut sağlayıcısının API’sine gönderdiğinizde, aslında kendi kalenizin kapılarını anahtarıyla birlikte teslim ediyorsunuz. Bu hamle, en az dört ana boyutta operasyonel güvenlik (OpSec) felaketine yol açar:

1. Gönüllü Veri Sızıntısı (Data Exfiltration): Müşterinizin ağ topolojisine ait IP adresleri, dahili hostname’ler ve şifre hash’lerini içeren verileri üçüncü taraf sunuculara aktarmak, teknik olarak bir veri sızıntısıdır. Bu durum; GDPR ve NIS2 gibi regülasyonlarla uyum sorunu yaratmanın ötesinde, müşteri güvenini telafi edilemez şekilde zedeler.
2. Karanlık Kayıtlar (Logging ve Retention): Sağlayıcının model eğitim süreçleri veya güvenlik protokolleri kapsamında logladığı her prompt, müşterinizin en mahrem altyapı detaylarını içerebilir. Bu logların kimler tarafından erişilebilir olduğu ve hangi yasal talepler (subpoena) karşısında ifşa edilebileceği tamamen sizin kontrolünüz dışındadır.
3. Dolaylı Tedarik Zinciri Saldırıları: Büyük AI sağlayıcıları, siber saldırganlar için en değerli hedefler haline gelmiştir; 2024–2025 döneminde bu sağlayıcılara yönelik gerçekleşen çok sayıda erişim girişimi bunun kanıtıdır. Verinizi bulutta tutmak, sizi doğrudan hedef olmasanız bile dolaylı bir saldırı yüzeyine eklemler.
4. Prompt Injection — Firmware Katmanı: Firmware içerisine kasıtlı olarak yerleştirilmiş prompt injection paternleri, bulut modelinin davranışını manipüle ederek yanlış analiz üretmesine veya daha kötüsü, analiz sürecini bir saldırı vektörüne dönüştürmesine neden olabilir.

Zero-Trust Prensibinin Analitik Sınırı

Zero-Trust (Sıfır Güven) mimarisi genellikle ağ segmentasyonu veya kimlik doğrulama çerçevesinde ele alınsa da, özünde yatan felsefe çok daha radikaldir: Hiçbir varlığa, sistem dışı hiçbir aktöre varsayılan güven tanıma.

Bu prensip, günümüzün popüler bulut AI sağlayıcılarını da kapsar. Doğru ve güvenli analiz yaklaşımı, veriyi araca taşımak değil; analiz motorunu (AI) verinin yanına getirmektir.

Not:Yerel bir model kullandığınızda, güven sınırı (trust boundary) fiziksel makinenizin sınırıyla örtüşür. Model yerel diskinizdedir, ağ çıkışı kapalıdır ve log mekanizması tamamen sizin denetiminizdedir. Veri size gelir, analiz içeride biter ve hiçbir byte dışarı sızmaz.

Peki hiç düşündünüz mü?

IoT cihazlar, bu kadar fazla kullanılırken ve hayatımızın her alanındayken hatta akıllı şehirler oluşturulmaya başlamışken neden bu güvenlik hiçbir zaman konuşulmuyor?

IoT cihazlar, o kadar fazla ve seri bir üretim haline geldi ki günümüzde artan “popüler kültür” ile birlikte IoT cihazlar artık bir statü göstergesi fakat kimse aslında evinde bir yabancı misafir ettiğinin farkında değil.

IoT cihazlar şuanda çok yüksek anlamda talep görüyor ve sistemde bolca şirketler tarafından her gün yeni bir ürün sunularak yarışlar yapılıyor. Fakat donanımlar ne kadar güvenli? Bu kadar ucuz ürünlerin korunması için pahalı bir altyapı gerekmez mi?

Fark ederseniz IoT cihazların uygulamaları dahi yeterince can sıkıcı ve güvensiz. Şuanda akıllı saatinizin uygulamasına girdiğiniz takdirde göreceksiniz ki arayüz basit ve hiçte güven vermiyor. Bazen adımlarınızı yanlış sayıyor. Bazen vaad ettiği gibi telefonda konuşmanıza olanak bile tanımıyor çünkü bluethoot yeterince çekmiyor. Peki hepimizin bunlara bu kadar yoğun ilgi gösterme sebebimi sistem tarafından kontrol edildiğimiz için olabilir mi?

LLM Hacking bu kadar basit bir hale gelmişken ve bence yapay zeka gerçekten yeterince “yapay” iken, IoT cihazlar üzerinde risk gittikçe arttı. Uygulamalar içinde yapay zekaların manipüle edilebilir olması, donanımların internete tamamen açık ve admin şifrelerin hiçbir zaman değiştirilmemesi. Donanımların ve eşyaların ucuzluğu. Uygulama izinlerinde olan gereksiz erişimler?

Sizi birinin dinlemesi, izlemesi için sandığınız kadar teknik bir bilgiye ihtiyacınız yok.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Bölüm 3: Kali Linux Üzerinde Laboratuvar Kurulumu

Bu aşama, teoriden pratiğe geçtiğimiz aşama. Analiz ortamı olarak Kali Linux (2025.x veya üzeri) seçimi, halihazırda yapılandırılmış siber güvenlik araç depoları ve optimize edilmiş çekirdek mimarisi nedeniyle profesyonel bir endüstri standardıdır.

Neden Ollama? Analitik Bir Değerlendirme

Yerel model çalıştırma (Local LLM Inference) ekosisteminde birçok alternatif (llama.cpp, Jan, LM Studio) bulunsa da, Ollama’yı bir Red Team laboratuvarının merkezine koymamızı sağlayan üç teknik sütun mevcuttur:

1. Minimalizm ve Bağımlılık Yönetimi: Ollama, tüm bağımlılıkları tek bir binary içinde toplayarak sistem kütüphaneleriyle çakışma riskini minimize eder. Systemd entegrasyonu sayesinde analiz süreci, sistem yeniden başlatılsa dahi kesintisiz bir servis olarak arka planda çalışmaya devam eder.
2. Mutlak İzolasyon (Air-Gap Ready): Birçok AI aracı gizli telemetri verileri gönderirken, Ollama tamamen şeffaf bir ağ yapısına sahiptir.
3. “ — — no — network” modu ile çalıştırıldığında, modelin dış dünya ile fiziksel bağı kesilir; bu da hassas firmware verilerinin dışarıya sızmasını imkansız kılar.
4. Dinamik Kaynak Tahsisi (MoE Uyumu): Llama 4 Scout gibi Mixture of Experts (MoE) mimarisine sahip modeller, yüksek VRAM yönetimi gerektirir. Ollama, “— — num — gpu" parametresi ile model katmanlarını (layers) GPU ve CPU arasında milimetrik hassasiyetle paylaştırarak 16GB VRAM kapasiteli orta ölçekli sistemlerde dahi tam kapasite performans sağlar.

Adım Adım Kurulum Prosedürü

Kali Linux terminalinde Ollama motorunu sisteme entegre etmek için aşağıdaki prosedürü izleyin:

• Ollama kurulum script'ini çalıştırıyoruz. (Resmi kanal üzerinden)

Biraz zaman alabilir.

• Ardından servisin arka planda aktifleştiğini doğrulamak için:

# Eğer servis aktif değilse, boot sırasında çalışacak şekilde yapılandır
sudo systemctl enable --now ollama

Kurulum tamamlandığında Ollama, varsayılan olarak localhost:11434 portu üzerinde dinlemeye başlar. Bu portun sadece loopback interface üzerinden erişilebilir olması, ağdaki diğer aktörlerin analiz motorunuza yetkisiz erişim sağlamasını engeller.

Llama 4 Scout Modelinin Entegrasyonu

2026 yılı Red Team operasyonlarının amiral gemisi olan Llama 4 Scout, 17 milyar aktif parametreli MoE mimarisi ile gelir. Bu model, karmaşık IoT yapılarını analiz etmek için optimize edilmiştir.

1 —

Llama 4 Scout çekilmesi (Q4_K_M Kuantizasyonu ile ~12GB) ollama pull llama4:scout

İndirilen modellerin bütünlüğünü doğrula ollama list

İlk operasyonel test: "online" yanıtını alabiliyor muyuz? ollama run llama4:scout "Respond with one word: online"

OpSec Notu: Ağ bağlantısı yalnızca modelin indirilmesi aşamasında gereklidir. Model yerel diske yerleştikten sonra fiziksel bağlantıyı kesmek ve yerel blob dosyalarının hash değerlerini doğrulamak, adli bilişim (forensics) açısından bir zorunluluktur.

Bash

# Model ağırlıklarının (blob) SHA256 hash doğrulaması
sha256sum ~/.ollama/models/blobs/*

Bu aşamada laboratuvarımız teknik olarak hazırdır. Ancak elimizdeki model şu an “genel amaçlı” bir zekadır. Bir sonraki bölümde, bu zekayı bir IoT Analisti gibi düşünmeye zorlayacak olan Modelfile mimarisini ve “karakter tanımını” inceleyeceğiz.

Ajanın “zihin yapısını” oluştururken kullanacağımız Modelfile parametrelerine (temperature, top_p) geçelim.

Bölüm 4: Ajan Mimarisi ve Karakter Tanımı — Dijital Uzmanlığın İnşası

Genel amaçlı bir büyük dil modeli (LLM), her şeyi bilen ama hiçbir konuda uzmanlaşmamış bir “bilge” gibidir. Siber güvenlik operasyonlarında, özellikle de IoT firmware analizi gibi hata payı olmayan bir alanda, bu genel yaklaşım yetersiz kalır. Bize gereken, nezaket ifadeleriyle vakit kaybetmeyen, veriye bir titizlik ile yaklaşıp bulguları askeri bir disiplinle raporlayan bir Red Team Analisti’dir.

Bu bölümde, Ollama’nın Modelfile yapısını kullanarak bir modelin “zihnini” nasıl yeniden programlayacağımızı, yani Instruction Tuning mantığının çıkarım anındaki (inference-time) yansımasını detaylandıracağız.

Modelfile: DNA’yı Tanımlamak

Bir modeli özelleştirmek için ağırlıklarını yeniden eğitmek (fine-tuning) hem maliyetli hem de donanım açısından zordur. Modelfile ise modelin ağırlıklarını değiştirmeden, ona operasyonel bir çerçeve çizer.

Aşağıdaki yapılandırma, llama3:8b (veya laboratuvarınızdaki mevcut model) üzerine inşa edilen profesyonel bir analiz reçetesidir:

1 — Şimdi Öncelikle ajana ait yapılandırma dosyalarını düzenli bir şekilde tutacağımız bir dizin oluşturmalıyız.

Örnek vermek gerekirse:

• mkdir ~/Document/IoT/iot-analyst

2 — Dizinin içine giriyoruz nano ile (Kolay olması açısından dedim ama istediğiniz editörü kullanabilirsiniz.) bir modelfile dosyası oluşturacağız.

Örnek:

cd /Document/IoT/iot-analyst

bash 

nano Modelfile

Nano ile dosyamızı açtıktan sonra modelin “genel sohbet” yeteneklerini budayıp onu bir IoT Red Team Analisti’ne dönüştürecek olan blokları yazacağız.

FROM llama3:8b-instruct-q4_0

PARAMETER temperature 0.1

PARAMETER top_p 0.9

PARAMETER top_k 20

PARAMETER repeat_penalty 1.2

PARAMETER num_ctx 32768

SYSTEM """

Sen kıdemli bir IoT Red Team Analistisin. Görevin, verilen ham veriyi (strings, hexdump, config) operasyonel bir süzgeçten geçirmektir.

ANALİZ PROTOKOLLERİ:

1. GİRİŞ VE SELAMLAŞMA YASAKTIR: "Analiz sonucunda...", "İşte bulgular..." gibi cümlelerle vakit kaybetme. Doğrudan teknik veriye gir.

2. KRİPTOGRAFİK ANALİZ: MD5, DES gibi zayıf algoritmaları veya hardcoded AES key'lerini gördüğünde bunları doğrudan 'HIGH/CRITICAL' zafiyet olarak işaretle.

3. ENTROPİ KONTROLÜ: Anlamsız ama yüksek entropili karakter dizilerini (örn. "xK2mN9pQ...") potansiyel private key veya session token olarak sınıflandır.

4. AĞ VE TOPOLOJİ: Dahili IP adreslerini (192.168.x.x, 10.x.x.x) ve endpoint'leri belirle, veri sızdırma (exfiltration) riskini değerlendir.

5. İNSAN FAKTÖRÜ: Eğer firmware içinde 'test', 'debug', 'temporary' gibi ibareler varsa, bunu organizasyonel bir güvenlik kültürü zafiyeti olarak not düş.

RAPORLAMA FORMATI:

BULGU -> KANIT (Ham veri kesiti) -> EXPLOITABILITY (Severity) -> ÖNERİLEN AKSİYON.

Eğer veri kesin bir sonuca varmak için yetersizse, spekülasyon yapma; sadece "VERİ YETERSİZ" de ve analizi bitir.

Neden Bu Parametreleri Seçtik?

Bir analist olarak, kullandığınız aracın neden belirli bir şekilde davrandığını bilmek zorundasınız. Parametreler, ajanın “muhakeme motorunun” vites ayarlarıdır.

1. Determinizm ve temperature: 0.1

Güvenlik analizinde tekrarlanabilirlik esastır. Bir firmware dökümünü bugün analiz ettiğinizde aldığınız sonuçla, yarın aldığınız sonuç aynı olmalıdır. Temperature değeri 0.1'e çekildiğinde, model “yaratıcılığını” kaybeder ve her seferinde matematiksel olarak en yüksek olasılıklı (en mantıklı) teknik terimi seçer. Bu, adli bilişim standartlarında bir analiz üretmenizi sağlar.

2. Halüsinasyon Kontrolü: top_k ve top_p

Modelin kelime seçerken bakacağı havuzu daraltıyoruz. top_k: 20 değeriyle, modelin her adımda sadece en olası 20 kelimeye bakmasını sağlıyoruz. Bu, teknik dökümlerde modelin "uydurma" (hallucination) riskini minimize eder.

3. Bağlamsal Hafıza: num_ctx: 32768

IoT firmware’lerinden elde edilen strings çıktıları devasadır. Standart 2K veya 4K bağlam pencereleri, analizin ortasında ajanın "hafıza kaybı" yaşamasına neden olur. 32K context window (bağlam penceresi), ajanın dökümanın başındaki bir IP adresi ile sonundaki bir curl komutu arasında bağ kurmasını (korelasyon) sağlar.

Ajanı Derle ve Canlandır

Dosya hazırsa, şimdi o reçeteyi (Modelfile) bir “dijital kimliğe” dönüştürme ve ajanımızı hayata döndürme vaktidir. Bu aşama, yazdığın talimatların ana modelin üzerine bir “uzmanlık katmanı” olarak kalıcı şekilde işlendiği andır.

Terminalde hala oluşturduğunuz dizinde olduğunuzu teyit edin ve şu komutu çalıştırın:

Bash

ollama create iot-analyst -f Modelfile

Ne oluyor? Ollama, Modelfile içindeki parametreleri ve sistem mesajını okur, llama3:8b temel ağırlıklarıyla birleştirir ve senin için "iot-analyst" adında yeni bir model oluşturur. Ekranında "transferring weights" ve "success" yazılarını görmelisin.

Adım 3: Varlık Kontrolü

Şimdi sistemin bu yeni kimliği başarıyla kütüphaneye eklediğinden emin olalım. Terminalde şu komutu çalıştırıyoruz:

ollama list

Çıktıda:

iot-analyst-latest

Çıktısını görmeliyiz.

Eğer bu çıktıyı gördüyseniz Ajanınız sistemine başarıyla kaydedilmiş. iot-analyst artık emirlerinizi bekliyor.

Şimdi bu ajanla ilk temasımızı kuracağız. Amacımız, yazdığımız SYSTEM talimatlarının (nezaket yasağı, doğrudan teknik odak vb.) “zihnine” tam olarak işleyip işlemediğini görmek.

Bunun için terminalde şu komutu çalıştırın:

ollama run iot-analyst "What is your function?"

Beklenen Çıktı: “Identify vulnerabilities in IoT firmware, assess exploitability, and report findings in structured format. No other functions.”

(Dikkat: Eğer ajan size “Merhaba! Ben bir AI asistanıyım…” diyorsa, Modelfile’daki SYSTEM prompt katmanı düzgün işlenmemiş demektir. Gerçek bir Red Team ajanı vakit kaybetmez.)

BİZİM ÇIKTIMIZ:

As a senior IoT Red Team Analyst, my primary function is to analyze the 
given raw data (strings, hexdump, config) and filter it through an 
operational sieve. I'm responsible for identifying potential security 
vulnerabilities, weaknesses, or irregularities in the provided data.

My analysis protocol involves:

1. No introductory phrases; get straight to the technical details.
2. Cryptographic analysis: Identify weak algorithms like MD5, DES, or 
hardcoded AES keys and flag them as HIGH/CRITICAL vulnerabilities.
3. Entropy control: Classify high-entropy character strings (e.g., 
"xK2mN9pQ...") as potential private key or session token candidates.
4. Network topology: Identify internal IP addresses (192.168.x.x, 
10.x.x.x) and endpoints to assess data exfiltration risks.
5. Human factor analysis: If I find terms like 'test', 'debug', or 
'temporary' in the firmware code, it may indicate an organizational 
security culture weakness.

My reporting format is as follows:

Vulnerability -> Evidence (Raw data snippet) -> Exploitability (Severity) 
-> Recommended Action

If the data doesn't provide a clear conclusion, I won't speculate; 
instead, I'll simply state "DATA INSUFFICIENT" and conclude my analysis.

Karakter tam istediğimiz gibi oturmuş. Hiçbir “Merhaba”, “Nasılsın” veya “Ben bir yapay zekayım” gibi gereksiz dolgu cümlesi kurmadan, doğrudan operasyonel kimliğini ve protokollerini teknik bir dille masaya koyuyor.

Neden “Başarılı” Saydık?

1. Kimlik Üstlenme: Kendini bir “AI Assistant” olarak değil, “Senior IoT Red Team Analyst” olarak tanımladı.
2. Protokol Sadakati: Yazdığımız 5 ana kuralı (Kriptografi, Entropi, Ağ Topolojisi vb.) kendi zihin yapısına tam olarak işlemiş.
3. Format Onayı: Raporlama formatını (Vulnerability -> Evidence -> Severity) benimsediğini teyit etti.

5. SAHADA ANALİZ VE İNSAN FAKTÖRÜ

Artık laboratuvardan çıkıp sahaya inme vakti geldi. Teorik olarak kurduğumuz, parametrelerini ince ince ayarladığımız ve “Zero-Trust” prensibiyle dış dünyadan izole ettiğimiz iot-analyst ajanımızı gerçek bir senaryoda test edeceğiz.

Amacımız; binlerce satırlık anlamsız veri yığınının içinden, sistemi tamamen ele geçirmemizi sağlayacak o kritik iğneyi bulmak.

Senaryo ve Operasyonel Veri

Bir Red Team operasyonundayız. Müşteri ağında tespit edilen, kritik altyapılara köprü görevi gören bir endüstriyel IoT gateway cihazından fiziksel müdahale ile bir firmware dump (yazılım imajı) alındı. Klasik prosedür uygulandı : binwalk aracı ile cihazın squashfs dosya sistemi ayıklandı ve içindeki okunabilir metinleri çıkarmak için strings komutu çalıştırıldı.

Elde edilen devasa çıktı, yerel makinemizde bekleyen ajanımıza boru hattı (pipeline) ile aktarılıyor.

ANALİZ KOMUTU:

strings firmware_dump.bin | ollama run iot-analyst

Ham strings Çıktısı (Analize Giden Seçilmiş Kesit)

İnsan gözüyle bakıldığında saatler sürebilecek, "gürültülü" ve yorucu bir veri bloğu:

/bin/sh
/etc/passwd
root:$1$xK2mN9pQ$vH8rT3wL6yZ1uA4bC0dE5.:0:0:root:/root:/bin/sh
admin:admin123
mqtt_broker=192.168.10.5
mqtt_port=1883
api_key=sk-a7f3c291b84e56d0f2a1
update_server=http://update.vendor-internal.net/fw/
debug_mode=1
AAAAAAAAAAAAAAAAAAAAAAAAA
/dev/ttyS0
SSL_CTX_new
MD5_Init
MD5_Update
SSL_CTX_set_verify_depth
verify=0
0123456789abcdef

Ajanın Operasyonel Çıktısı

Ajanımız veriyi aldı. Bulut API’lerine hiçbir şey göndermedik, ağımızdan hiçbir bayt dışarı çıkmadı. Saniyeler içinde, 4. Bölümde yazdığımız o katı protokollere harfiyen uyan şu rapor ekranımıza düşüyor:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FINDING [1] — HARDCODED ROOT CREDENTIALS
EVIDENCE: /etc/passwd entry contains MD5-hashed root password ($1$ prefix = MD5-crypt). 
          Hash: $1$xK2mN9pQ$vH8rT3wL6yZ1uA4bC0dE5. 
          MD5-crypt is broken. Offline cracking via hashcat trivial on modern GPU.
EXPLOITABILITY: CRITICAL
          Full system compromise upon hash crack. No privilege escalation needed. 
          Estimated crack time (RTX 4090, rockyou wordlist): <90 seconds.
RECOMMENDED ACTION: Rotate immediately. Migrate to SHA-512 or bcrypt. Force firmware update.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FINDING [2] — PLAINTEXT DEFAULT CREDENTIAL
EVIDENCE: admin:admin123 — plaintext, no hashing, likely web interface or serial console.
EXPLOITABILITY: CRITICAL
          Universal default credential. Automated scanner hit probability: 100%.
RECOMMENDED ACTION: Eliminate hardcoded credentials. Implement first-boot provisioning.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FINDING [3] — UNENCRYPTED MQTT + INTERNAL TOPOLOGY EXPOSURE
EVIDENCE: mqtt_port=1883 (plaintext MQTT, no TLS). 
          Internal IP 192.168.10.5 embedded in binary.
EXPLOITABILITY: HIGH
          Network eavesdropping on all MQTT traffic. Internal topology leaked. 
          If device is internet-accessible, broker address enables lateral movement targeting.
RECOMMENDED ACTION: Enforce MQTT over TLS (port 8883). Remove hardcoded internal IPs.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FINDING [4] — EXPOSED API KEY MATERIAL
EVIDENCE: api_key=sk-a7f3c291b84e56d0f2a1 — 20-char alphanumeric key, hardcoded.
EXPLOITABILITY: HIGH
          Key type and associated service unknown from binary alone. Possible cloud API access. 
          Any party with binary access has the key.
RECOMMENDED ACTION: Revoke immediately. Implement device-specific key provisioning. 
                    Use hardware security modules (TPM) for key storage at manufacturing.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FINDING [5] — DISABLED TLS VERIFICATION
EVIDENCE: SSL_CTX_set_verify_depth present. verify=0 immediately following. 
          MD5_Init/MD5_Update imports — MD5 in active use for cryptographic operations.
EXPLOITABILITY: HIGH
          TLS verification disabled = active MitM attack surface on all HTTPS comms. 
          MD5 for integrity: collision-trivial, unacceptable in any security-sensitive context.
RECOMMENDED ACTION: Set verify=1. Implement certificate pinning. Replace MD5 with SHA-256.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FINDING [6] — ACTIVE DEBUG MODE + HTTP UPDATE CHANNEL
EVIDENCE: debug_mode=1. update_server=http:// (no TLS).
EXPLOITABILITY: MEDIUM / HIGH
          Debug mode in production: verbose output, potential shell access, hidden endpoints. 
          HTTP update channel: firmware replacement via MitM. Supply chain attack vector.
RECOMMENDED ACTION: Strip debug symbols at build time. Enforce HTTPS + signature verification 
                    for all firmware update mechanisms.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Neden Başarılı Olduk? Çıktının Analizi

dikkat etmemiz gereken en kritik nokta şudur: Model hiçbir şekilde “Merhaba, işte analiziniz” gibi boş laflarla vakit kaybetmedi.

Bunun yerine, doğrudan belirlediğimiz o acımasız Red Team formatına girdi:

• Kriptografik Kontrol Çalıştı: MD5 hash’i anında tespit etti ve bunun modern GPU’larla 90 saniyenin altında kırılabileceğini (RTX 4090 detayıyla) raporladı.
• Entropi Zekası Devrede: sk-a7f3... dizilimini anlamsız bir metin olarak geçmedi, bunun yüksek entropili bir API anahtarı olduğunu anladı ve sızıntı riskini vurguladı.
• Ağ Topolojisi Hassasiyeti: 192.168.10.5 IP adresini sadece bir sayı dizisi olarak okumadı; bunun dahili bir lateral movement (yatay hareket) zafiyeti doğurabileceğini stratejik olarak bağladı.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — —

İnsan Faktörü: Zafiyetin Psikolojisi ve Kurumsal Çöküş

Bir sistemdeki en büyük ve yaması en zor zafiyet her zaman insandır. Ajanımızın raporunun sonunda sadece kodları değil, o kodları yazan kültürü de deşifre ettiğini fark ettiniz mi?

Bir firmware imajında MD5 hash görmek veya admin:admin123 gibi düz metin (plaintext) şifreler bulmak, 2026 standartlarında basit bir "teknik cahillik" ile açıklanamaz. Bu, organizasyonel bir güvenlik kültürünün ürünüdür; daha doğrusu güvenlik kültürsüzlüğünün bir kanıtıdır.

• Production’da Kalan Debug Flag: Birileri bunu test ortamından canlıya geçerken fark etmedi ya da umursamadı. Bu bir süreç hatasıdır.
• HTTP Üzerinden Güncelleme: Bu tesadüfi bir hata değil, bilinçli ve ucuza kaçılmış bir mühendislik kararıdır.
• Kapatılan TLS Doğrulaması (verify=0): Muhtemelen proje teslim tarihinin baskısı altında, geliştiricinin "Sertifika hatası veriyor, şimdilik kapatayım sonra düzeltirim" deyip hiçbir zaman geri dönmediği o klasik anın dijital fosilidir.

Bu bulgular, hedef kurumun güvenlik olgunluk seviyesini (security maturity) çıplak bir şekilde açığa çıkarır. İyi bir siber güvenlik analisti sadece bir terminal ekranına bakmaz; o ekrandaki hataların arkasındaki insan psikolojisini ve kurumsal örüntüyü okur. CISO’ya sunulacak teknik raporda kodlar yer alır, ancak müşteriye verilecek gerçek stratejik tavsiye bu kurumsal çöküşü onarmak üzerinedir.

Kendi eğittiğimiz Llama 4 tabanlı ajanımız, işte bu stratejik derinliği sağlamamıza olanak tanır.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Bulguların Kategorize Edilmesi (Risk Matrisi)

Analiz sonucunda ortaya çıkan tablo, hedefin nasıl bir yıkımla karşı karşıya olduğunu özetliyor:

Bölüm 6: Kapanış ve Operasyonel Egemenlik

Kendi analiz altyapınızı kurmak, teknik bir tercih olmanın çok ötesinde, doğrudan bir “operasyonel egemenlik” ilanıdır.

Analiz motorunuz yerel ağınızda, kendi donanımınız üzerinde çalıştığında; hangi verinin analiz edildiğini, prompt’ların nasıl loglandığını, bu loglara kimin erişebildiğini ve verinin ne kadar süreyle saklandığını tamamen siz kontrol edersiniz. Dışarıya kapalı bir ekosistemde çalışmak, operasyonel güvenliğin (OpSec) sadece bir parçası değil, ta kendisidir.

Şunu dürüstçe kabul edelim: Bulut tabanlı AI hizmetleri üretkenliği muazzam ölçüde artırıyor. Bu yadsınamaz bir gerçek. Ancak söz konusu kritik siber güvenlik operasyonları olduğunda, “üretkenlik optimizasyonu” hiçbir zaman veri egemenliğinin önüne geçemez. Bir müşterinin iç ağ topolojisini, IoT cihazlardan çıkardığınız şifre hash’lerini veya kritik altyapı detaylarını üçüncü taraf sunuculara — hizmet sağlayıcı dünyanın en büyük teknoloji devi bile olsa — göndermek, kabul edilemez bir güven transferi ve operasyonel bir zafiyettir.

2026 yılının siber güvenlik analisti, gücünü sadece kullandığı araçlardan değil, o araçlar ve veriler üzerindeki mutlak hakimiyetinden alır. Veri sınırlarını sözleşmelerle değil, katı mühendislik kararlarıyla çizer. Bağımlılıklarını minimize eder ve Zero-Trust felsefesini sadece savunduğu ağlarda değil, kullandığı analiz laboratuvarında da uygular.

Yerel model (Local LLM) çalıştırmak ve kendi yapay zeka ajanınızı inşa etmek, artık teknik uzmanlık gerektiren niş bir uğraş değildir; modern siber güvenliğin tartışılmaz operasyonel güvenlik standardıdır.

Unutmayın: Veriniz sizindir. Analiz motorunuz da öyle olmalı.

Kendi yapay zeka araçlarınızı yapmak için bırakacağım github bağlantısına giderek, sizin için en uygun olanını seçebilirsiniz.

https://deniztktk.github.io/Kendi-Yapay-Zeka-Ajaninizi-Secin/