<![CDATA[TurkTeam | Türk Siber Güvenlik Topluluğu - Mobil Güvenlik]]> https://www.turkteam.org/ Sun, 25 Oct 2026 18:48:39 +0000 MyBB <![CDATA[Signal RingRTC Açığı CVE-2026-113380: Kapattığınız Arama Neden Bitmiyor?]]> https://www.turkteam.org/konu-signal-ringrtc-acigi-cve-2026-113380-kapattiginiz-arama-neden-bitmiyor.html Sun, 25 Oct 2026 11:43:11 +0300 BilgeKagan]]> https://www.turkteam.org/konu-signal-ringrtc-acigi-cve-2026-113380-kapattiginiz-arama-neden-bitmiyor.html [Resim: attachment.php?aid=427]
Selamlar,

Signal, kötü niyetli bir arayanın, kullanıcı aramayı kapattıktan sonra bile ses ve video akışını açık tutmasına izin verebilen kritik bir açığı kapattı. CVE-2026-113380 (CVSS 9.3) olarak izlenen açık, Signal'in sesli/görüntülü aramalarda kullandığı açık kaynaklı RingRTC kütüphanesini etkiliyor. SecurityWeek konuyu aktardı. Bu, "kapat" düğmesinin neden her zaman garanti olmadığını gösteren öğretici bir örnek. Burada açığı ve kullanıcı önlemlerini ele alıyorum.

Konuda anlatılacaklar
  1. Açık ne yapıyor?
  2. Teknik neden: FSM kuyruğu
  3. Etkilenen ve düzeltilmiş sürümler
  4. Gerçek dünya riski
  5. Kullanıcı önlemleri

1. Açık ne yapıyor?
Normalde aramayı kapattığınızda mikrofon ve kamera kapanır. Bu açıkta uzaktaki bir katılımcı, aramanın olay kuyruğunu doldurarak kapatma işlemini sonsuza dek bekletebiliyor. Sonuç: kullanıcı aramayı bitirdiğini sanırken ses (ve muhtemelen video) akmaya devam ediyor.

2. Teknik neden
RingRTC, aramayı WebRTC tabanlı bir Sonlu Durum Makinesi (Finite State Machine, FSM) ile yönetiyor. GitHub yazısına göre sorun üç eksiklikten kaynaklanıyor:
  • Kapatma (hangup), bir "öldür" anahtarı gibi değil, FSM olay kuyruğuna eklenen sıradan bir olay olarak ele alınıyordu.
  • Uzak taraftan gelen olaylar için hız sınırı (rate limit) yoktu.
  • Kapatma olayının önceliği yoktu.
Araştırmacının ifadesiyle: kuyruğu doldurun, kapatma saldırganın gürültüsünün arkasında sonsuza dek bekler; böylece arama (mikrofon, belki kamera) hiç sonlandırılmaz.

3. Etkilenen ve düzeltilmiş sürümler
Açık RingRTC 2.72.0 ile (4 Eylül'de yayımlandı) giderildi. GHSA kaydına ve haberlere göre etkilenen uygulama sürümleri:
Kod:
Android : 8.27.0 öncesi iOS : 8.30.0 öncesi Desktop : 8.29.0 öncesi
Signal, çözümü, arama sonlandırma isteklerinin FSM kuyruğunda takılı kalmamasını ve bağımsız olarak algılanmasını sağlayarak uyguladı. NIST, CVE'yi NVD'ye ekledi. Vahşi doğada sömürü raporu yok.

4. Gerçek dünya riski
Saldırganın, aramayı kabul ettiğiniz bir kişi olması gerektiği için risk, rastgele herkese açık değil. Ancak hedefli gözetim senaryolarında ciddi bir gizlilik tehdidi: kurban aramayı bitirdiğini düşünürken ortam sesi dinlenmeye devam edebilir.

5. Kullanıcı önlemleri
  1. Signal'i tüm cihazlarınızda hemen güncelleyin. Android 8.27.0+, iOS 8.30.0+, Desktop 8.29.0+ hedefleyin.
  2. Arama göstergesini kontrol edin. Güncelleyemiyorsanız, kapattıktan sonra aramanın gerçekten bittiğini (gösterge, mikrofon ikonu) doğrulayın.
  3. Şüpheli kişilerden arama kabul etmeyin. Saldırı, karşı tarafın aramada olmasını gerektiriyor.
  4. Hassas görüşmelerde uygulama tamamen kapanana kadar ortam güvenliğine dikkat edin.

Sonuç
Bu açık, "kullanıcı kapattı" ile "sistem gerçekten kapattı" arasındaki farkın güvenlik açısından ne kadar kritik olabileceğini gösteriyor. Kapatma, bir olay değil, öncelikli bir kesme (interrupt) olmalıydı. Signal uygulamalarınızı güncel tutuyor musunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   11-t11-signal-ringrtc-cve.png (Dosya Boyutu: 115.85 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=427]
Selamlar,

Signal, kötü niyetli bir arayanın, kullanıcı aramayı kapattıktan sonra bile ses ve video akışını açık tutmasına izin verebilen kritik bir açığı kapattı. CVE-2026-113380 (CVSS 9.3) olarak izlenen açık, Signal'in sesli/görüntülü aramalarda kullandığı açık kaynaklı RingRTC kütüphanesini etkiliyor. SecurityWeek konuyu aktardı. Bu, "kapat" düğmesinin neden her zaman garanti olmadığını gösteren öğretici bir örnek. Burada açığı ve kullanıcı önlemlerini ele alıyorum.

Konuda anlatılacaklar
  1. Açık ne yapıyor?
  2. Teknik neden: FSM kuyruğu
  3. Etkilenen ve düzeltilmiş sürümler
  4. Gerçek dünya riski
  5. Kullanıcı önlemleri

1. Açık ne yapıyor?
Normalde aramayı kapattığınızda mikrofon ve kamera kapanır. Bu açıkta uzaktaki bir katılımcı, aramanın olay kuyruğunu doldurarak kapatma işlemini sonsuza dek bekletebiliyor. Sonuç: kullanıcı aramayı bitirdiğini sanırken ses (ve muhtemelen video) akmaya devam ediyor.

2. Teknik neden
RingRTC, aramayı WebRTC tabanlı bir Sonlu Durum Makinesi (Finite State Machine, FSM) ile yönetiyor. GitHub yazısına göre sorun üç eksiklikten kaynaklanıyor:
  • Kapatma (hangup), bir "öldür" anahtarı gibi değil, FSM olay kuyruğuna eklenen sıradan bir olay olarak ele alınıyordu.
  • Uzak taraftan gelen olaylar için hız sınırı (rate limit) yoktu.
  • Kapatma olayının önceliği yoktu.
Araştırmacının ifadesiyle: kuyruğu doldurun, kapatma saldırganın gürültüsünün arkasında sonsuza dek bekler; böylece arama (mikrofon, belki kamera) hiç sonlandırılmaz.

3. Etkilenen ve düzeltilmiş sürümler
Açık RingRTC 2.72.0 ile (4 Eylül'de yayımlandı) giderildi. GHSA kaydına ve haberlere göre etkilenen uygulama sürümleri:
Kod:
Android : 8.27.0 öncesi iOS : 8.30.0 öncesi Desktop : 8.29.0 öncesi
Signal, çözümü, arama sonlandırma isteklerinin FSM kuyruğunda takılı kalmamasını ve bağımsız olarak algılanmasını sağlayarak uyguladı. NIST, CVE'yi NVD'ye ekledi. Vahşi doğada sömürü raporu yok.

4. Gerçek dünya riski
Saldırganın, aramayı kabul ettiğiniz bir kişi olması gerektiği için risk, rastgele herkese açık değil. Ancak hedefli gözetim senaryolarında ciddi bir gizlilik tehdidi: kurban aramayı bitirdiğini düşünürken ortam sesi dinlenmeye devam edebilir.

5. Kullanıcı önlemleri
  1. Signal'i tüm cihazlarınızda hemen güncelleyin. Android 8.27.0+, iOS 8.30.0+, Desktop 8.29.0+ hedefleyin.
  2. Arama göstergesini kontrol edin. Güncelleyemiyorsanız, kapattıktan sonra aramanın gerçekten bittiğini (gösterge, mikrofon ikonu) doğrulayın.
  3. Şüpheli kişilerden arama kabul etmeyin. Saldırı, karşı tarafın aramada olmasını gerektiriyor.
  4. Hassas görüşmelerde uygulama tamamen kapanana kadar ortam güvenliğine dikkat edin.

Sonuç
Bu açık, "kullanıcı kapattı" ile "sistem gerçekten kapattı" arasındaki farkın güvenlik açısından ne kadar kritik olabileceğini gösteriyor. Kapatma, bir olay değil, öncelikli bir kesme (interrupt) olmalıydı. Signal uygulamalarınızı güncel tutuyor musunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   11-t11-signal-ringrtc-cve.png (Dosya Boyutu: 115.85 KB / İndirme Sayısı: 1) ]]> <![CDATA[Frida ile Android Dinamik Analiz 2026: Lab Uygulamanızda Çalışma Zamanı İnceleme]]> https://www.turkteam.org/konu-frida-ile-android-dinamik-analiz-2026-lab-uygulamanizda-calisma-zamani-inceleme.html Sun, 18 Oct 2026 20:11:14 +0300 Tonyukuk]]> https://www.turkteam.org/konu-frida-ile-android-dinamik-analiz-2026-lab-uygulamanizda-calisma-zamani-inceleme.html [Resim: attachment.php?aid=220]
Merhaba arkadaşlar,

Statik analiz bir uygulamanın kodunu çalıştırmadan inceler; ama bazı davranışlar ancak uygulama çalışırken ortaya çıkar: hangi fonksiyonun ne değer döndürdüğü, SSL doğrulamasının gerçekte yapılıp yapılmadığı, bir kök kontrolünün nasıl çalıştığı. İşte burada dinamik analiz ve Frida devreye girer. Frida, çalışan bir sürece kod enjekte ederek fonksiyonları canlı izlemenizi (hooking) sağlayan açık kaynak bir araçtır. Bu rehberde Frida'yı resmi belgelerine dayanarak kurmayı ve yalnızca kendi geliştirdiğiniz, kendi cihazınızdaki bir lab uygulaması üzerinde temel dinamik analizi anlatıyorum. Başkasına ait uygulamalarda kullanmak yasa ve lisans ihlalidir.

Konuda Anlatılacaklar
  1. Dinamik analiz ve hooking nedir?
  2. Lab ortamı: emülatör ve kendi uygulamanız
  3. Frida kurulumu (host ve cihaz)
  4. Süreçleri listeleme ve bağlanma
  5. İlk hook: bir fonksiyonu izleme
  6. Örnek: kendi kök kontrolünüzü gözlemleme
  7. Etik sınırlar ve savunma dersleri

Dinamik Analiz ve Hooking Nedir?

Dinamik analiz, uygulamayı gerçek/sanal bir cihazda çalıştırırken davranışını inceler. Hooking, bir fonksiyonun çağrılmasını araya girerek yakalamak; argümanlarını, dönüş değerini görmek ve isterseniz değiştirmektir. Frida bunu, hedef sürece bir ajan (JavaScript ile yazılmış) enjekte ederek yapar. Bu teknik hem saldırı hem savunma tarafında kullanılır; biz savunma ve kendi kodunu anlama amacıyla ele alıyoruz.

[Resim: attachment.php?aid=221]

Lab Ortamı: Emülatör ve Kendi Uygulamanız

Güvenli ve yasal bir lab için:
  • Android Studio ile bir Android Emülatör (tercihen Google APIs imajı, root erişimi kolay olan) kurun.
  • Analiz edeceğiniz uygulama sizin yazdığınız basit bir test uygulaması olsun. OWASP'ın MASTG projesi, tam da bu amaç için savunmasız örnek uygulamalar (MAS Test Apps) sağlar.
  • Asla Play Store'dan indirdiğiniz üçüncü taraf bir uygulamaya müdahale etmeyin.

