Step Finance Treasury Hack’i: Treasury Cüzdanları Neden Hack’leniyor?

Step Finance treasury hack’i, akıllı kontrat açığı olmadan milyonlarca dolarlık fonun nasıl çıkarılabildiğini gösterdi. Bu içerik, treasury cüzdanlarının neden hedef olduğunu, saldırının neden geç fark edildiğini ve hangi operasyonel hataların krizi büyüttüğünü inceliyor.

Bir kripto projesinde hazine cüzdanı (treasury wallet), çoğu zaman “en güvenli alan” olarak kabul edilir. Büyük bakiyeler, çoklu imza yapıları, donanım cüzdanları, sınırlı erişim listeleri… Kâğıt üzerinde bakıldığında her şey yerli yerindedir. Ancak son 48 saat içinde yaşanan Step Finance treasury hack’i, bu varsayımın pratikte ne kadar kırılgan olabileceğini sert bir şekilde hatırlattı.

Yaklaşık 27–30 milyon USD değerinde fon, teknik olarak yetkili ve geçerli görünen işlemlerle Step Finance’in treasury cüzdanlarından dışarı çıktı. Ne bir akıllı kontrat açığı vardı ne de zincir üzerinde “şüpheli” görünen bir exploit. Zincir kurallarına göre her şey olması gerektiği gibiydi. Tam da bu yüzden bu saldırı, klasik hack anlatılarından çok daha tehlikeliydi.

Bu vakayı kritik yapan şey, saldırının nasıl gerçekleştiğinden çok, neden uzun süre fark edilmediği. Çünkü saldırgan zinciri kırmadı; zinciri kullanan yapının alışkanlıklarını, süreçlerini ve “zaten güvenli” kabul edilen varsayımlarını hedef aldı. Treasury güvenliğinin zayıf halkası kod değil, çoğu zaman operasyonel refleksler oldu.

Son yıllarda yaşanan treasury saldırılarının ortak noktası da tam olarak bu: Neredeyse hiçbiri olağanüstü bir teknik sihirle gerçekleşmiyor. Asıl risk, zaman içinde normalleşen davranışlar, sorgulanmayan onay akışları ve “bizde olmaz” düşüncesiyle büyüyor. Bu nedenle hazine cüzdanları artık yalnızca teknik bir güvenlik konusu değil; doğrudan yönetişim, süreç disiplini ve karar alma biçimi meselesi.

Bu yazıda, Step Finance treasury hack’ini merkezine alarak şu soruya odaklanıyorum: Hazine cüzdanları neden bu kadar sık hedef alınıyor ve neden hâlâ aynı hatalar tekrar ediliyor?

Bir Treasury Saldırısı Bir Projeyi Saatler İçinde Nasıl Likidite Krizine Sürükler?

Kripto ekosisteminde “tek gecede” yaşanan likidite krizleri aslında bir gecede başlamaz. Bu krizler çoğu zaman haftalar, hatta aylar boyunca sessizce hazırlanır. Treasury saldırılarında olay anı hızlıdır; ancak saldırganın hazırlığı yavaştır.

Step Finance vakasında da görüldüğü gibi, zincir üstü davranışlar uzun süre izlenir, normal kabul edilen işlem kalıpları öğrenilir ve operasyonel refleksler test edilir.

Saldırgan için kritik sorular şunlardır:

• Hangi adresler rutin kullanılıyor?
• Hangi saatlerde transferler yapılıyor?
• Kimler imzacı, hangi işlemler “olağan” sayılıyor?
• Hangi eşiklerde alarm üretiliyor, hangilerinde üretilmiyor?

Bu bilgiler bir araya geldiğinde, saldırı artık bir “deneme” olmaktan çıkar ve planlı bir operasyon haline gelir. Step Finance saldırısında da fon çıkışları, tek bir büyük patlama şeklinde değil; sistemin dikkatini çekmeyecek şekilde, yetkili ve meşru görünen akışlar üzerinden gerçekleşti. Bu da saldırının ilk aşamalarının fark edilmesini geciktirdi.

Treasury cüzdanından çıkan fonun etkisi ise yalnızca bilanço ile sınırlı değildir. Birçok projede treasury; likidite sağlama anlaşmalarını, market-making yükümlülüklerini, partner ödemelerini ve kimi zaman kullanıcıya geri ödeme süreçlerini finanse eder. Bu nedenle treasury’de yaşanan tek bir güvenlik olayı, çok kısa sürede operasyonel bir kilitlenmeye dönüşebilir.