Frida Kurulumu (Host ve Cihaz)

Frida iki parçadan oluşur: bilgisayarınızdaki komut satırı araçları ve cihazdaki frida-server. Resmi belgelere göre host tarafı:

Kod:
pip install frida-tools frida --version

frida-tools; frida, frida-ps, frida-trace gibi komutları içerir. Cihaz tarafı için cihazın mimarisine uygun frida-server sürümünü resmi GitHub sürümlerinden indirip (yalnızca kendi root'lu emülatörünüze) yükleyin:

Kod:
adb push frida-server /data/local/tmp/ adb shell "su -c 'chmod 755 /data/local/tmp/frida-server'" adb shell "su -c '/data/local/tmp/frida-server &'"

[Resim: attachment.php?aid=222]

Süreçleri Listeleme ve Bağlanma

frida-server çalışırken, USB üzerinden bağlı cihazdaki uygulamaları listeleyin. Resmi belgelere göre -U USB cihazını, -a yüklü uygulamaları, -i ise ek bilgiyi gösterir:

Kod:
frida-ps -U frida-ps -Uai

İkinci komut, yüklü uygulamaları paket adlarıyla birlikte listeler. Kendi test uygulamanızın paket adını (örneğin org.benim.lab) buradan not alın.

İlk Hook: Bir Fonksiyonu İzleme

Basit bir Frida ajanı JavaScript ile yazılır. Aşağıdaki script, kendi uygulamanızdaki bir Java metodunu yakalayıp argüman ve dönüş değerini yazdırır. Java.perform ve Java.use, Frida'nın resmi JavaScript API'sinin parçasıdır:

Kod:
// izle.js Java.perform(function () { var Hesap = Java.use("org.benim.lab.Hesaplayici"); Hesap.topla.implementation = function (a, b) { console.log("[+] topla cagrildi: a=" + a + " b=" + b); var sonuc = this.topla(a, b); console.log("[+] donen deger: " + sonuc); return sonuc; }; });

Scripti kendi uygulamanıza enjekte ederek çalıştırın:

Kod:
frida -U -l izle.js -f org.benim.lab

-f uygulamayı Frida'nın başlatmasını sağlar (spawn), böylece en baştan izlersiniz. Konsola, uygulama o metodu her çağırdığında argümanlar ve dönüş değeri düşer.

Örnek: Kendi Kök Kontrolünüzü Gözlemleme

Birçok uygulama cihazın root'lu olup olmadığını kontrol eder. Kendi lab uygulamanıza basit bir kök kontrolü fonksiyonu yazıp, Frida ile bu fonksiyonun ne döndürdüğünü gözlemleyin:

Kod:
// kok-gozlem.js Java.perform(function () { var G = Java.use("org.benim.lab.GuvenlikKontrol"); G.rootluMu.implementation = function () { var r = this.rootluMu(); console.log("[*] rootluMu() -> " + r); return r; // sadece gozlem; degeri degistirmiyoruz }; });

[Resim: attachment.php?aid=223]

Buradaki önemli savunma dersi: Dinamik analizle kök kontrolü gibi istemci tarafı korumaların değiştirilebildiğini görürsünüz. Bu yüzden güvenlik kararlarını yalnızca istemciye bırakmayın; kritik doğrulamaları sunucu tarafında da yapın. Kendi uygulamanızda bu zafiyeti görmek, onu nasıl sertleştireceğinizi öğretir.

İleri Seviye: Etik Sınırlar ve Savunma Dersleri

Frida çok güçlü bir araçtır ve bu güç sorumluluk getirir:
  • Yalnızca kendi uygulamalarınızda veya yazılı izinli (bug bounty kapsamı dahilinde) hedeflerde kullanın.
  • İstemci tarafı korumalar (kök tespiti, SSL pinning, kurcalama tespiti) saldırganı yavaşlatır ama tek başına yeterli değildir.
  • Savunma için: kritik iş mantığını ve yetkilendirmeyi sunucuda tutun, hassas verileri istemcide tutmayın, obfuscation ve bütünlük kontrolleri ekleyin.
  • Dinamik analiz bulgularınızı OWASP MASTG testleriyle eşleştirerek raporlayın.

Frida ayrıca iOS, Windows, Linux ve macOS süreçlerinde de çalışır; mantık her yerde aynıdır: çalışan koda araya girip davranışı gözlemlemek.

Sonuç

Frida, bir uygulamanın çalışırken gerçekte ne yaptığını görmenin en etkili yollarından biri. Kendi lab uygulamanızda frida-tools ve frida-server ile kurulum yapın, frida-ps ile süreçleri bulun, basit bir Java.perform hook'u ile fonksiyonları izleyin ve istemci tarafı korumaların neden tek başına yetmediğini kendi gözünüzle görün. Bu bilgiyi yalnızca kendi kodunuzu güçlendirmek için kullanın. Siz Frida ile hangi senaryoları test ettiniz? Yorumlarda paylaşın.

Kaynakça
Yasal Uyarı

Frida ve dinamik analiz teknikleri yalnızca kendinize ait uygulamalar, kendi cihazınız veya sahibinden yazılı izin aldığınız (ör. bug bounty kapsamındaki) hedefler üzerinde kullanılmalıdır. Başkasına ait uygulama veya cihazlara izinsiz müdahale, lisans ihlaline ve 5237 sayılı Türk Ceza Kanunu'nun 243, 244 ve 245. maddeleri kapsamında suça yol açar. TurkTeam yalnızca savunma ve eğitim amaçlı paylaşımları destekler.

Görsel: TurkTeam özgün kapak ve diyagramları

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

.png   11-cover.png (Dosya Boyutu: 231.44 KB / İndirme Sayısı: 9)

.jpg   11-a.jpg (Dosya Boyutu: 57.35 KB / İndirme Sayısı: 10)

.jpg   11-b.jpg (Dosya Boyutu: 59.76 KB / İndirme Sayısı: 9)

.jpg   11-c.jpg (Dosya Boyutu: 54.72 KB / İndirme Sayısı: 9) ]]> [Resim: attachment.php?aid=220]
Merhaba arkadaşlar,

Statik analiz bir uygulamanın kodunu çalıştırmadan inceler; ama bazı davranışlar ancak uygulama çalışırken ortaya çıkar: hangi fonksiyonun ne değer döndürdüğü, SSL doğrulamasının gerçekte yapılıp yapılmadığı, bir kök kontrolünün nasıl çalıştığı. İşte burada dinamik analiz ve Frida devreye girer. Frida, çalışan bir sürece kod enjekte ederek fonksiyonları canlı izlemenizi (hooking) sağlayan açık kaynak bir araçtır. Bu rehberde Frida'yı resmi belgelerine dayanarak kurmayı ve yalnızca kendi geliştirdiğiniz, kendi cihazınızdaki bir lab uygulaması üzerinde temel dinamik analizi anlatıyorum. Başkasına ait uygulamalarda kullanmak yasa ve lisans ihlalidir.

Konuda Anlatılacaklar
  1. Dinamik analiz ve hooking nedir?
  2. Lab ortamı: emülatör ve kendi uygulamanız
  3. Frida kurulumu (host ve cihaz)
  4. Süreçleri listeleme ve bağlanma
  5. İlk hook: bir fonksiyonu izleme
  6. Örnek: kendi kök kontrolünüzü gözlemleme
  7. Etik sınırlar ve savunma dersleri

Dinamik Analiz ve Hooking Nedir?

Dinamik analiz, uygulamayı gerçek/sanal bir cihazda çalıştırırken davranışını inceler. Hooking, bir fonksiyonun çağrılmasını araya girerek yakalamak; argümanlarını, dönüş değerini görmek ve isterseniz değiştirmektir. Frida bunu, hedef sürece bir ajan (JavaScript ile yazılmış) enjekte ederek yapar. Bu teknik hem saldırı hem savunma tarafında kullanılır; biz savunma ve kendi kodunu anlama amacıyla ele alıyoruz.

[Resim: attachment.php?aid=221]

Lab Ortamı: Emülatör ve Kendi Uygulamanız

Güvenli ve yasal bir lab için:
  • Android Studio ile bir Android Emülatör (tercihen Google APIs imajı, root erişimi kolay olan) kurun.
  • Analiz edeceğiniz uygulama sizin yazdığınız basit bir test uygulaması olsun. OWASP'ın MASTG projesi, tam da bu amaç için savunmasız örnek uygulamalar (MAS Test Apps) sağlar.
  • Asla Play Store'dan indirdiğiniz üçüncü taraf bir uygulamaya müdahale etmeyin.

Frida Kurulumu (Host ve Cihaz)

Frida iki parçadan oluşur: bilgisayarınızdaki komut satırı araçları ve cihazdaki frida-server. Resmi belgelere göre host tarafı:

Kod:
pip install frida-tools frida --version

frida-tools; frida, frida-ps, frida-trace gibi komutları içerir. Cihaz tarafı için cihazın mimarisine uygun frida-server sürümünü resmi GitHub sürümlerinden indirip (yalnızca kendi root'lu emülatörünüze) yükleyin:

Kod:
adb push frida-server /data/local/tmp/ adb shell "su -c 'chmod 755 /data/local/tmp/frida-server'" adb shell "su -c '/data/local/tmp/frida-server &'"

[Resim: attachment.php?aid=222]

Süreçleri Listeleme ve Bağlanma

frida-server çalışırken, USB üzerinden bağlı cihazdaki uygulamaları listeleyin. Resmi belgelere göre -U USB cihazını, -a yüklü uygulamaları, -i ise ek bilgiyi gösterir:

Kod:
frida-ps -U frida-ps -Uai

İkinci komut, yüklü uygulamaları paket adlarıyla birlikte listeler. Kendi test uygulamanızın paket adını (örneğin org.benim.lab) buradan not alın.

İlk Hook: Bir Fonksiyonu İzleme

Basit bir Frida ajanı JavaScript ile yazılır. Aşağıdaki script, kendi uygulamanızdaki bir Java metodunu yakalayıp argüman ve dönüş değerini yazdırır. Java.perform ve Java.use, Frida'nın resmi JavaScript API'sinin parçasıdır:

Kod:
// izle.js Java.perform(function () { var Hesap = Java.use("org.benim.lab.Hesaplayici"); Hesap.topla.implementation = function (a, b) { console.log("[+] topla cagrildi: a=" + a + " b=" + b); var sonuc = this.topla(a, b); console.log("[+] donen deger: " + sonuc); return sonuc; }; });

Scripti kendi uygulamanıza enjekte ederek çalıştırın:

Kod:
frida -U -l izle.js -f org.benim.lab

-f uygulamayı Frida'nın başlatmasını sağlar (spawn), böylece en baştan izlersiniz. Konsola, uygulama o metodu her çağırdığında argümanlar ve dönüş değeri düşer.

Örnek: Kendi Kök Kontrolünüzü Gözlemleme

Birçok uygulama cihazın root'lu olup olmadığını kontrol eder. Kendi lab uygulamanıza basit bir kök kontrolü fonksiyonu yazıp, Frida ile bu fonksiyonun ne döndürdüğünü gözlemleyin:

Kod:
// kok-gozlem.js Java.perform(function () { var G = Java.use("org.benim.lab.GuvenlikKontrol"); G.rootluMu.implementation = function () { var r = this.rootluMu(); console.log("[*] rootluMu() -> " + r); return r; // sadece gozlem; degeri degistirmiyoruz }; });

[Resim: attachment.php?aid=223]

Buradaki önemli savunma dersi: Dinamik analizle kök kontrolü gibi istemci tarafı korumaların değiştirilebildiğini görürsünüz. Bu yüzden güvenlik kararlarını yalnızca istemciye bırakmayın; kritik doğrulamaları sunucu tarafında da yapın. Kendi uygulamanızda bu zafiyeti görmek, onu nasıl sertleştireceğinizi öğretir.

İleri Seviye: Etik Sınırlar ve Savunma Dersleri

Frida çok güçlü bir araçtır ve bu güç sorumluluk getirir:
  • Yalnızca kendi uygulamalarınızda veya yazılı izinli (bug bounty kapsamı dahilinde) hedeflerde kullanın.
  • İstemci tarafı korumalar (kök tespiti, SSL pinning, kurcalama tespiti) saldırganı yavaşlatır ama tek başına yeterli değildir.
  • Savunma için: kritik iş mantığını ve yetkilendirmeyi sunucuda tutun, hassas verileri istemcide tutmayın, obfuscation ve bütünlük kontrolleri ekleyin.
  • Dinamik analiz bulgularınızı OWASP MASTG testleriyle eşleştirerek raporlayın.

Frida ayrıca iOS, Windows, Linux ve macOS süreçlerinde de çalışır; mantık her yerde aynıdır: çalışan koda araya girip davranışı gözlemlemek.

Sonuç

Frida, bir uygulamanın çalışırken gerçekte ne yaptığını görmenin en etkili yollarından biri. Kendi lab uygulamanızda frida-tools ve frida-server ile kurulum yapın, frida-ps ile süreçleri bulun, basit bir Java.perform hook'u ile fonksiyonları izleyin ve istemci tarafı korumaların neden tek başına yetmediğini kendi gözünüzle görün. Bu bilgiyi yalnızca kendi kodunuzu güçlendirmek için kullanın. Siz Frida ile hangi senaryoları test ettiniz? Yorumlarda paylaşın.

Kaynakça
Yasal Uyarı

Frida ve dinamik analiz teknikleri yalnızca kendinize ait uygulamalar, kendi cihazınız veya sahibinden yazılı izin aldığınız (ör. bug bounty kapsamındaki) hedefler üzerinde kullanılmalıdır. Başkasına ait uygulama veya cihazlara izinsiz müdahale, lisans ihlaline ve 5237 sayılı Türk Ceza Kanunu'nun 243, 244 ve 245. maddeleri kapsamında suça yol açar. TurkTeam yalnızca savunma ve eğitim amaçlı paylaşımları destekler.

Görsel: TurkTeam özgün kapak ve diyagramları

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

.png   11-cover.png (Dosya Boyutu: 231.44 KB / İndirme Sayısı: 9)

.jpg   11-a.jpg (Dosya Boyutu: 57.35 KB / İndirme Sayısı: 10)

.jpg   11-b.jpg (Dosya Boyutu: 59.76 KB / İndirme Sayısı: 9)

.jpg   11-c.jpg (Dosya Boyutu: 54.72 KB / İndirme Sayısı: 9) ]]> <![CDATA[OWASP MASVS ve MASTG 2026: Mobil Uygulama Güvenliği Standardı ve Test Rehberi]]> https://www.turkteam.org/konu-owasp-masvs-ve-mastg-2026-mobil-uygulama-guvenligi-standardi-ve-test-rehberi.html Sun, 18 Oct 2026 19:41:50 +0300 Tonyukuk]]> https://www.turkteam.org/konu-owasp-masvs-ve-mastg-2026-mobil-uygulama-guvenligi-standardi-ve-test-rehberi.html [Resim: attachment.php?aid=207]
Merhaba arkadaşlar,

Mobil uygulama güvenliği test ederken "nereye bakmalıyım, bir uygulama ne zaman yeterince güvenli?" sorusunun standart bir cevabı var: OWASP Mobile Application Security (MAS) projesi. Bu proje; neyin test edileceğini söyleyen MASVS'yi, nasıl test edileceğini anlatan MASTG'yi ve ikisini birbirine bağlayan MASWE zayıflık kataloğunu içerir. 2026, bu proje için büyük bir yıl oldu: MASTG v2.0.0 (Haziran 2026) ve MASWE v1.0.0 (Ağustos 2026) ilk kararlı sürümleriyle yayımlandı. Bu rehberde bu üç bileşeni resmi kaynaklara dayanarak açıklıyor ve kendi uygulamanız için nasıl bir test planı kuracağınızı gösteriyorum.

Konuda Anlatılacaklar
  1. OWASP MAS projesi nedir?
  2. MASVS: kontrol kategorileri
  3. MASTG v2.0.0: atomik test yapısı
  4. MASWE v1.0.0: zayıflık kataloğu
  5. İzlenebilirlik zinciri
  6. Test profilleri (L1, L2, R)
  7. Kendi uygulamanız için test planı

OWASP MAS Projesi Nedir?

OWASP MAS, mobil uygulama güvenliği için fiili dünya standardıdır. Google'ın MASA programı (App Defense Alliance), CREST OVS, NIST SP 800-163r1 ve 800-218 gibi birçok program bu projeyi referans alır. Üç ana bileşeni vardır: MASVS (standart), MASTG (test rehberi) ve MASWE (zayıflık numaralandırması). 2022'de proje adı MSTG'den MAS'a değişti ve o zamandan beri modüler, izlenebilir bir yapıya dönüştü.

[Resim: attachment.php?aid=208]

MASVS: Kontrol Kategorileri

Mobile Application Security Verification Standard (MASVS, güncel sürüm v2.1.0), platformdan bağımsız kontrolleri kategoriler halinde tanımlar:
  • MASVS-STORAGE: Hassas verinin cihazda güvenli saklanması.
  • MASVS-CRYPTO: Güncel ve doğru kriptografi kullanımı.
  • MASVS-AUTH: Kimlik doğrulama ve yetkilendirme.
  • MASVS-NETWORK: Güvenli ağ iletişimi (TLS vb.).
  • MASVS-PLATFORM: Platform (IPC, WebView, ekran) etkileşimleri.
  • MASVS-CODE: Kod kalitesi ve güncel bağımlılıklar.
  • MASVS-RESILIENCE: Tersine mühendisliğe ve kurcalamaya karşı dayanıklılık.
  • MASVS-PRIVACY: Kullanıcı mahremiyeti (v2.1.0 ile eklendi).
MASVS "ne" sorusunu yanıtlar; her kontrol soyuttur ve bilinçli olarak platform belirtmez.

MASTG v2.0.0: Atomik Test Yapısı

Mobile Application Security Testing Guide (MASTG), kontrolleri nasıl test edeceğinizi gösterir. Resmi duyuruya göre v2.0.0 (Haziran 2026) ilk kararlı, tamamen yeniden yapılandırılmış sürümdür. Eski "kitap bölümü" formatı yerini modüler, kimlikli bileşenlere bıraktı:
  • MASTG-TEST-****: Atomik testler (285 adet).
  • MASTG-DEMO-****: Çalışan kod örnekleriyle gösterimler (152 adet).
  • MASTG-TECH-****: Teknikler (167 adet).
  • MASTG-TOOL-****: Araçlar (135 adet).
  • MASTG-BEST-****: En iyi uygulamalar (72 adet).
Her v2 testi atomik bir kontrol içerir ve sabit bir yapıya sahiptir: üst veri (platform, tür, zayıflık), Overview, Steps, Observation ve Evaluation (geçti/kaldı ölçütü). Bu yapı, testi otomatikleştirmeyi ve raporda kesin biçimde atıf vermeyi mümkün kılar.

[Resim: attachment.php?aid=209]

MASWE v1.0.0: Zayıflık Kataloğu

Mobile Application Security Weakness Enumeration (MASWE), soyut MASVS kontrolleri ile somut MASTG testleri arasındaki boşluğu doldurur; tıpkı yazılım dünyasında CWE'nin yaptığı gibi. Resmi duyuruya göre v1.0.0 (Ağustos 2026) ilk kararlı sürümdür ve 78 zayıflık içerir (MASWE-0001'den MASWE-0078'e, kategorilere göre gruplu). Her zayıflık; tek cümlelik tanım, ortaya çıkma biçimleri (modes of introduction), etki ve azaltma (mitigations) bölümleriyle standart bir yapıdadır. Örneğin MASWE-0001'den 0006'ya kadar MASVS-STORAGE zayıflıkları yer alır.

İzlenebilirlik Zinciri

Üç bileşen tek bir zincir oluşturur:

Kod:
MASVS kontrolü -> MASWE zayifligi -> MASTG testi -> MASTG demo (ne) (hangi zayiflik) (nasil test) (calisir ornek)

Örnek: "Uygulama güncel güçlü kriptografi kullanır" (MASVS-CRYPTO-1) kontrolü, "öngörülebilir rastgele sayı üretimi" (MASWE) zayıflığına, oradan "Android'de güvensiz random API kullanımı" testine (MASTG-TEST), oradan da Random() yerine SecureRandom() kullanımını gösteren bir demoya bağlanır. Bu zincir sayesinde "MASVS-STORAGE-2 başarısız" gibi belirsiz bir ifade yerine, "MASWE-0005 başarısız, ortaya çıkma biçimi: üretimde ayrıntılı loglama" gibi aksiyon alınabilir bir bulgu yazabilirsiniz.

[Resim: attachment.php?aid=210]

Test Profilleri (L1, L2, R)

MASVS v2'de eski L1/L2/R doğrulama seviyeleri, MASTG'ye "test profilleri" olarak taşındı:
  • L1: Tüm uygulamalar için temel güvenlik.
  • L2: Hassas veri işleyen uygulamalar (bankacılık, sağlık) için savunma derinliği.
  • R (Resilience): Tersine mühendislik ve kurcalamaya karşı ek dayanıklılık (ör. DRM, fikri mülkiyet koruması).
Uygulamanızın risk düzeyine göre uygun profili seçip o profildeki testleri çalıştırırsınız. Bir not uygulaması için L1 yeterliyken, bir mobil bankacılık uygulaması L2+R gerektirir.

İleri Seviye: Kendi Uygulamanız İçin Test Planı

Pratik bir yol haritası:
  1. Uygulamanızın risk düzeyine göre bir profil seçin (L1/L2/R).
  2. İlgili MASVS kategorilerini belirleyin (örneğin veri saklayan bir uygulama için STORAGE, CRYPTO, NETWORK öncelikli).
  3. Her kategori için MASTG testlerini uygulayın; statik bulgular için MobSF, dinamik için Frida kullanabilirsiniz.
  4. Her bulguyu ilgili MASWE kimliğiyle etiketleyin ve MASTG-BEST maddesiyle düzeltme önerisi verin.
  5. Sonuçları bir kontrol listesi olarak raporlayın.

OWASP, bu amaçla indirilebilir MAS kontrol listeleri (checklist) de yayımlar; testlerinizi bu listeyle takip etmek, hiçbir kontrolü atlamamanızı sağlar. Tüm testleri yalnızca kendi uygulamanızda veya izinli hedeflerde çalıştırın.

Sonuç

OWASP MAS, mobil güvenlikte "ne, nasıl ve hangi zayıflık" sorularının tamamına standart cevap veren bir çerçeve. 2026'da MASTG v2.0.0 ve MASWE v1.0.0 ile olgunlaştı. Uygulamanızın risk profilini belirleyin, MASVS kategorilerini MASTG testleriyle sınayın ve bulgularınızı MASWE kimlikleriyle raporlayın. Böylece testleriniz tekrarlanabilir, otomatikleştirilebilir ve savunulabilir olur. Siz hangi MASVS kategorisini en kritik görüyorsunuz? Yorumlarda tartışalım.

Kaynakça
Yasal Uyarı