Step Finance vakasında olduğu gibi, saldırı fark edildiğinde çoğu zaman şu tablo ortaya çıkar:

Fonların önemli bir kısmı çoktan hareket etmiştir. Operasyon ekipleri eş zamanlı olarak hem teknik analizi hem de kriz yönetimini yürütmek zorunda kalır. Dışarıdan bakıldığında “sadece bir hack” gibi görünen olay, içeride hızla yönetimsel bir stres testine dönüşür.

Bazı treasury saldırıları daha da sessiz ilerler. Fonlar tek seferde değil, parça parça çıkarılır. Operasyonel aksaklıklar “gecikme”, “piyasa koşulları” veya “yoğunluk” ile açıklanır. Saldırı ihtimali geç fark edilir. Oysa bu gecikme, saldırganın en çok kazandığı zamandır. Çünkü zincir üzerinde her şey hâlâ “kurallara uygun” görünmektedir.

İşte bu noktada kritik gerçek ortaya çıkar: Bir treasury saldırısı, yalnızca teknik bir güvenlik ihlali değil; likidite, itibar ve yönetişim krizinin aynı anda tetiklenmesidir. Kod tarafı çökmese bile, güven duygusu çöker. Ve bu, bir proje için en zor toparlanan kayıptır.

Treasury Wallet Gerçekten Nedir?

Treasury wallet, yalnızca büyük miktarda varlık tutan bir adres değildir. Çoğu projede treasury, bir cüzdan topolojisidir: sıcak, ılık ve soğuk cüzdanlar; çoklu imza kasaları; operasyonel ödemeler için limitli adresler; likidite ve borsa transferleri için ayrılmış hatlar. Sağlıklı yapılarda treasury, iş akışına paralel olarak bölünür.

Bu yüzden treasury güvenliğini değerlendirirken ilk soru “ne kadar fon var?” değil, “bu fonlar nasıl ve hangi koşullarda hareket ediyor?” olmalıdır. Hangi işlemler otomatik, hangileri manuel? Hangi adresler whitelist’te? Hangi imza eşikleri geçerli? Bu soruların cevapları, treasury’nin gerçek risk profilini belirler.

Ayrıca treasury yalnızca zincir üstü bir yapı değildir. Anahtarlar zincir dışında yaşar: cihazlarda, tarayıcılarda, erişim yönetimi sistemlerinde, CI/CD hatlarında, hatta yöneticilerin günlük çalışma alışkanlıklarında. Bu yüzden treasury güvenliği, yalnızca “doğru wallet aracı seçimi” ile çözülemez.

Saldırganlar Treasury Wallet’ları Neden Hedefler?

Saldırgan perspektifinden bakıldığında treasury cüzdanları yüksek getiri–düşük tekrar oranı sunar. Tek bir hedef, büyük etki. Üstelik birçok proje şeffaflık adına treasury adreslerini paylaşır. Bu iyi niyet, saldırgan için keşif süresini ciddi şekilde kısaltır.

Bir diğer neden, treasury tarafında operasyonel istisnaların kaçınılmaz olmasıdır. Ürün tarafı hız ister, finans ödemeyi ister, partner deadline ister. Bu baskılar altında “geçici” çözümler üretilir. Ancak bu geçici çözümler zamanla kalıcı hale gelir. Saldırganın aradığı boşluklar tam da burada oluşur.

Üçüncü ve belki de en kritik neden, sahipliğin dağınıklığıdır. Treasury çoğu zaman güvenlik, finans ve operasyon ekiplerinin kesişiminde yer alır. Net sahiplik yoksa, kontroller de net olmaz.

Saldırgan için en verimli zemin, “bunun sorumlusu kimdi?” sorusunun net cevaplanamadığı yapılardır.

Treasury Wallet Güvenliğinde Yapılan 5 Kritik Hata

Hata 1 – Tekil Anahtar ve Yetki Konsantrasyonu

Çoklu imza veya MPC yapıları kağıt üzerinde vardır; ancak pratikte karar alma ve operasyonel kontrol birkaç kişide toplanır. İmzacıların aynı ekipten, aynı cihaz standartlarıyla ve aynı iletişim kanalları üzerinden hareket etmesi, imza bağımsızlığını ortadan kaldırır.

Bu durumda saldırgan için hedef hâlâ tektir. Bir imzacının ortamı ele geçirildiğinde, sosyal mühendislik yoluyla diğer imzalar da toplanabilir. Multi-sig burada güvenlik değil, gecikme üretir.

Hata 2 – Hot Wallet’ların Yanlış Konumlandırılması

Hot wallet’lar operasyonel hız için vardır; ancak birçok projede zamanla ana kasa gibi kullanılmaya başlanır. Günlük ödemeler, acil transferler derken bu cüzdanlarda tutulan bakiye artar.

Hot wallet’ların temas ettiği yüzeyler fazladır: API’ler, bot’lar, otomasyonlar, üçüncü parti servisler. Bu yüzeylerden biri zayıfladığında, saldırgan çok kısa sürede büyük etki yaratabilir.

Hata 3 – İşlem Onay Süreçlerinin Kontrolsüz Otomasyonu

Otomasyon verimlilik sağlar; fakat bağlam kontrolü yoksa hatayı ölçekler. Script’ler ve bot’lar yanlış yapılandırıldığında, saniyeler içinde ciddi fon hareketleri üretebilir.

Birçok vakada saldırgan doğrudan cüzdan anahtarını çalmaz; otomasyonun çalıştığı ortamı ele geçirir. Sistem “meşru” şekilde çalışmaya devam ederken fonlar yanlış adreslere akar.

Hata 4 – İzleme ve Anomali Tespitinin Zayıf Olması

Treasury hareketlerinin davranışsal bir profili vardır: olağan saatler, olağan muhataplar, olağan miktarlar. Bu profilin dışına çıkan her işlem teknik olarak yetkili olsa bile incelenmelidir.

Sorun çoğu zaman araç eksikliği değil, süreç eksikliğidir. Alarm gelir ama kim bakacak, ne zaman aksiyon alınacak, hangi noktada incident sayılacak belli değildir.

Hata 5 – Incident Response Planının Kâğıt Üzerinde Kalması

Treasury saldırılarında ilk dakikalar kritiktir. Buna rağmen birçok organizasyonda IR planı test edilmemiştir. Kim kimi arayacak, hangi cüzdanlar dondurulacak, hangi otomasyonlar durdurulacak net değildir.

Planın varlığı değil, çalışırlığı önemlidir. Test edilmemiş plan, kriz anında yok hükmündedir.

30 Milyon USD’lik Saldırı Teknik Olarak Nasıl Gerçekleşti?

Son 48 saat içinde kripto dünyası, Solana ekosistemindeki analiz ve portföy aracı Step Finance’in treasury (hazine) cüzdanlarına yönelik büyük bir güvenlik ihlaliyle sarsıldı. Olay, sadece büyük bir fon çıkışı olarak kalmadı; aynı zamanda modern treasury saldırılarının teknik karakterini de net şekilde ortaya koydu.

Resmî açıklamalara göre bu saldırıda yaklaşık 27–30 milyon USD değerindeki varlık, Step Finance’in kimi treasury cüzdanlarından beklenmeyen şekilde dışarı çıktı. Olayın en dikkat çekici tarafı şu: Zincir üzerinde bu çıkış işlemleri teknik olarak yetkili ve geçerli imzalı görünüyordu. Ne bir “reentrancy” açığı ne de klasik bir smart contract error’ı tetiklenmişti. Saldırgan, sistemin izin verdiği akışları suistimal ederek fonları dışarıya aktardı.

Bu vakayı teknik anlamda ayakta tutan temel faktör, saldırganın doğrudan private key’i çalmaktan ziyade yetkili işlem akışını manipüle etmesi oldu. Yani zincir dışı ortamda ele geçirilen bir imza bağlamı üzerinden sistem, saldırıyı “meşru bir operasyon” gibi değerlendirdi ve onay verdi.

Aşama 1 – İmza Bağlamının Kompromize Edilmesi

Analizlere göre saldırgan, Step Finance’in operasyonel imzacı ortamına zincir dışı erişim sağladı. Bu tür erişimler genellikle şu kanallardan gelir:

• Wallet uygulaması oturum bilgilerinin ele geçirilmesi
• Kullanılan cihaz veya tarayıcı profilindeki güvenlik zafiyeti
• CI/CD veya yönetim paneli gibi operasyon araçlarının token sızdırması

Bu olayda saldırgan doğrudan cüzdan anahtarını ele geçirmedi; bunun yerine imzaları üretme yeteneğini doğrudan etkileyen bağlamı ele geçirdi.

Teknik olarak sistem için bu durum şöyle görünür: “Bu imza geçerli. Bu adres yetkili.”

Bu sebeple zincir üstü izlemede ilk anda hiçbir anormallik görünmedi.

Aşama 2 – İlk Küçük Çıkışlar: Alarmı Bypass Etme

Saldırgan, doğrudan büyük bir transfer yapmak yerine önce daha küçük çıkışlarla sistemi test etti. Bu çıkışlar:

• Daha önce yapılan operasyonlarla benzer saatlerde
• Olağan gas ayarlarıyla
• Olağan muhatap adres tiplerine benzer adreslere şekilde gerçekleştirildi.

Bu teknik yaklaşımın iki önemli sonucu oldu:

Zincir üstü anomali tespit sistemleri çoğu zaman “eşik değer” bazlıdır; burada örneğin 5–10 ETH üzeri transfer alarm üretir. Küçük çıkışlar bu alarm eşiğini tetiklemedi.

Operasyon ekiplerinin bakışında bu transferler “benzer transfer kalıbı” olarak değerlendirildi. Bu nedenle erken uyarı mekanizması devreye girmedi.

Aşama 3 – Parçalı Büyük Çıkışlar

İlk aşamanın sorunsuz geçmesinin ardından saldırgan fon çıkışını ölçekledi. Bu noktada saldırı stratejisi şu hale geldi: Fonlar tek seferde değil, parça parça ve zamana yayılmış şekilde çıkarıldı. Ara adresler ve farklı muhataplar kullanıldı Adımlar birbirine bağlanarak, operasyonun batıltısız gibi görünmesi sürdürüldü

Bu teknik model, klasik “big transfer, big alarm” türü değil; daha sofistike bir davranışsal modeldir. Sistemdeki izleme mekanizmaları da bu davranışları “normal bir operasyon” sinyali olarak algıladı.

Aşama 4 – Fark Edildiğinde Artık Büyük Kısım Tamamlanmıştı

Saldırı yalnızca zincir üzerinde bir büyük çıkışla fark edilmedi. İlk fark edilen sinyal, ekibin dashboard’unda beklenmedik bir bakiye uyumsuzluğu oldu — yani teknik analiz değil, operasyonel bir dengesizlik raporu olayı tetikledi.

Bu ana kadar saldırganın tüm işlemleri zincir üzerindeki mevcut izinlerle yapmış olması, izleme sistemlerini yanıltmıştı. Bir kere olay fark edildiğinde ise saldırgan, kalan fonları hızla ara adreslere yönlendirmeye başlamıştı.

Bu Saldırıyı Durdurmak İçin Ne Gerekirdi?

Bu vakada saldırının erken safhasında durdurulması için birkaç kritik kontrol noktası bulunuyordu:

1. Bağlam Bazlı İmza Analizi: Sistem sadece “imza geçerli mi?” dememeli; “bu imza bu bağlamda bekleniyor mu?” diye bağlam analizini de değerlendirmelidir. Bu örnekte, imzacı ortamına dair bağlam manipüle edildiği için klasik kontroller yetersiz kaldı.

2. Davranışsal Anomali İzleme: Saldırgan small-steps stratejisini kullandı. Bu nedenle izleme, tek transfer büyüklüğü yerine zincir içi davranış profili korelasyonu ile alarm üretmelidir (örneğin adres, saat, transfer paterni).

3. Treasury Adresi İçin Kill-Switch: Birçok operasyonel treasury yapısı, olağan üstü durumda anahtar kesme (kill-switch) veya programmable pause mekanizması barındırmaz. Bu olayda böyle bir mekanizma olsaydı, ilk alarm anında süreci durdurmak mümkündü.