Bu rehberdeki test teknikleri yalnızca kendinize ait veya sahibinden yazılı izin aldığınız uygulamalar üzerinde uygulanmalıdır. Başkasına ait uygulamaları izinsiz test etmek, lisans ihlaline ve 5237 sayılı Türk Ceza Kanunu'nun 243, 244 ve 245. maddeleri kapsamında sorumluluğa yol açar. TurkTeam yalnızca savunma ve eğitim amaçlı paylaşımları destekler.

Görsel: TurkTeam özgün kapak ve diyagramları

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

.png   12-cover.png (Dosya Boyutu: 248.97 KB / İndirme Sayısı: 10)

.jpg   12-a.jpg (Dosya Boyutu: 80.63 KB / İndirme Sayısı: 9)

.jpg   12-b.jpg (Dosya Boyutu: 47.85 KB / İndirme Sayısı: 11)

.jpg   12-c.jpg (Dosya Boyutu: 82.65 KB / İndirme Sayısı: 9) ]]> [Resim: attachment.php?aid=207]
Merhaba arkadaşlar,

Mobil uygulama güvenliği test ederken "nereye bakmalıyım, bir uygulama ne zaman yeterince güvenli?" sorusunun standart bir cevabı var: OWASP Mobile Application Security (MAS) projesi. Bu proje; neyin test edileceğini söyleyen MASVS'yi, nasıl test edileceğini anlatan MASTG'yi ve ikisini birbirine bağlayan MASWE zayıflık kataloğunu içerir. 2026, bu proje için büyük bir yıl oldu: MASTG v2.0.0 (Haziran 2026) ve MASWE v1.0.0 (Ağustos 2026) ilk kararlı sürümleriyle yayımlandı. Bu rehberde bu üç bileşeni resmi kaynaklara dayanarak açıklıyor ve kendi uygulamanız için nasıl bir test planı kuracağınızı gösteriyorum.

Konuda Anlatılacaklar
  1. OWASP MAS projesi nedir?
  2. MASVS: kontrol kategorileri
  3. MASTG v2.0.0: atomik test yapısı
  4. MASWE v1.0.0: zayıflık kataloğu
  5. İzlenebilirlik zinciri
  6. Test profilleri (L1, L2, R)
  7. Kendi uygulamanız için test planı

OWASP MAS Projesi Nedir?

OWASP MAS, mobil uygulama güvenliği için fiili dünya standardıdır. Google'ın MASA programı (App Defense Alliance), CREST OVS, NIST SP 800-163r1 ve 800-218 gibi birçok program bu projeyi referans alır. Üç ana bileşeni vardır: MASVS (standart), MASTG (test rehberi) ve MASWE (zayıflık numaralandırması). 2022'de proje adı MSTG'den MAS'a değişti ve o zamandan beri modüler, izlenebilir bir yapıya dönüştü.

[Resim: attachment.php?aid=208]

MASVS: Kontrol Kategorileri

Mobile Application Security Verification Standard (MASVS, güncel sürüm v2.1.0), platformdan bağımsız kontrolleri kategoriler halinde tanımlar:
  • MASVS-STORAGE: Hassas verinin cihazda güvenli saklanması.
  • MASVS-CRYPTO: Güncel ve doğru kriptografi kullanımı.
  • MASVS-AUTH: Kimlik doğrulama ve yetkilendirme.
  • MASVS-NETWORK: Güvenli ağ iletişimi (TLS vb.).
  • MASVS-PLATFORM: Platform (IPC, WebView, ekran) etkileşimleri.
  • MASVS-CODE: Kod kalitesi ve güncel bağımlılıklar.
  • MASVS-RESILIENCE: Tersine mühendisliğe ve kurcalamaya karşı dayanıklılık.
  • MASVS-PRIVACY: Kullanıcı mahremiyeti (v2.1.0 ile eklendi).
MASVS "ne" sorusunu yanıtlar; her kontrol soyuttur ve bilinçli olarak platform belirtmez.

MASTG v2.0.0: Atomik Test Yapısı

Mobile Application Security Testing Guide (MASTG), kontrolleri nasıl test edeceğinizi gösterir. Resmi duyuruya göre v2.0.0 (Haziran 2026) ilk kararlı, tamamen yeniden yapılandırılmış sürümdür. Eski "kitap bölümü" formatı yerini modüler, kimlikli bileşenlere bıraktı:
  • MASTG-TEST-****: Atomik testler (285 adet).
  • MASTG-DEMO-****: Çalışan kod örnekleriyle gösterimler (152 adet).
  • MASTG-TECH-****: Teknikler (167 adet).
  • MASTG-TOOL-****: Araçlar (135 adet).
  • MASTG-BEST-****: En iyi uygulamalar (72 adet).
Her v2 testi atomik bir kontrol içerir ve sabit bir yapıya sahiptir: üst veri (platform, tür, zayıflık), Overview, Steps, Observation ve Evaluation (geçti/kaldı ölçütü). Bu yapı, testi otomatikleştirmeyi ve raporda kesin biçimde atıf vermeyi mümkün kılar.

[Resim: attachment.php?aid=209]

MASWE v1.0.0: Zayıflık Kataloğu

Mobile Application Security Weakness Enumeration (MASWE), soyut MASVS kontrolleri ile somut MASTG testleri arasındaki boşluğu doldurur; tıpkı yazılım dünyasında CWE'nin yaptığı gibi. Resmi duyuruya göre v1.0.0 (Ağustos 2026) ilk kararlı sürümdür ve 78 zayıflık içerir (MASWE-0001'den MASWE-0078'e, kategorilere göre gruplu). Her zayıflık; tek cümlelik tanım, ortaya çıkma biçimleri (modes of introduction), etki ve azaltma (mitigations) bölümleriyle standart bir yapıdadır. Örneğin MASWE-0001'den 0006'ya kadar MASVS-STORAGE zayıflıkları yer alır.

İzlenebilirlik Zinciri

Üç bileşen tek bir zincir oluşturur:

Kod:
MASVS kontrolü -> MASWE zayifligi -> MASTG testi -> MASTG demo (ne) (hangi zayiflik) (nasil test) (calisir ornek)

Örnek: "Uygulama güncel güçlü kriptografi kullanır" (MASVS-CRYPTO-1) kontrolü, "öngörülebilir rastgele sayı üretimi" (MASWE) zayıflığına, oradan "Android'de güvensiz random API kullanımı" testine (MASTG-TEST), oradan da Random() yerine SecureRandom() kullanımını gösteren bir demoya bağlanır. Bu zincir sayesinde "MASVS-STORAGE-2 başarısız" gibi belirsiz bir ifade yerine, "MASWE-0005 başarısız, ortaya çıkma biçimi: üretimde ayrıntılı loglama" gibi aksiyon alınabilir bir bulgu yazabilirsiniz.

[Resim: attachment.php?aid=210]

Test Profilleri (L1, L2, R)

MASVS v2'de eski L1/L2/R doğrulama seviyeleri, MASTG'ye "test profilleri" olarak taşındı:
  • L1: Tüm uygulamalar için temel güvenlik.
  • L2: Hassas veri işleyen uygulamalar (bankacılık, sağlık) için savunma derinliği.
  • R (Resilience): Tersine mühendislik ve kurcalamaya karşı ek dayanıklılık (ör. DRM, fikri mülkiyet koruması).
Uygulamanızın risk düzeyine göre uygun profili seçip o profildeki testleri çalıştırırsınız. Bir not uygulaması için L1 yeterliyken, bir mobil bankacılık uygulaması L2+R gerektirir.

İleri Seviye: Kendi Uygulamanız İçin Test Planı

Pratik bir yol haritası:
  1. Uygulamanızın risk düzeyine göre bir profil seçin (L1/L2/R).
  2. İlgili MASVS kategorilerini belirleyin (örneğin veri saklayan bir uygulama için STORAGE, CRYPTO, NETWORK öncelikli).
  3. Her kategori için MASTG testlerini uygulayın; statik bulgular için MobSF, dinamik için Frida kullanabilirsiniz.
  4. Her bulguyu ilgili MASWE kimliğiyle etiketleyin ve MASTG-BEST maddesiyle düzeltme önerisi verin.
  5. Sonuçları bir kontrol listesi olarak raporlayın.

OWASP, bu amaçla indirilebilir MAS kontrol listeleri (checklist) de yayımlar; testlerinizi bu listeyle takip etmek, hiçbir kontrolü atlamamanızı sağlar. Tüm testleri yalnızca kendi uygulamanızda veya izinli hedeflerde çalıştırın.

Sonuç

OWASP MAS, mobil güvenlikte "ne, nasıl ve hangi zayıflık" sorularının tamamına standart cevap veren bir çerçeve. 2026'da MASTG v2.0.0 ve MASWE v1.0.0 ile olgunlaştı. Uygulamanızın risk profilini belirleyin, MASVS kategorilerini MASTG testleriyle sınayın ve bulgularınızı MASWE kimlikleriyle raporlayın. Böylece testleriniz tekrarlanabilir, otomatikleştirilebilir ve savunulabilir olur. Siz hangi MASVS kategorisini en kritik görüyorsunuz? Yorumlarda tartışalım.

Kaynakça
Yasal Uyarı

Bu rehberdeki test teknikleri yalnızca kendinize ait veya sahibinden yazılı izin aldığınız uygulamalar üzerinde uygulanmalıdır. Başkasına ait uygulamaları izinsiz test etmek, lisans ihlaline ve 5237 sayılı Türk Ceza Kanunu'nun 243, 244 ve 245. maddeleri kapsamında sorumluluğa yol açar. TurkTeam yalnızca savunma ve eğitim amaçlı paylaşımları destekler.

Görsel: TurkTeam özgün kapak ve diyagramları

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

.png   12-cover.png (Dosya Boyutu: 248.97 KB / İndirme Sayısı: 10)

.jpg   12-a.jpg (Dosya Boyutu: 80.63 KB / İndirme Sayısı: 9)

.jpg   12-b.jpg (Dosya Boyutu: 47.85 KB / İndirme Sayısı: 11)

.jpg   12-c.jpg (Dosya Boyutu: 82.65 KB / İndirme Sayısı: 9) ]]> <![CDATA[MobSF ile Android APK Statik Analizi 2026: Kurulum, Tarama ve Rapor Okuma Rehberi]]> https://www.turkteam.org/konu-mobsf-ile-android-apk-statik-analizi-2026-kurulum-tarama-ve-rapor-okuma-rehberi.html Sun, 18 Oct 2026 11:31:26 +0300 Tonyukuk]]> https://www.turkteam.org/konu-mobsf-ile-android-apk-statik-analizi-2026-kurulum-tarama-ve-rapor-okuma-rehberi.html [Resim: attachment.php?aid=163]
Merhaba arkadaşlar,

Bir Android uygulamasının güvenli olup olmadığını anlamanın en hızlı yollarından biri statik analizdir: uygulamayı çalıştırmadan, paketinin içindeki kodu, izinleri ve yapılandırmayı incelemek. Mobile Security Framework (MobSF), açık kaynak ve ücretsiz bir mobil uygulama güvenlik analiz çerçevesidir; APK dosyalarını sürükle-bırak kolaylığında tarar. Bu rehberde MobSF'i resmi belgelerine dayanarak Docker ile kurup, kendi geliştirdiğiniz veya analiz izniniz olan bir APK'yı nasıl statik analiz edeceğinizi ve raporu OWASP MASVS çerçevesiyle nasıl okuyacağınızı anlatıyorum. Yalnızca kendi uygulamalarınızı veya yazılı izin aldığınız uygulamaları analiz edin.

Konuda Anlatılacaklar
  1. Statik analiz nedir, MobSF ne yapar?
  2. Docker ile kurulum
  3. APK yapısı ve analize hazırlık
  4. Statik tarama adımları
  5. Raporu okuma: izinler, sertifika, kod
  6. OWASP MASVS/MASTG ile eşleştirme
  7. Komut satırı ve CI entegrasyonu

Statik Analiz Nedir, MobSF Ne Yapar?

Statik analiz, uygulamayı çalıştırmadan paketini inceler. MobSF bir APK'yı açar; AndroidManifest.xml'den izinleri ve bileşenleri çıkarır, imza sertifikasını kontrol eder, sabit kodlanmış sırları (API anahtarı, parola) arar, güvensiz kod desenlerini işaretler ve bir güvenlik skoru üretir. Dinamik analiz (çalışırken inceleme) de destekler ama bu rehberde statik tarafa odaklanıyoruz.

[Resim: attachment.php?aid=164]

Docker ile Kurulum

MobSF'i çalıştırmanın en temiz yolu Docker'dır. Resmi belgelerdeki komutlar:

Kod:
docker pull opensecurity/mobile-security-framework-mobsf:latest docker run -it --rm -p 8000:8000 \ opensecurity/mobile-security-framework-mobsf:latest

Ardından tarayıcıda http://127.0.0.1:8000 adresini açın. Resmi belgelere göre Docker imajı yönetici kullanıcı bilgilerini mobsf / mobsf olarak ayarlar; ilk girişten sonra bu parolayı değiştirin. MobSF'i kendi bilgisayarınızda, yerel ağa kapalı biçimde çalıştırın; internete açmayın.

APK Yapısı ve Analize Hazırlık

Bir APK aslında bir ZIP arşividir. İçinde classes.dex (derlenmiş kod), AndroidManifest.xml, kaynaklar ve imza bulunur. MobSF bunları sizin için çözer, ama yapıyı bilmek raporu okumayı kolaylaştırır. Kendi test APK'nızın imzasını komut satırından da inceleyebilirsiniz (Android SDK'nın resmi aracı apksigner ile):

Kod:
apksigner verify --print-certs uygulamam.apk

Analiz edeceğiniz APK yalnızca kendinize ait olmalı ya da sahibinden yazılı izin almış olmalısınız. Mağazadan indirdiğiniz üçüncü taraf bir uygulamayı tersine mühendislik yapmak, uygulamanın lisans koşullarını ve yasaları ihlal edebilir.

Statik Tarama Adımları

MobSF arayüzünde analiz çok basittir:
  1. Ana sayfadaki yükleme alanına APK dosyasını sürükleyip bırakın.
  2. MobSF otomatik olarak statik analizi başlatır ve birkaç dakika içinde rapor üretir.
  3. Rapor üstünde bir güvenlik skoru ve özet görürsünüz.
  4. Sol menüden izinler, manifest analizi, kod analizi gibi bölümlere geçersiniz.

[Resim: attachment.php?aid=165]

Raporu Okuma: İzinler, Sertifika, Kod

Raporun en önemli bölümleri:
  • İzinler (Permissions): Uygulamanın istediği izinler. SMS okuma, konum, kişiler gibi "tehlikeli" izinler işlevle orantısızsa dikkat edin. İşlevi dosya not tutmak olan bir uygulamanın SMS iznine ihtiyacı yoktur.
  • Sertifika (Signer): İmza algoritması ve geçerlilik. Zayıf imza şeması (yalnızca v1) veya hata ayıklama (debug) sertifikasıyla imzalı bir sürüm üretim için risklidir.
  • Manifest analizi: exported=true olan bileşenler (activity, service, receiver, provider) dışarıdan erişilebilir; gereksizse kapatılmalıdır. android:debuggable="true" ve izin veren clear-text trafik ayarları da burada işaretlenir.
  • Kod analizi: Sabit kodlanmış API anahtarları, zayıf kriptografi (ECB modu, sabit IV), güvensiz rastgelelik, SSL doğrulamasını atlayan kod gibi desenler.

MobSF her bulguyu bir açıklama ve genellikle ilgili OWASP referansıyla sunar; raporu baştan sona değil, önce yüksek önemli bulgulardan okuyun.

OWASP MASVS/MASTG ile Eşleştirme

MobSF bulgularını bir çerçeveye oturtmak için OWASP Mobile Application Security projesini kullanın. MASVS (güncel sürüm v2.1.0) kontrolleri tanımlar; MASTG (güncel sürüm v2.0.0) bu kontrolleri sınayan testleri içerir. 2026'da yayımlanan MASWE v1.0.0 ise MASVS kontrolleri ile MASTG testleri arasındaki belirli zayıflıkları numaralandırır (78 zayıflık). Örneğin MobSF'in bulduğu "hassas veri korumasız depolanıyor" bulgusu MASVS-STORAGE kategorisine, oradan ilgili MASWE zayıflığına ve MASTG testine bağlanır. Bu eşleştirme, bulgularınıza standart bir dil ve raporlanabilir bir kimlik kazandırır.

[Resim: attachment.php?aid=166]

İleri Seviye: Komut Satırı ve CI Entegrasyonu

MobSF bir REST API sunar; bunu CI/CD hattında otomatik tarama için kullanabilirsiniz. MobSF ekibinin açık kaynak aracı mobsfscan ise kaynak kod üzerinde doğrudan statik güvenlik taraması yapar (kod tabanınız elinizdeyse ideal):

Kod:
pip install mobsfscan mobsfscan ./android-projem

mobsfscan, güvensiz kriptografi, sabit kodlanmış sırlar, SSL pinning eksikliği gibi sorunları kaynak kodda işaretler ve CI'da "fail" döndürecek şekilde yapılandırılabilir. Böylece her kod değişikliğinde mobil güvenlik kontrolü otomatik çalışır. Statik analizi, mümkünse dinamik analiz ve manuel test ile birleştirmek en sağlam sonucu verir; hiçbir otomatik araç tek başına tam güvence vermez.

Sonuç

MobSF, bir APK'nın güvenlik durumunu dakikalar içinde ortaya koyan güçlü ve ücretsiz bir araç. Docker ile kurun, varsayılan mobsf/mobsf parolasını değiştirin, kendi uygulamanızı tarayın, izin-sertifika-kod bulgularını önceliklendirin ve hepsini OWASP MASVS/MASTG/MASWE çerçevesine oturtun. CI için mobsfscan ile bunu otomatikleştirin. Siz hangi mobil güvenlik aracını kullanıyorsunuz? Yorumlarda paylaşın.

Kaynakça
Yasal Uyarı

Bu rehberdeki analizler yalnızca kendinize ait veya sahibinden yazılı izin aldığınız uygulamalar üzerinde yapılmalıdır. Başkasına ait uygulamaları izinsiz tersine mühendislik veya analiz etmek, lisans ihlaline ve 5237 sayılı Türk Ceza Kanunu'nun 243-245. maddeleri kapsamında sorumluluğa yol açabilir. TurkTeam yalnızca savunma ve eğitim amaçlı paylaşımları destekler.

Görsel: TurkTeam özgün kapak ve diyagramları

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

.jpg   10-cover.jpg (Dosya Boyutu: 81.6 KB / İndirme Sayısı: 9)

.jpg   10-a.jpg (Dosya Boyutu: 55.21 KB / İndirme Sayısı: 8)

.jpg   10-b.jpg (Dosya Boyutu: 66.15 KB / İndirme Sayısı: 9)

.jpg   10-c.jpg (Dosya Boyutu: 90.11 KB / İndirme Sayısı: 8) ]]> [Resim: attachment.php?aid=163]
Merhaba arkadaşlar,

Bir Android uygulamasının güvenli olup olmadığını anlamanın en hızlı yollarından biri statik analizdir: uygulamayı çalıştırmadan, paketinin içindeki kodu, izinleri ve yapılandırmayı incelemek. Mobile Security Framework (MobSF), açık kaynak ve ücretsiz bir mobil uygulama güvenlik analiz çerçevesidir; APK dosyalarını sürükle-bırak kolaylığında tarar. Bu rehberde MobSF'i resmi belgelerine dayanarak Docker ile kurup, kendi geliştirdiğiniz veya analiz izniniz olan bir APK'yı nasıl statik analiz edeceğinizi ve raporu OWASP MASVS çerçevesiyle nasıl okuyacağınızı anlatıyorum. Yalnızca kendi uygulamalarınızı veya yazılı izin aldığınız uygulamaları analiz edin.

Konuda Anlatılacaklar
  1. Statik analiz nedir, MobSF ne yapar?
  2. Docker ile kurulum
  3. APK yapısı ve analize hazırlık
  4. Statik tarama adımları
  5. Raporu okuma: izinler, sertifika, kod
  6. OWASP MASVS/MASTG ile eşleştirme
  7. Komut satırı ve CI entegrasyonu

Statik Analiz Nedir, MobSF Ne Yapar?

Statik analiz, uygulamayı çalıştırmadan paketini inceler. MobSF bir APK'yı açar; AndroidManifest.xml'den izinleri ve bileşenleri çıkarır, imza sertifikasını kontrol eder, sabit kodlanmış sırları (API anahtarı, parola) arar, güvensiz kod desenlerini işaretler ve bir güvenlik skoru üretir. Dinamik analiz (çalışırken inceleme) de destekler ama bu rehberde statik tarafa odaklanıyoruz.

[Resim: attachment.php?aid=164]

Docker ile Kurulum

MobSF'i çalıştırmanın en temiz yolu Docker'dır. Resmi belgelerdeki komutlar:

Kod:
docker pull opensecurity/mobile-security-framework-mobsf:latest docker run -it --rm -p 8000:8000 \ opensecurity/mobile-security-framework-mobsf:latest

Ardından tarayıcıda http://127.0.0.1:8000 adresini açın. Resmi belgelere göre Docker imajı yönetici kullanıcı bilgilerini mobsf / mobsf olarak ayarlar; ilk girişten sonra bu parolayı değiştirin. MobSF'i kendi bilgisayarınızda, yerel ağa kapalı biçimde çalıştırın; internete açmayın.

APK Yapısı ve Analize Hazırlık

Bir APK aslında bir ZIP arşividir. İçinde classes.dex (derlenmiş kod), AndroidManifest.xml, kaynaklar ve imza bulunur. MobSF bunları sizin için çözer, ama yapıyı bilmek raporu okumayı kolaylaştırır. Kendi test APK'nızın imzasını komut satırından da inceleyebilirsiniz (Android SDK'nın resmi aracı apksigner ile):

Kod:
apksigner verify --print-certs uygulamam.apk

Analiz edeceğiniz APK yalnızca kendinize ait olmalı ya da sahibinden yazılı izin almış olmalısınız. Mağazadan indirdiğiniz üçüncü taraf bir uygulamayı tersine mühendislik yapmak, uygulamanın lisans koşullarını ve yasaları ihlal edebilir.

Statik Tarama Adımları

MobSF arayüzünde analiz çok basittir:
  1. Ana sayfadaki yükleme alanına APK dosyasını sürükleyip bırakın.
  2. MobSF otomatik olarak statik analizi başlatır ve birkaç dakika içinde rapor üretir.
  3. Rapor üstünde bir güvenlik skoru ve özet görürsünüz.
  4. Sol menüden izinler, manifest analizi, kod analizi gibi bölümlere geçersiniz.

[Resim: attachment.php?aid=165]

Raporu Okuma: İzinler, Sertifika, Kod

Raporun en önemli bölümleri:
  • İzinler (Permissions): Uygulamanın istediği izinler. SMS okuma, konum, kişiler gibi "tehlikeli" izinler işlevle orantısızsa dikkat edin. İşlevi dosya not tutmak olan bir uygulamanın SMS iznine ihtiyacı yoktur.
  • Sertifika (Signer): İmza algoritması ve geçerlilik. Zayıf imza şeması (yalnızca v1) veya hata ayıklama (debug) sertifikasıyla imzalı bir sürüm üretim için risklidir.
  • Manifest analizi: exported=true olan bileşenler (activity, service, receiver, provider) dışarıdan erişilebilir; gereksizse kapatılmalıdır. android:debuggable="true" ve izin veren clear-text trafik ayarları da burada işaretlenir.
  • Kod analizi: Sabit kodlanmış API anahtarları, zayıf kriptografi (ECB modu, sabit IV), güvensiz rastgelelik, SSL doğrulamasını atlayan kod gibi desenler.