4. Off-Chain Operasyonel İzleme: Bu saldırıda kritik olan nokta zincir dışı bağlamdı. Off-chain sinyaller (device anomaly, session anomaly, session origin) SIEM veya UBA gibi sistemlerle korele edilseydi, bu erken sinyallerle saldırı daha hızlı fark edilebilirdi.

   Sonuç – Step Finance Treasury Hack’in Mesajı

   Bu saldırı klasik bir smart contract exploit’i değildir. Saldırganı “teknik zekâsı” değil; sistemin varsayılan güvenlik kabulleri başarılı kıldı. Step Finance Treasury saldırısı bize şunu açıkça gösteriyor: Yetkili görünen akışlar, bağlamı yanıtlamıyor. Zincir, imzaya bakar; saldırgan ise bağlama. Bu fark, modern treasury hack’lerinin en tehlikeli kısmıdır.

   Teknikten Kullanıcı Odağına: Bu Saldırı Sizi Neden Doğrudan İlgilendiriyor?

   Buraya kadar anlatılanlar teknik görünebilir. İmza bağlamları, otomasyonlar, davranışsal izleme, kill-switch’ler… Ancak bu saldırının asıl önemi teknik detaylarda değil, bu detayların kullanıcı ve organizasyon davranışıyla nasıl birleştiğinde felakete dönüştüğünde yatıyor.

Son 48 saatte yaşanan bu vaka bize şunu açıkça gösterdi: Saldırganın kazancı, sistemdeki teknik bir “açık”tan değil; insanların ve ekiplerin “zaten güvenli” varsayımıyla hareket etmesinden geliyor. Treasury yapısında çalışan herkes — yönetici, finans, operasyon, ürün ya da güvenlik — zincirin bir halkası. Bu halkalardan biri zayıfladığında, saldırgan teknik olarak kusursuz bir akışı kendi lehine çevirebiliyor.

Bu noktada kullanıcı odağı şuradan başlıyor: Eğer bir projede fon hareketlerini onaylıyor, tetikliyor, izliyor ya da “sonradan bakarız” diyorsan; bu saldırının hedef kitlesindesin. Çünkü bu vakada görüldüğü gibi, saldırıyı mümkün kılan şey teknik karmaşıklık değil; alışkanlıkların sorgulanmaması.

Birçok ekip şu yanılgıya düşüyor: “Bu kadar teknik bir saldırı ancak çok büyük yapılarda olur.” Oysa gerçek tam tersi. Büyük yapılar genellikle daha fazla göz, daha fazla süreç ve daha fazla izleme katmanına sahiptir. Orta ve hızlı büyüyen yapılar ise hız, pratiklik ve güven ilişkileri üzerinden hareket eder. Saldırgan için ideal zemin de burasıdır.

Bu saldırıyı yaşayan yapının büyüklüğü değil, olgunluk seviyesindeki kör noktalar belirleyici oldu:

• İmzalar yetkiliydi ama bağlam sorgulanmıyordu
• İşlemler meşru görünüyordu ama davranışsal olarak izlenmiyordu
• Alarm yoktu çünkü “olağan” kalıpların dışına çıkılmamıştı
• Incident planı vardı ama ilk dakikalarda devreye girecek refleks net değildi

Burada durup kendine şu soruları sormak, kullanıcı açısından en kritik adımdır:

• Bir imza talebi geldiğinde, gerçekten neden geldiğini sorguluyor muyuz?
• Bir treasury transferi “alışıldık” olduğu için otomatik mi kabul ediliyor?
• Küçük transferlerin bir araya geldiğinde büyük bir risk oluşturabileceğini izliyor muyuz?
• “Yetkiliydi” ile “doğruydu” arasındaki farkı operasyonel olarak ayırabiliyor muyuz?

Bu soruların rahatsız edici olmasının sebebi şu: Çoğu zaman cevaplar teknik değil, kültüreldir.

İşte kullanıcı odağı tam burada devreye girer. Treasury güvenliği, yalnızca teknik ekibin problemi değildir. Fonla temas eden herkes, bu yapının doğal bir parçasıdır.

Saldırganın zinciri kırmak için tek bir kişiye ihtiyacı varken, savunmanın çalışması için herkesin aynı farkındalıkta olması gerekir.

Step Finance Treasury Saldırısı Bize Ne Öğretiyor?

Step Finance treasury saldırısı, kripto ekosisteminin artık hangi evrede olduğunu çok net biçimde gösterdi. Bu olay, klasik “akıllı kontrat açığı” ya da “özel anahtar çalındı” anlatılarından biri değil. Aksine, teknik olarak yetkili görünen, imzalı ve zincir kurallarına tamamen uygun işlemler üzerinden yaklaşık 27–30 milyon USD değerinde fonun treasury cüzdanlarından dışarı taşındığı bir vaka.

Bu saldırıyı tehlikeli yapan şey, karmaşık bir exploit değil; tam tersine, sistemin normal çalışıyor gibi görünmesi. Zincir açısından bakıldığında her şey kurallara uygundu. İmzalar geçerliydi. Adresler yetkiliydi. İşlemler reddedilmedi. Ancak saldırgan, zinciri değil, zinciri kullanan yapının alışkanlıklarını ve varsayımlarını hedef aldı.

Step Finance vakası bize şunu açıkça söylüyor: Saldırılar artık “daha akıllı” değil, daha insani. Koddan çok davranışı, kontrattan çok süreci, anahtardan çok imza bağlamını hedef alıyorlar. Yetkilerden ziyade, yetkilerin nasıl ve hangi koşullarda kullanıldığını istismar ediyorlar.

Bu nedenle treasury güvenliği, hiçbir zaman “kuruldu ve bitti” denebilecek bir alan olmadı. Ancak Step Finance örneğiyle birlikte bu gerçek artık çok daha görünür. Multi-sig kullanmak, cold wallet’a sahip olmak, prosedür yazmak hâlâ çok önemli. Fakat bunların hiçbiri, şu soru sorulmadığında tek başına yeterli değil:

“Bu işlemi neden, neden şimdi ve gerçekten doğru bağlamda mı yapıyoruz?”

Bu yazıda detaylandırılan saldırı zinciri bize şunu gösteriyor: Güvenlik ihlalleri çoğu zaman tek bir büyük hatadan değil, birbirini besleyen küçük varsayımların toplamından doğuyor. Her biri tek başına “makul” görünen kararlar, bir araya geldiğinde saldırgan için kusursuz bir yol açıyor.

Gerçek koruma, şu üç unsur bir araya geldiğinde başlıyor:

• Teknik kontroller: İmza yapıları, davranışsal izleme, otomasyon sınırları
• Süreç disiplini: Yetki ayrımı, onay bağlamı, incident refleksi
• Kullanıcı farkındalığı: “Neden?”, “Ne zaman?”, “Ne oluyor?” sorularını sorma alışkanlığı

Bu üçlüden biri eksikse, saldırı kaçınılmaz olmasa bile etkisi büyüyor. Step Finance vakasında gördüğümüz gibi, sistem teknik olarak çalışırken organizasyonel refleksler yetersiz kaldığında sonuç ağır oluyor.

Bu üçlüden biri eksikse, saldırı kaçınılmaz olmasa bile etkisi büyür.

Yazarın Notu

Güvenlik Bir Araç Değil, Bir Reflekstir..

Bu yazıyı, yalnızca Step Finance’te yaşanan bir olayı anlatmak için değil; bu vakanın neden bu kadar tanıdık hissettirdiğini göstermek için yazdım. Çünkü neredeyse her treasury saldırısından sonra duyulan cümle aynıdır: “Aslında bakınca sinyaller vardı.”

Güvenlik, bu sinyalleri olaydan sonra okumak değil; olay olmadan önce fark edebilmektir. Bu da sadece teknik bilgiyle değil, sürekli farkındalıkla mümkündür. Treasury güvenliği, bir ürün ya da araç meselesi değil; organizasyonel bir refleks meselesidir.

İşte bu noktada Gate TR Akademi devreye giriyor. Gate TR Akademi’de amacımız; güvenliği yalnızca teknik ekiplerin konuştuğu bir konu olmaktan çıkarıp, kullanıcıyı, yöneticiyi ve operasyonu aynı zeminde buluşturmak. Çünkü sürdürülebilir güvenlik, herkes neyi neden yaptığını anladığında mümkün oluyor.

Eğer Step Finance vakası size kendi treasury yapınızla ilgili tek bir rahatsız edici soruyu bile sordurduysa, doğru yerdeyiz.

Güvenle kalın.

Yazar: Meltem Erdem
Editör: Gate TR Akademi Ekibi