MobSF her bulguyu bir açıklama ve genellikle ilgili OWASP referansıyla sunar; raporu baştan sona değil, önce yüksek önemli bulgulardan okuyun.

OWASP MASVS/MASTG ile Eşleştirme

MobSF bulgularını bir çerçeveye oturtmak için OWASP Mobile Application Security projesini kullanın. MASVS (güncel sürüm v2.1.0) kontrolleri tanımlar; MASTG (güncel sürüm v2.0.0) bu kontrolleri sınayan testleri içerir. 2026'da yayımlanan MASWE v1.0.0 ise MASVS kontrolleri ile MASTG testleri arasındaki belirli zayıflıkları numaralandırır (78 zayıflık). Örneğin MobSF'in bulduğu "hassas veri korumasız depolanıyor" bulgusu MASVS-STORAGE kategorisine, oradan ilgili MASWE zayıflığına ve MASTG testine bağlanır. Bu eşleştirme, bulgularınıza standart bir dil ve raporlanabilir bir kimlik kazandırır.

[Resim: attachment.php?aid=166]

İleri Seviye: Komut Satırı ve CI Entegrasyonu

MobSF bir REST API sunar; bunu CI/CD hattında otomatik tarama için kullanabilirsiniz. MobSF ekibinin açık kaynak aracı mobsfscan ise kaynak kod üzerinde doğrudan statik güvenlik taraması yapar (kod tabanınız elinizdeyse ideal):

Kod:
pip install mobsfscan mobsfscan ./android-projem

mobsfscan, güvensiz kriptografi, sabit kodlanmış sırlar, SSL pinning eksikliği gibi sorunları kaynak kodda işaretler ve CI'da "fail" döndürecek şekilde yapılandırılabilir. Böylece her kod değişikliğinde mobil güvenlik kontrolü otomatik çalışır. Statik analizi, mümkünse dinamik analiz ve manuel test ile birleştirmek en sağlam sonucu verir; hiçbir otomatik araç tek başına tam güvence vermez.

Sonuç

MobSF, bir APK'nın güvenlik durumunu dakikalar içinde ortaya koyan güçlü ve ücretsiz bir araç. Docker ile kurun, varsayılan mobsf/mobsf parolasını değiştirin, kendi uygulamanızı tarayın, izin-sertifika-kod bulgularını önceliklendirin ve hepsini OWASP MASVS/MASTG/MASWE çerçevesine oturtun. CI için mobsfscan ile bunu otomatikleştirin. Siz hangi mobil güvenlik aracını kullanıyorsunuz? Yorumlarda paylaşın.

Kaynakça
Yasal Uyarı

Bu rehberdeki analizler yalnızca kendinize ait veya sahibinden yazılı izin aldığınız uygulamalar üzerinde yapılmalıdır. Başkasına ait uygulamaları izinsiz tersine mühendislik veya analiz etmek, lisans ihlaline ve 5237 sayılı Türk Ceza Kanunu'nun 243-245. maddeleri kapsamında sorumluluğa yol açabilir. TurkTeam yalnızca savunma ve eğitim amaçlı paylaşımları destekler.

Görsel: TurkTeam özgün kapak ve diyagramları

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

.jpg   10-cover.jpg (Dosya Boyutu: 81.6 KB / İndirme Sayısı: 9)

.jpg   10-a.jpg (Dosya Boyutu: 55.21 KB / İndirme Sayısı: 8)

.jpg   10-b.jpg (Dosya Boyutu: 66.15 KB / İndirme Sayısı: 9)

.jpg   10-c.jpg (Dosya Boyutu: 90.11 KB / İndirme Sayısı: 8) ]]> <![CDATA[Mobilde 2FA: Authenticator, Passkey ve SMS Karşılaştırması 2026]]> https://www.turkteam.org/konu-mobilde-2fa-authenticator-passkey-ve-sms-karsilastirmasi-2026.html Sun, 18 Oct 2026 11:28:34 +0300 Tonyukuk]]> https://www.turkteam.org/konu-mobilde-2fa-authenticator-passkey-ve-sms-karsilastirmasi-2026.html [Resim: attachment.php?aid=161]
Selam,

Mobilde ikinci faktör artık sadece SMS değil. Authenticator uygulamaları (TOTP) ve passkey / platform authenticator seçenekleri olgunlaştı. Bu yazıda 2026 itibarıyla pratik karşılaştırmamı ve neyi ne zaman önerdiğimi yazıyorum.

SMS OTP
Artıları: herkes kullanabilir. Eksileri: SIM swap, SS7 riskleri, phishing ile aynı anda çalınabilir (gerçek zamanlı proxy). Hassas hesaplarda tek başına yeterli görmüyorum.

Authenticator (TOTP)
Zaman tabanlı 6 haneli kod. Çevrimdışı çalışır. Seed'i yedeklemek kritik; telefonu kaybedince hesap kilitlenmesin. Uygulama seçerken açık kaynak / saygın satıcı + cihaz içi şifreleme bakın.
  • Kurulumda QR'ı ekran görüntüsü olarak buluta atmayın
  • Yedek kodları parola yöneticisine veya offline kasaya
  • Aynı TOTP seed'i birden fazla cihaza bilinçli koyun



Passkey
FIDO2 / WebAuthn tabanlı; phishing'e karşı TOTP'tan daha dirençli (origin bağlı). iOS / Android / masaüstü platform anahtarları ve donanım güvenlik anahtarları. Senkron passkey kolaylık sağlar; tehdit modelinize göre cihaz şifresi + iCloud/Google hesabı güvenliği de dahil olur.

Pratik önerim
  • E-posta ve parola yöneticisi: passkey veya donanım anahtarı + TOTP yedek
  • Banka uygulaması: bankanın sunduğu yöntem + SIM PIN + operatördeki ek şifre
  • İş hesapları: mümkünse FIDO2 zorunlu, SMS yalnızca break-glass

Kurtarma senaryosu
Telefon çalındığında: Find My / Google Find ile uzaktan silme, SIM blok, kritik hesaplarda oturum düşürme, TOTP seed yedeklerinden yeni cihaz. Bu tatbikatı yılda bir yapın.

Kaynaklar
  • FIDO Alliance / WebAuthn spesifikasyon özetleri
  • NIST SP 800-63B (authenticator gücü kavramları)
  • Platform üreticilerinin passkey belgeleri

Siz passkey'e geçerken hangi sitede takıldınız? Hâlâ TOTP zorunlu tutan büyük servisler var mı listenizde?

Donanım anahtarı
YubiKey / benzeri anahtarlar phishing direnci yüksek ikinci faktördür. Hesap başına en az iki anahtar (asıl + yedek) kaydedin; tek anahtar kaybı hesap kilidi demektir. NFC / USB-C uyumunu telefonunuza göre seçin.

Kurumsal MDM
Şirket telefonunda passkey / authenticator politikası MDM ile yönetilir. BYOD'da iş hesaplarını kişisel TOTP uygulamasına koymak veri sınıflandırma politikasını ihlal edebilir; iş profili kullanın.


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.

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.

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-n25-daa546.png (Dosya Boyutu: 69.36 KB / İndirme Sayısı: 8) ]]> [Resim: attachment.php?aid=161]
Selam,

Mobilde ikinci faktör artık sadece SMS değil. Authenticator uygulamaları (TOTP) ve passkey / platform authenticator seçenekleri olgunlaştı. Bu yazıda 2026 itibarıyla pratik karşılaştırmamı ve neyi ne zaman önerdiğimi yazıyorum.

SMS OTP
Artıları: herkes kullanabilir. Eksileri: SIM swap, SS7 riskleri, phishing ile aynı anda çalınabilir (gerçek zamanlı proxy). Hassas hesaplarda tek başına yeterli görmüyorum.

Authenticator (TOTP)
Zaman tabanlı 6 haneli kod. Çevrimdışı çalışır. Seed'i yedeklemek kritik; telefonu kaybedince hesap kilitlenmesin. Uygulama seçerken açık kaynak / saygın satıcı + cihaz içi şifreleme bakın.
  • Kurulumda QR'ı ekran görüntüsü olarak buluta atmayın
  • Yedek kodları parola yöneticisine veya offline kasaya
  • Aynı TOTP seed'i birden fazla cihaza bilinçli koyun



Passkey
FIDO2 / WebAuthn tabanlı; phishing'e karşı TOTP'tan daha dirençli (origin bağlı). iOS / Android / masaüstü platform anahtarları ve donanım güvenlik anahtarları. Senkron passkey kolaylık sağlar; tehdit modelinize göre cihaz şifresi + iCloud/Google hesabı güvenliği de dahil olur.

Pratik önerim
  • E-posta ve parola yöneticisi: passkey veya donanım anahtarı + TOTP yedek
  • Banka uygulaması: bankanın sunduğu yöntem + SIM PIN + operatördeki ek şifre
  • İş hesapları: mümkünse FIDO2 zorunlu, SMS yalnızca break-glass

Kurtarma senaryosu
Telefon çalındığında: Find My / Google Find ile uzaktan silme, SIM blok, kritik hesaplarda oturum düşürme, TOTP seed yedeklerinden yeni cihaz. Bu tatbikatı yılda bir yapın.

Kaynaklar
  • FIDO Alliance / WebAuthn spesifikasyon özetleri
  • NIST SP 800-63B (authenticator gücü kavramları)
  • Platform üreticilerinin passkey belgeleri

Siz passkey'e geçerken hangi sitede takıldınız? Hâlâ TOTP zorunlu tutan büyük servisler var mı listenizde?

Donanım anahtarı
YubiKey / benzeri anahtarlar phishing direnci yüksek ikinci faktördür. Hesap başına en az iki anahtar (asıl + yedek) kaydedin; tek anahtar kaybı hesap kilidi demektir. NFC / USB-C uyumunu telefonunuza göre seçin.

Kurumsal MDM
Şirket telefonunda passkey / authenticator politikası MDM ile yönetilir. BYOD'da iş hesaplarını kişisel TOTP uygulamasına koymak veri sınıflandırma politikasını ihlal edebilir; iş profili kullanın.


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.

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.

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-n25-daa546.png (Dosya Boyutu: 69.36 KB / İndirme Sayısı: 8) ]]> <![CDATA[Midnight Mimosa: Ucuz Android Telefonlara Fabrikadan Gömülü Zararlı Yazılım]]> https://www.turkteam.org/konu-midnight-mimosa-ucuz-android-telefonlara-fabrikadan-gomulu-zararli-yazilim.html Sat, 17 Oct 2026 11:20:34 +0300 Tonyukuk]]> https://www.turkteam.org/konu-midnight-mimosa-ucuz-android-telefonlara-fabrikadan-gomulu-zararli-yazilim.html [Resim: attachment.php?aid=66]
Telefon güvenliğinde çoğu tavsiye "şüpheli uygulama kurma, bilinmeyen kaynaktan APK yükleme" üzerine kuruludur. Peki ya zararlı yazılım siz telefonu ilk kez açmadan önce, fabrikadan çıktığı anda içindeyse? Bitdefender'ın ortaya çıkardığı Midnight Mimosa kampanyası tam olarak bu senaryo.

Olay ne?

Araştırmacılar, düşük maliyetli ve MediaTek yonga setli bazı Android telefonların firmware'ine (sistem bölümüne) gömülü zararlı yazılım buldu. Bu yazılım cihaz kullanıcıya ulaştığında zaten kurulu olduğu için normal uygulama kaldırma yöntemiyle silinemiyor. Kampanya yaklaşık iki yılda 150'den fazla ülkede binlerce cihazı etkilemiş; en çok vaka Meksika, Fransa, İtalya, ABD, Almanya, Brezilya ve İspanya'da.

Raporda adı geçen modeller arasında Doogee S200 X, Doogee Fire 3 Max, Cubot KINGKONG X ve Samsung/Apple taklidi sahte cihazlar var. Bir Doogee Fire 3 Max sahibi, resmi bir firmware güncellemesinin cihazı tekrar enfekte ettiğini bildirmiş.

Teknik olarak neden tehlikeli?

Zararlının çekirdeği, platform anahtarıyla imzalanmış bir sistem uygulaması. Android bu yüzden ona güveniyor ve yüksek yetki veriyor. Kullandığı sahte paket adları gerçek sistem bileşenlerini taklit ediyor: com.android.system.lite, com.android.sys.prot, com.android.sys.gmsprot gibi.

Bu yetkilerle yapabildikleri:
  • Sessizce uygulama kurup kaldırmak, izin vermek, sunucudan indirdiği kodu çalıştırmak.
  • IMEI, Android ID, MAC adresi ve saat dilimini komuta sunucusuna göndermek.
  • Erişilebilirlik (Accessibility), bildirim ve SMS izinlerini kendine vermek.

İlginç kaçınma tekniği: zararlı, uygulama kurmadan hemen önce Google Play Store'u (com.android.vending) geçici olarak devre dışı bırakıyor; böylece Play Protect kurulumu yakalayamıyor. Kurulum bitince Play Store'u tekrar açıyor. Bazı sürümler kurulum kaynağını da manipüle ederek uygulamaları "Google Play'den gelmiş" gibi gösteriyor.

Amaç ne, para mı casusluk mu?

Bitdefender'a göre ana motivasyon reklam dolandırıcılığı. Düşürülen sahte uygulamalar (hava durumu, uygulama kilidi, not alma, OCR araçları gibi) meşru bir reklam SDK'sı ile gizli pencerelerde gerçek reklam yükleyip sahte gösterim ve tıklama üretiyor. Ayrıca bazı cihazlar konut proxy'si (residential proxy) olarak kaydediliyor; yani başkalarının trafiği sizin telefonunuzun internet bağlantısı üzerinden geçirilebiliyor. Araştırmacılar proxy komuta altyapısının çalışır durumda olduğunu doğruladı ancak kendi test cihazlarına aktif bir hedef gelmediği için trafiğin fiilen yönlendirilip yönlendirilmediğini teyit edemedi.

Burada benim altını çizmek istediğim nokta: SMS ve Erişilebilirlik izinleri şu an reklam için kullanılıyor olabilir, ama bu bir yetenek. Aynı yetki, bir gün bankacılık SMS kodlarını okumak için de kullanılabilir. Bu yüzden bu tip bir cihazı kimlik doğrulama (OTP) cihazı olarak kullanmak çok riskli.

Temizlenebilir mi?

Kolay değil. Zararlı yüksek yetkili bir sistem uygulaması olduğu için fabrika ayarlarına döndürmek yetmiyor. Temizlik için firmware'in yeniden yüklenmesi ya da bileşenin ADB (Android Debug Bridge) ile devre dışı bırakılması gerekiyor; bu da ortalama kullanıcı için zor.

Pratik öneriler
  • İş ve kimlik doğrulama için markasız/çok ucuz Android telefonları kullanmayın.
  • Kurumsalsanız MDM envanterinde yukarıdaki paket adlarını arayın.
  • Telefonu banka veya OTP cihazı yapacaksanız platform bütünlük doğrulamasını (Play Integrity) geçen cihazları tercih edin; yönetilmeyen Android'lerdeki SMS tabanlı OTP'yi zayıf kabul edin.
  • Kullanıcılara fabrika sıfırlamasının firmware zararlısını temizlemediğini anlatın.

Yasal ve etik not

Bu konu bir farkındalık/haber derlemesidir; amaç yalnızca kendi cihazınızı ve kurumunuzun yönettiği cihazları korumaktır. Başkasının cihazına izinsiz erişim ya da müdahale TCK kapsamında suçtur.

Kaynakça
Görsel: TurkTeam özgün kapak görseli

.jpg   tonyukuk-06-mimosa.jpg (Dosya Boyutu: 85.92 KB / İndirme Sayısı: 7) ]]> [Resim: attachment.php?aid=66]
Telefon güvenliğinde çoğu tavsiye "şüpheli uygulama kurma, bilinmeyen kaynaktan APK yükleme" üzerine kuruludur. Peki ya zararlı yazılım siz telefonu ilk kez açmadan önce, fabrikadan çıktığı anda içindeyse? Bitdefender'ın ortaya çıkardığı Midnight Mimosa kampanyası tam olarak bu senaryo.

Olay ne?

Araştırmacılar, düşük maliyetli ve MediaTek yonga setli bazı Android telefonların firmware'ine (sistem bölümüne) gömülü zararlı yazılım buldu. Bu yazılım cihaz kullanıcıya ulaştığında zaten kurulu olduğu için normal uygulama kaldırma yöntemiyle silinemiyor. Kampanya yaklaşık iki yılda 150'den fazla ülkede binlerce cihazı etkilemiş; en çok vaka Meksika, Fransa, İtalya, ABD, Almanya, Brezilya ve İspanya'da.

Raporda adı geçen modeller arasında Doogee S200 X, Doogee Fire 3 Max, Cubot KINGKONG X ve Samsung/Apple taklidi sahte cihazlar var. Bir Doogee Fire 3 Max sahibi, resmi bir firmware güncellemesinin cihazı tekrar enfekte ettiğini bildirmiş.

Teknik olarak neden tehlikeli?

Zararlının çekirdeği, platform anahtarıyla imzalanmış bir sistem uygulaması. Android bu yüzden ona güveniyor ve yüksek yetki veriyor. Kullandığı sahte paket adları gerçek sistem bileşenlerini taklit ediyor: com.android.system.lite, com.android.sys.prot, com.android.sys.gmsprot gibi.

Bu yetkilerle yapabildikleri:
  • Sessizce uygulama kurup kaldırmak, izin vermek, sunucudan indirdiği kodu çalıştırmak.
  • IMEI, Android ID, MAC adresi ve saat dilimini komuta sunucusuna göndermek.
  • Erişilebilirlik (Accessibility), bildirim ve SMS izinlerini kendine vermek.

İlginç kaçınma tekniği: zararlı, uygulama kurmadan hemen önce Google Play Store'u (com.android.vending) geçici olarak devre dışı bırakıyor; böylece Play Protect kurulumu yakalayamıyor. Kurulum bitince Play Store'u tekrar açıyor. Bazı sürümler kurulum kaynağını da manipüle ederek uygulamaları "Google Play'den gelmiş" gibi gösteriyor.

Amaç ne, para mı casusluk mu?

Bitdefender'a göre ana motivasyon reklam dolandırıcılığı. Düşürülen sahte uygulamalar (hava durumu, uygulama kilidi, not alma, OCR araçları gibi) meşru bir reklam SDK'sı ile gizli pencerelerde gerçek reklam yükleyip sahte gösterim ve tıklama üretiyor. Ayrıca bazı cihazlar konut proxy'si (residential proxy) olarak kaydediliyor; yani başkalarının trafiği sizin telefonunuzun internet bağlantısı üzerinden geçirilebiliyor. Araştırmacılar proxy komuta altyapısının çalışır durumda olduğunu doğruladı ancak kendi test cihazlarına aktif bir hedef gelmediği için trafiğin fiilen yönlendirilip yönlendirilmediğini teyit edemedi.

Burada benim altını çizmek istediğim nokta: SMS ve Erişilebilirlik izinleri şu an reklam için kullanılıyor olabilir, ama bu bir yetenek. Aynı yetki, bir gün bankacılık SMS kodlarını okumak için de kullanılabilir. Bu yüzden bu tip bir cihazı kimlik doğrulama (OTP) cihazı olarak kullanmak çok riskli.

Temizlenebilir mi?

Kolay değil. Zararlı yüksek yetkili bir sistem uygulaması olduğu için fabrika ayarlarına döndürmek yetmiyor. Temizlik için firmware'in yeniden yüklenmesi ya da bileşenin ADB (Android Debug Bridge) ile devre dışı bırakılması gerekiyor; bu da ortalama kullanıcı için zor.

Pratik öneriler
  • İş ve kimlik doğrulama için markasız/çok ucuz Android telefonları kullanmayın.
  • Kurumsalsanız MDM envanterinde yukarıdaki paket adlarını arayın.
  • Telefonu banka veya OTP cihazı yapacaksanız platform bütünlük doğrulamasını (Play Integrity) geçen cihazları tercih edin; yönetilmeyen Android'lerdeki SMS tabanlı OTP'yi zayıf kabul edin.
  • Kullanıcılara fabrika sıfırlamasının firmware zararlısını temizlemediğini anlatın.

Yasal ve etik not

Bu konu bir farkındalık/haber derlemesidir; amaç yalnızca kendi cihazınızı ve kurumunuzun yönettiği cihazları korumaktır. Başkasının cihazına izinsiz erişim ya da müdahale TCK kapsamında suçtur.

Kaynakça
Görsel: TurkTeam özgün kapak görseli

.jpg   tonyukuk-06-mimosa.jpg (Dosya Boyutu: 85.92 KB / İndirme Sayısı: 7) ]]> <![CDATA[Hirudo Android Bankacılık Trojanı: Gerçek Uygulamayı Sahte Kopyasıyla Değiştiriyor]]> https://www.turkteam.org/konu-hirudo-android-bankacilik-trojani-gercek-uygulamayi-sahte-kopyasiyla-degistiriyor.html Fri, 16 Oct 2026 11:12:13 +0300 Tonyukuk]]> https://www.turkteam.org/konu-hirudo-android-bankacilik-trojani-gercek-uygulamayi-sahte-kopyasiyla-degistiriyor.html [Resim: attachment.php?aid=7]
Hirudo: Android Bankacılık Trojanları Yeni Seviyeye Çıktı

Selamlar,

Hollandalı mobil güvenlik firması ThreatFabric, 14 Ekim 2026'da Hirudo adlı yeni bir Android bankacılık RAT'ını (Remote Access Trojan) açıkladı. Hirudo klasik "üstüne bir üst katman çiz" yaklaşımının ötesine geçiyor: Hedef banka uygulamasını tespit edip, onu amaçlı olarak yamalanmış bir kopyasıyla değiştiriyor ve uygulamanın kendi imza, erişilebilirlik, ekran koruma ve Play Integrity kontrollerini içeriden kör ediyor. Bu konuda saldırının nasıl çalıştığını ve kullanıcıların / kurumların nasıl korunabileceğini özetliyoruz.

Konuda Anlatılacaklar
  1. Hirudo nedir, kimleri hedefliyor?
  2. Dağıtım zinciri: Sahte mağaza sayfaları ve dropper uygulamalar
  3. Bankacılık uygulamasını değiştirme mekanizması
  4. Play Integrity ve imza kontrollerinin nasıl atlatıldığı
  5. Kullanıcı ve kurum için koruma önerileri
  6. Kaynakça

1) Hirudo Nedir?
Hirudo; kimlik bilgisi hırsızlığı, cihaz ele geçirme, ekran ve kamera yakalama ile SMS hırsızlığını tek bir arka uçta birleştiren olgun bir operasyon. ThreatFabric, Endonezya'daki sekiz bankacılık uygulamasının özel yamalanmış kopyalarını tespit etti. Kimlik bilgisi hedefleri ise Endonezya, Çin, Hindistan, Meksika, Fas ve Tayland'ı kapsıyor. ThreatFabric'in dolandırıcılık mühendisliği başkan yardımcısı Eward Driehuis'in ifadesiyle operasyon "oldukça olgun bir arka uç" ile cihaz kontrolünü birleştiriyor.

2) Dağıtım Zinciri
Kullanıcılar Meta platformlarındaki reklamlardan, Google Play Store gibi görünen sahte web sayfalarına yönlendiriliyor. Bu sayfalar alışveriş, kısa dizi veya futbol uygulamaları gibi görünüyor. Dropper uygulamalar (örnek paket isimleri ThreatFabric raporunda geçiyor: Shopora, 1V1 X, KoiShort, ZoyaTV) gerçek içerik yüklüyor; arka planda ise kampanya yapılandırmasını çekip Hirudo RAT'ının kurulu olup olmadığını kontrol ediyor.

Kurulu değilse sahte bir "güncelleme" istemi gösteriyor. Hirudo ayrı bir uygulama olarak kuruluyor ve kendi izinlerini (erişilebilirlik, bildirim erişimi) ayrı ayrı istiyor. Yükleme öncesinde StreamRat'ta da görülen bir anti-tespit tekniği kullanılıyor: Bilinçli olarak çalışmayan bir VPN bağlantısı kurarak interneti kesip Google Play Protect'in bulut tabanlı kontrollerini zayıflatmaya çalışıyor. ThreatFabric, Play Protect'in çevrimdışı bilinen zararlı uygulama tespitinin bu yöntemle tamamen kapanmadığını, tekniğin daha çok çevrimiçi itibar ve kod analizi mekanizmalarını zayıflatmayı hedeflediğini değerlendiriyor.

3) Bankacılık Uygulamasını Değiştirme
Hirudo'nun asıl farkı burada. RAT, erişilebilirlik servisi üzerinden yüklü banka uygulamasını tespit ediyor, imza sertifikasını saklı bir referansla karşılaştırıyor ve sahte bir "güncelleme" istemi gösteriyor. Gerçek uygulamanın kaldırma ekranını kullanıcıya dokunmasını beklemeden açıyor; aynı anda bankaya özel yamalanmış kopyayı indiriyor. Kopya orijinal paket adını ve sürüm görünümünü koruyor ama test anahtarıyla imzalanmış durumda.

Bu "önce kaldır, sonra yükle" zorunluluğu saldırgan için bir kısıt; ancak karşılığında uygulama içi güvenlik kontrollerini içeriden kör etme imkanı veriyor.

4) Play Integrity ve İmza Kontrollerinin Atlatılması
Yamalanmış kopyanın içine gömülen kanca (hooking) motoru (YAHFA/Dobby) şu yanıtları sahte üretiyor:
  • İmza sorgusunda gerçek uygulamanın imza sertifikasını döndürüyor.
  • Etkin erişilebilirlik servisleri listesini boş döndürüyor.
  • FLAG_SECURE bayrağını kaldırarak ekranın uzaktan izlenmesini ve kaydedilmesini mümkün kılıyor.
  • Anahtar onaylama (key attestation) sertifikalarını sızdırılmış bir keybox ile yeniden imzalıyor.
  • Play Integrity isteklerini düz HTTP üzerinden saldırganın sunucusuna iletiyor; sunucu uygulama için geçerli görünen bir karar döndürüyor.
ThreatFabric'in altını çizdiği iki savunucu dersi: Birincisi, motorun taşıdığı attestation keybox saldırganın kendi anahtarı değil, kamuya sızmış bir keybox. İkincisi, Integrity yanıtı gerçekten üretilmediği için "geçerli bir Integrity yanıtı" tek başına uygulamanın bozulmamış olduğunun kanıtı değil.

5) Korunma Önerileri
Son kullanıcı:
  • Uygulamaları yalnızca resmi Google Play veya bankanın kendi sitesinden yükleyin; reklamlardan gelen "ücretsiz TV / alışveriş / kısa dizi" uygulamalarına şüpheyle yaklaşın.
  • Banka uygulaması birdenbire "güncelleme" diye kaldırma ekranı açarsa işlemi durdurun ve bankayı arayın.
  • Bilinmeyen kaynaklardan APK yüklemeyi (Unknown Sources) kapalı tutun.
  • Erişilebilirlik izni isteyen uygulamaları çok sıkı denetleyin; bankacılık dışı uygulamaların bu izne ihtiyacı nadirdir.

Banka ve kurum:
  • Uygulama imzası, erişilebilirlik listesi ve Play Integrity kararını yalnızca istemci tarafında doğrulamayın; sunucu tarafında yeniden doğrulayın.
  • Keybox sızıntılarını ve bilinen yeniden imzalama göstergelerini tehdit istihbaratınızla takip edin.
  • Kullanıcı oturumlarında cihaz bütünlüğü sinyallerinin ani değişimini izleyin.
  • Müşteri destek kanallarında "banka uygulaması kaldırma / yeniden yükleme" taleplerini olası enfeksiyon göstergesi olarak ele alın.

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

.jpg   tonyukuk-04-hirudo.jpg (Dosya Boyutu: 113.61 KB / İndirme Sayısı: 10) ]]> [Resim: attachment.php?aid=7]
Hirudo: Android Bankacılık Trojanları Yeni Seviyeye Çıktı

Selamlar,

Hollandalı mobil güvenlik firması ThreatFabric, 14 Ekim 2026'da Hirudo adlı yeni bir Android bankacılık RAT'ını (Remote Access Trojan) açıkladı. Hirudo klasik "üstüne bir üst katman çiz" yaklaşımının ötesine geçiyor: Hedef banka uygulamasını tespit edip, onu amaçlı olarak yamalanmış bir kopyasıyla değiştiriyor ve uygulamanın kendi imza, erişilebilirlik, ekran koruma ve Play Integrity kontrollerini içeriden kör ediyor. Bu konuda saldırının nasıl çalıştığını ve kullanıcıların / kurumların nasıl korunabileceğini özetliyoruz.

Konuda Anlatılacaklar
  1. Hirudo nedir, kimleri hedefliyor?
  2. Dağıtım zinciri: Sahte mağaza sayfaları ve dropper uygulamalar
  3. Bankacılık uygulamasını değiştirme mekanizması
  4. Play Integrity ve imza kontrollerinin nasıl atlatıldığı
  5. Kullanıcı ve kurum için koruma önerileri
  6. Kaynakça

1) Hirudo Nedir?
Hirudo; kimlik bilgisi hırsızlığı, cihaz ele geçirme, ekran ve kamera yakalama ile SMS hırsızlığını tek bir arka uçta birleştiren olgun bir operasyon. ThreatFabric, Endonezya'daki sekiz bankacılık uygulamasının özel yamalanmış kopyalarını tespit etti. Kimlik bilgisi hedefleri ise Endonezya, Çin, Hindistan, Meksika, Fas ve Tayland'ı kapsıyor. ThreatFabric'in dolandırıcılık mühendisliği başkan yardımcısı Eward Driehuis'in ifadesiyle operasyon "oldukça olgun bir arka uç" ile cihaz kontrolünü birleştiriyor.

2) Dağıtım Zinciri
Kullanıcılar Meta platformlarındaki reklamlardan, Google Play Store gibi görünen sahte web sayfalarına yönlendiriliyor. Bu sayfalar alışveriş, kısa dizi veya futbol uygulamaları gibi görünüyor. Dropper uygulamalar (örnek paket isimleri ThreatFabric raporunda geçiyor: Shopora, 1V1 X, KoiShort, ZoyaTV) gerçek içerik yüklüyor; arka planda ise kampanya yapılandırmasını çekip Hirudo RAT'ının kurulu olup olmadığını kontrol ediyor.

Kurulu değilse sahte bir "güncelleme" istemi gösteriyor. Hirudo ayrı bir uygulama olarak kuruluyor ve kendi izinlerini (erişilebilirlik, bildirim erişimi) ayrı ayrı istiyor. Yükleme öncesinde StreamRat'ta da görülen bir anti-tespit tekniği kullanılıyor: Bilinçli olarak çalışmayan bir VPN bağlantısı kurarak interneti kesip Google Play Protect'in bulut tabanlı kontrollerini zayıflatmaya çalışıyor. ThreatFabric, Play Protect'in çevrimdışı bilinen zararlı uygulama tespitinin bu yöntemle tamamen kapanmadığını, tekniğin daha çok çevrimiçi itibar ve kod analizi mekanizmalarını zayıflatmayı hedeflediğini değerlendiriyor.

3) Bankacılık Uygulamasını Değiştirme
Hirudo'nun asıl farkı burada. RAT, erişilebilirlik servisi üzerinden yüklü banka uygulamasını tespit ediyor, imza sertifikasını saklı bir referansla karşılaştırıyor ve sahte bir "güncelleme" istemi gösteriyor. Gerçek uygulamanın kaldırma ekranını kullanıcıya dokunmasını beklemeden açıyor; aynı anda bankaya özel yamalanmış kopyayı indiriyor. Kopya orijinal paket adını ve sürüm görünümünü koruyor ama test anahtarıyla imzalanmış durumda.

Bu "önce kaldır, sonra yükle" zorunluluğu saldırgan için bir kısıt; ancak karşılığında uygulama içi güvenlik kontrollerini içeriden kör etme imkanı veriyor.

4) Play Integrity ve İmza Kontrollerinin Atlatılması
Yamalanmış kopyanın içine gömülen kanca (hooking) motoru (YAHFA/Dobby) şu yanıtları sahte üretiyor:
  • İmza sorgusunda gerçek uygulamanın imza sertifikasını döndürüyor.
  • Etkin erişilebilirlik servisleri listesini boş döndürüyor.
  • FLAG_SECURE bayrağını kaldırarak ekranın uzaktan izlenmesini ve kaydedilmesini mümkün kılıyor.
  • Anahtar onaylama (key attestation) sertifikalarını sızdırılmış bir keybox ile yeniden imzalıyor.
  • Play Integrity isteklerini düz HTTP üzerinden saldırganın sunucusuna iletiyor; sunucu uygulama için geçerli görünen bir karar döndürüyor.
ThreatFabric'in altını çizdiği iki savunucu dersi: Birincisi, motorun taşıdığı attestation keybox saldırganın kendi anahtarı değil, kamuya sızmış bir keybox. İkincisi, Integrity yanıtı gerçekten üretilmediği için "geçerli bir Integrity yanıtı" tek başına uygulamanın bozulmamış olduğunun kanıtı değil.

5) Korunma Önerileri
Son kullanıcı:
  • Uygulamaları yalnızca resmi Google Play veya bankanın kendi sitesinden yükleyin; reklamlardan gelen "ücretsiz TV / alışveriş / kısa dizi" uygulamalarına şüpheyle yaklaşın.
  • Banka uygulaması birdenbire "güncelleme" diye kaldırma ekranı açarsa işlemi durdurun ve bankayı arayın.
  • Bilinmeyen kaynaklardan APK yüklemeyi (Unknown Sources) kapalı tutun.
  • Erişilebilirlik izni isteyen uygulamaları çok sıkı denetleyin; bankacılık dışı uygulamaların bu izne ihtiyacı nadirdir.

Banka ve kurum:
  • Uygulama imzası, erişilebilirlik listesi ve Play Integrity kararını yalnızca istemci tarafında doğrulamayın; sunucu tarafında yeniden doğrulayın.
  • Keybox sızıntılarını ve bilinen yeniden imzalama göstergelerini tehdit istihbaratınızla takip edin.
  • Kullanıcı oturumlarında cihaz bütünlüğü sinyallerinin ani değişimini izleyin.
  • Müşteri destek kanallarında "banka uygulaması kaldırma / yeniden yükleme" taleplerini olası enfeksiyon göstergesi olarak ele alın.

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

.jpg   tonyukuk-04-hirudo.jpg (Dosya Boyutu: 113.61 KB / İndirme Sayısı: 10) ]]>