Smart Contracts 🧭 | Crypto Bots 🤖 AI Security Research 🧠 Ex-C4 Warden 🐺 | Sherlock Lead Judge 🕵️♂️ Audit Portfolio ⇣ https://teapawt.org/t.co/fvkDWCDVxU
Joined May 2020
- Tweets12.9K
- Following292
- Followers36.7K
- Likes14.3K
Pinned Tweet
1️⃣ Kripto hesabının gizli anahtarı hackerların eline geçmiş, cüzdanına bot kurulmuş bir hesaptaki stake de 90.000 USD’lik #AVAX ve 1 haftalık süremiz var !
Bu hafta #Avalanche ağında büyük bir mücadele ile en tehlikeli botlardan biri ile savaşarak , stake’teki AVAX ları kurtarmak için blockchainin karanlık ormanına daldım
Avalanche P-Chain’de geçen bu 1 haftalık mücadelemizin detayları ve 90.000 USD’lik AVAX’ı nasıl kurtardığımın hikayesi aşağıda 👇👇
Smart Contract retweeted
Yıllarca bize "Aman kriptodan uzak durun, böyle yerlerde paranız buhar olur, muhatap bulamazsınız; gelin devlet güvencesindeki kurumsal sermaye piyasalarına yatırım yapın" diye kamu spotu çektiler.
Geçen hafta o "başıboş, tehlikeli, merkeziyetsiz" dedikleri özel bir şirket olan Binance, Kuzey Koreli hackerlara 6,4 milyar dolar (250 milyar TL’den fazla) çaldırdı.
Ve dün ne oldu? Tek bir müşterisinin hesabından 1 kuruş bile eksilmedi; şirket çıkıp "Zararı kendi kasamızdan ve sigorta fonumuzdan kapattık, herkes parasını çekebilir" dedi ve konuyu 48 saatte kapattı.
Peki bizim 103 yıllık asırlık devlet geleneğimizin; SPK’sının, BDDK’sının, Takasbank’ının, MKK’sının, bağımsız denetim kuruluşlarının ve saklama bankalarının o çok güvenli yatırım fonlarında durum ne?
455 bin vatandaşın parası, hem de dünyanın en risksiz aracı sayılan Para Piyasası Fonlarında (PPF), tam 45 gündür içeride rehin! Ne Kuzey Koreli hacker saldırdı ne de sistem çöktü; bizzat "denetliyoruz" dedikleri masalarda buharlaşan paraların faturasını aylardır sade vatandaşa ödetiyorlar. Üstüne bir de çıkıp "Tasfiye ne zaman biterse o zaman bakarız, zaten fonun ortağısınız" diye hukuk dersi veriyorlar.
Özel bir kripto borsası 6,4 milyar dolarlık siber saldırıyı kendi cebinden 1 günde telafi ederken; koskoca regülasyon mekanizması kendi gözetiminde dönen usulsüzlüğün bedelini 455 bin tasarruf sahibinin sırtına yıkıp kenara çekiliyor.
Meğer asıl yüksek risk AKP imiş, onun yandaşlarla dolu SPK'sı Takasbank’ı imiş...
#TamAnaParaHemenYoksaistifa
#AnaParaYaDaHemenSecim
#SPK #Fonzede #Takasbank #PPF #Binance
🚨 If I Were Running a Centralized Exchange, I Would Hire These White-Hat Hackers!
Bybit: $1.5 billion.
Binance: $6.3 billion.
I think centralized crypto exchanges (CEXs) really need to change their security approach.
Because blockchain cryptography is not being broken. In most cases, hackers exploit signing infrastructure, authorization systems, software, and operational security weaknesses.
So, what is the solution?
If I were running a centralized exchange, I would put the world's best White-Hat Security Researchers at the center of my security team.
Why do I think this?
Let's look at decentralized exchanges (DEXs) and the DeFi ecosystem.
DEXs and CEXs work differently. Also, DEXs have experienced many serious hacks too. So comparing them directly may not be completely fair.
But DeFi has developed a very valuable security culture:
Open-source, independent audits, competitive auditing contests, bug bounty programs, formal verification, and continuous security testing by white-hat researchers.
This is what CEXs should learn from DeFi.
🛡️ If I Were Running a CEX, I Would Work With These Researchers First:
🔹 @samczsun
One of the most respected names in blockchain security. He has great experience in finding critical vulnerabilities before hackers, white-hat recovery operations, and emergency response systems like SEAL 911.
I would work with someone like him not only for audits, but also to build a real Emergency Response Architecture.
🔹 @0xRajeev
He has made important contributions to smart contract security education and training new security researchers.
I would use his approach to help exchange developers become not only good coders, but also security engineers who understand how hackers think and attack.
🔹 @trust__90
Researchers who can find complex business logic bugs, authorization problems, and unexpected edge cases are extremely valuable.
I would ask independent researchers like him to review wallet authorization, nonce, delegation, and signature validation systems.
🔹 @pashov
Pashov Audit Group is one of the well-known teams organizing independent security researchers for professional audits.
I would use this kind of team for multi-layer security audits of exchange wallets, smart contracts, and custody infrastructure.
🔹 @tpiliposian
A security researcher working at Certora, focusing on smart contract security, formal verification, and AI-assisted security auditing.
I would use his approach to mathematically verify important security rules instead of depending only on manual audits.
I would especially want CEX signing policies, access controls, and transaction validation systems to be tested with formal verification methods.
🔹 @windhustler
An experienced security researcher from the Spearbit ecosystem, with many independent audits and strong results in competitive auditing contests.
His work on LayerZero, omnichain protocols, cross-chain transfers, bridges, and DeFi security is especially interesting.
I would work with researchers like him to audit cross-chain asset transfers, bridge integrations, and smart contract systems used by CEXs.
🔹 @cmichelio
Christoph Michel is one of the most successful Code4rena researchers. In 2022, he became the first researcher on the platform to reach $1 million in total audit rewards.
He is also involved in the Spearbit and Cantina ecosystems, with deep knowledge of DeFi exploits, Solidity security, and complex protocol logic.
I would ask him to review business logic vulnerabilities, economic exploits, and authorization mechanisms, and run independent security tests.
🔹 @ChaseTheLight99
I would like to benefit from his work on automated security tools and researcher-focused tooling.
🔹 @GalloDaSballo
I would also look at his work on testing, fuzzing, invariant testing, and testing different attack scenarios in a systematic way.
If I were running a centralized exchange, I would not be satisfied with getting audits from only a few security companies.
I would bring these researchers and the teams they have trained into a continuous and independent security ecosystem.
Because after the Bybit and Binance hacks, we should ask ourselves one important question:
Is keeping a private key safe enough? Or do we also need independent researchers to continuously test what that key is allowed to sign?
For me, the answer is very clear :White-hat hackers should find the vulnerabilities before malicious hackers do.
Türkiye'deki Kripto Borsalarına : Geleneksel Siber Güvenlik Artık Yeterli Değil!
@BinanceTR , @ParibuCom , @btcturk , @garantibbvakrp ve Türkiye'de faaliyet gösteren diğer merkezi borsalara...
Bybit'te 1,5 milyar dolar, Binance'ın son saldırısında yaklaşık 6,3 milyar dolar!
Her iki olay da bize aynı gerçeği gösteriyor:
Kriptografi kırılmadı. Güvenlik mimarisi ve yetkilendirme mekanizmaları istismar edildi.
HSM, MPC, multisig, firewall ve geleneksel pentest kullanmak tek başına yeterli değil.
Artık saldırganlar yalnızca private key çalmıyor. İmzalama altyapılarını, transaction approval sistemlerini, geliştirici erişimlerini ve akıllı kontrat yetkilerini hedef alıyor.
Peki Türkiye'deki borsalar ne yapmalı?
1️⃣ Underground Security Researcher ve Bug Bounty Ekipleri
Kurumsal güvenlik ekiplerinin yanına, gerçek saldırı tekniklerini bilen bağımsız white-hat araştırmacıları dahil edilmeli.
• Dünya çapında Spearbit, Sherlock, Immunefi gibi platformlarda çalışan güvenlik araştırmacılarıyla iş birliği kurulmalı.
• Kritik bulgular için yüksek ödüllü bug bounty ve güvenli açıklama programları oluşturulmalı.Şuan neredeyse çoğunda yok veya tutarlar komik
Saldırganın nasıl düşündüğünü anlamadan etkili bir savunma tasarlayamazsınız.
2️⃣ Kendi Borsanızı Sürekli Test Edin
Yılda birkaç defa pentest yaptırmak artık yeterli değil.
Yetkilendirilmiş ve kontrollü ortamlarda sürekli saldırı simülasyonları yapılmalı.
Özellikle şu senaryolar test edilmeli:
• DevOps hesabının ele geçirilmesi
• İmzalama API'sinin kötüye kullanılması
• HSM/MPC imza yetkisinin manipülasyonu
• EIP-7702 zararlı delegation saldırıları
• Mempool front-running ve nonce yarışları
• Çoklu blockchain ağlarında eş zamanlı para çekme saldırıları
Amaç yalnızca açığı bulmak değil, güvenlik sisteminin saldırıyı kaç saniyede tespit edip durdurduğunu ölçmek olmalı.
3️⃣ Private Key Güvenliği Yetmez: Signing Policy Security
Bana göre en kritik konu bu.
Private key'in özel saklanması , imzalama servisinin güvenli olduğu anlamına gelmez.
Sistem kontrolsüz biçimde herhangi bir 32 baytlık hash'i imzalayabiliyorsa, saldırgan private key'i görmeden de zararlı işlemler imzalatabilir.
Bu nedenle:
• HSM/MPC üzerinde bağımsız işlem politikaları uygulanmalı.
• Keyfi yetkileri sınırlandırılmalı.
• EIP-7702 authorization, delegateAddress, chainId ve işlem içerikleri ayrı ayrı doğrulanmalı.
• Soğuk cüzdanlarda bağımsız imza ve işlem doğrulama mekanizmaları bulunmalı.
• Büyük transferler için threshold signing ve bağımsız onay kullanılmalı.
Asıl güvenlik sorusu, private key'in nerede olduğu değil, hangi koşullarda neyi imzalayabildiğidir.
4️⃣ AI Destekli On-Chain Güvenlik Botları
Artık milyonlarca blockchain hareketinin elle incelenmesini bekleyemeyiz.
Borsalar 7/24 çalışan, blok ve mempool seviyesinde gerçek zamanlı izleme sistemleri geliştirmeli.
Bu sistemler:
• Şüpheli EIP-7702 delegation değişikliklerini izlemeli.
• Olağan dışı ERC-20 approve, permit ve token transferlerini analiz etmeli.
• Çoklu adreslere dağıtılan fonları graph analytics ile takip etmeli.
• Private orderflow ihtimaline karşı yalnızca public mempool'a güvenmemeli.
• Kritik durumlarda önceden tanımlanmış, yetki sınırları belirlenmiş emergency response mekanizmalarını devreye almalı.
AI tespit ve analizde kullanılmalı; kritik müdahaleler ise doğrulanabilir güvenlik politikalarına bağlı olmalı.
5️⃣ Zero Trust: İçeriden Gelen Saldırılara Karşı Savunma
Bybit ve Binance olaylarının ardından özellikle DevOps, CI/CD, signing service ve privileged access güvenliği yeniden ele alınmalı.
• Hiçbir çalışan sınırsız sistem erişimine sahip olmamalı.
• Kritik yetkiler kısa süreli ve gerekçeye bağlı verilmeli.
• Production ortamlarına erişim, bağımsız onay ve güçlü cihaz güvenliğiyle korunmalı.
• Servis hesaplarının anomalileri, erişim kayıtları ve yetki yükseltmeleri gerçek zamanlı izlenmeli.
• İç tehdit analizleri çalışanların özel yaşamına müdahale etmek yerine, işle ilgili ve hukuka uygun güvenlik verilerine dayanmalı.
Zero Trust yalnızca dışarıdaki hacker'a değil, ele geçirilmiş bir iç hesaba karşı da savunmadır.
6️⃣ Hot Wallet ve Cold Wallet Arasına Gerçek Risk Duvarları
Büyük sıcak cüzdanların tek bir yetki ihlaliyle boşaltılabilmesi kabul edilemez.
• Hot wallet bakiyeleri operasyonel ihtiyaçlarla sınırlandırılmalı.
• Büyük para çekme işlemleri bağımsız doğrulama gerektirmeli.
• Yeni çekim adreslerinde risk bazlı bekleme süreleri ve ek kontroller bulunmalı.
• Sıcak cüzdandan soğuk cüzdana veya ters yönde hareketler önceden tanımlanmış işlem politikalarına tabi olmalı.
• Akıllı kontrat cüzdanlarında mümkünse on-chain harcama limitleri ve çoklu doğrulama zorunlu hale getirilmeli.
Bir imzalama servisi ele geçirildiğinde sistemin tamamı kaybedilmemeli.
7️⃣ Proof of Reserves Yetmez: Proof of Security!
Borsalar rezervlerini göstermekle yetinmemeli.
Bağımsız denetim kapsamında şu sorular da cevaplanmalı:
• Signing infrastructure son ne zaman denetlendi?
• Kritik güvenlik bulgularının kaçı giderildi?
• EIP-7702 ve account abstraction riskleri test edildi mi?
• Emergency response sistemleri tatbikatlarda kaç saniyede devreye giriyor?
• Müşteri varlıkları için hangi harcama ve erişim sınırları uygulanıyor?
Güvenliğe ilişkin kritik sırları ifşa etmeden, bu kontrollerin etkinliği bağımsız denetçiler tarafından doğrulanabilir.
🎯 SONUÇ
Türkiye'de kripto varlık sektörü büyürken güvenlik anlayışı da aynı hızda değişmek zorunda.
Sadece büyük güvenlik şirketlerinden hizmet satın almak, sertifika almak veya yılda birkaç pentest yaptırmak yeterli değil.
Borsalar, bağımsız güvenlik araştırmacılarını, AI destekli savunmayı, on-chain monitoring sistemlerini, güçlü signing policy mekanizmalarını ve sürekli Red Team operasyonlarını bir araya getirmeli.
Geleceğin başarılı borsası yalnızca en yüksek işlem hacmine sahip olan değil, saldırı anında müşteri varlıklarını koruyabilen borsa olacak.
Soru artık “Private key'i nasıl koruruz?” değil.
“Private key veya imzalama altyapısı ele geçirilse bile müşteri varlıklarının tamamının çalınmasını nasıl engelleriz?”
Binance ın tarihe geçen hacki ile ilgili yaptığı açıklamada ; bir mühendisinin laptop una sızıldığı için yapıldığını açıkladı, henüz detaylar gelmedi ama 6 milyar USD yi bu şekilde merkezi borsaların yönetmesi çok ilginç
2025 de benzer bir hack Coinbase yaşamıştı, BtcTürk de benzer bir hack yaşanmıştı
Aşağıda checklist gibi sağlam güvenlik yönetimi olmalı merkezi borsaların
Temel sorun ; Üniversitelerden derecelerle mezun olmuş diplomalı mühendislerin profesyonel hırsızlarla mücadele etmesi kolay değil, hacker mantalitesi gerekiyor başarılı mücadele için
Coinbase gibi bir merkezi kripto borsasının bu kadar amatör olarak verilerini çaldırması inanılır gibi değil, bizim ülkemizdeki kripto para borsalarınında çok dikkatli olması önemli çünkü bizim ülkemizde hukuk ve yasalar kripto ya karşı çok acımasız olacaktır, böyle bir olay olması durumunda hem kullanıcılar hem kripto borsaları toptan mağdur olabilir, bu nedenle önlemler sürekli alınmalı ve güncellenmeli
Coinbase Ne Yapsaydı Bu Hack Önlenirdi?
1. Rol Bazlı Erişim Kontrolleri (RBAC)
➡️ Nedir? Her çalışanın sadece işine gereken verilere erişebilmesi.
🧾 Örnek:
Müşteri destek personeli sadece müşterinin adını ve destek taleplerini görebilir; banka hesap bilgilerine veya şifre sistemlerine ulaşamaz.
Tıpkı hastanede temizlik personelinin hasta dosyalarına erişememesi gibi.
Şirket bu kısımda ciddi bir hata yapmışa benziyor
2. "Least Privilege" İlkesi (En Az Yetki)
➡️ Nedir? Çalışanlara sadece yapmaları gereken işlemleri yapabilecek kadar yetki verilmesi.
🔐 Örnek:
Bir stajyere “admin paneline tam erişim” verilmez. Kütüphaneye gittiğinde sadece kitap ödünç alma hakkı verilir, depo anahtarı verilmez.
3. Multi-Party Approval Sistemi (Çok Kişili Onay)
➡️ Nedir? Kritik işlemler yapılmadan önce birden fazla kişinin onayına ihtiyaç duyulması.
🤝 Örnek:
Şirkette büyük para transferleri için hem finans müdürü hem de CEO onayı gerekir.
Tıpkı bankada büyük para çekiminde 2 görevlinin şifreyi birlikte girmesi gibi.
4. Gerçek Zamanlı Outbound Veri Sızıntısı Takibi (DLP)
➡️ Nedir? Sistemde biri dışarıya veri gönderirse, anında fark edilmesi ve engellenmesi.
📡 Örnek:
Bir çalışan e-posta ile Excel dosyasını yetkisiz bir yere göndermeye çalıştığında içinde TC numarası varsa sistem uyarı verir ve gönderimi engeller.
Tıpkı e-Devlet'in “başka birinin bilgilerini indirmeni engellemesi” gibi.
5. Sosyal Mühendislik Eğitimi
➡️ Nedir? Çalışanların kandırılmaya karşı eğitilmesi (özellikle sahte e-postalara veya aramalara).
Eğitim önemli ama gerçek durum senaryoları ile
6. Zorunlu 2FA + YubiKey (İki Aşamalı Kimlik Doğrulama)
➡️ Nedir? Giriş yapmak için sadece şifre yetmez, ikinci bir doğrulama gerekir.
🔑 Örnek:
Giriş yaparken hem şifre girersin hem de telefona gelen kodu (veya fiziksel USB anahtar olan YubiKey’i) takarsın.
Tıpkı kasaya girmek için hem şifre hem anahtar gerekmesi gibi.
Bybit hacki ile Binance hackini karşılaştırdığımızda @circle USDC tarafında ve @tether hızlı bir iş çıkardı
Saldırganın açık penceresi Binance’in sistemleriydi ve o pencere her an kapanabilirdi. Hacker çağrısını sonraki üç buçuk saatte yedi kez tetikledi.
20:04 ile 23:56 arasında dokuz zincirde 17 sıcak cüzdandan 6,3 milyar dolar çekildi.
Yani saldırgan aynı anda hem dokuz zincirde drain yapıyor hem de stablecoin’leri çevirmeye çalışıyordu. Drain edilmemiş varlık, dondurulma riski olan varlıktan daha değerli bir önceliktir her zaman hackerlar için
Bu kadar hızlı reaksiyonuda beklemiyordu muhtemelen
Binance hackinde @range_org in incelemesine göre USDC çıkışları:
- 20:41 UTC: İlk büyük USDC transferi.
- 20:59 UTC: İkinci USDC transferi.
- 21:04:59 UTC: @circle 'ın 823 milyon USDC'yi dondurması.
Yani USDC için ilk transferden sonra yaklaşık 24 dakika, ikinci transferden sonra ise yalnızca 6 dakika da fonlar dondurulmuştu
Saldırgan EIP-7702 için 50 authorization hazırlamış, üç farklı EOA ile dry run testleri yapmış, çoklu ağlarda eş zamanlı saldırı gerçekleştirmiş.Yani operasyonun teknik hazırlık seviyesi oldukça yüksek.
Peki böylesine hazırlıklı bir saldırgan, stablecoinlerin dondurulacağını neden yeterince hesaba katamadı?
Binance hackinde @range_org in incelemesine göre USDC çıkışları:
- 20:41 UTC: İlk büyük USDC transferi.
- 20:59 UTC: İkinci USDC transferi.
- 21:04:59 UTC: @circle 'ın 823 milyon USDC'yi dondurması.
Yani USDC için ilk transferden sonra yaklaşık 24 dakika, ikinci transferden sonra ise yalnızca 6 dakika da fonlar dondurulmuştu
Saldırgan EIP-7702 için 50 authorization hazırlamış, üç farklı EOA ile dry run testleri yapmış, çoklu ağlarda eş zamanlı saldırı gerçekleştirmiş.Yani operasyonun teknik hazırlık seviyesi oldukça yüksek.
Peki böylesine hazırlıklı bir saldırgan, stablecoinlerin dondurulacağını neden yeterince hesaba katamadı?
“Yazılım mühendisliğinin sonu” makalesini okudum
arxiv.org/pdf/2606.05608v1
Ama tezi şu: Kod yazmak sıradanlaşıyor. Artık köşedeki manav, bir akşamda binlerce satırlık bir oyun yazıp derleyebilir, senin kod bilgin artık sıradan
Kod yazan sayısı 0 a inecek , birçok yazılım mühendisi aylardır kod yazmadığını söylüyor .
Kodu AI yazacak. Denetimi de AI yapacak.
Peki İnsan ne yapacak ?
İnsan ; Yapılan denetimin son imzasını atacak , çünkü hiçbir proje AI yapmıştı bizle konunun hiç alakası yok diyemeyecek
web3 güvenliğinin önderlerinden @0xRajeev in güvenliğe bakışı harika ; Tüm finansal hırsızlıklar (Borsalar, fonlar , kriptolar vb.) ın temelinde insan psikolojisi var
AI ile birlikte hırsızlar artık insanın psikolojisini manipüle etmede daha çok yol yönteme sahipler
Binance hack’inde kullanılan EIP-7702 delegate kontratına bakınca saldırganın ne kadar operasyonel düşündüğü daha net görülüyor.
Bu kontrattaki sweep fonksiyonu, saldırının sadece “yetki alıp transfer yapmak” olmadığını; baştan sona optimize edilmiş bir drain/sweep altyapısı olduğunu gösteriyor.
Neden tüm ETH’yi değil de balance - 1 ether gönderiyor?
Kodda dikkat çeken satır şu: to . call{value: bal - 1 ether}("")
Yani cüzdandaki tüm ETH’yi boşaltmıyor, 1 ETH bırakıyor.
Bu çok önemli bir detay.Bu, sadece teknik bir tercih değil, aynı zamanda alarm sistemlerini pas geçmeye yönelik operasyonel bir tasarım.
Merkezi borsalarda ve büyük sıcak cüzdan altyapılarında bazı alarm mekanizmaları “cüzdan tamamen boşaldı mı?”, “bakiye sıfıra mı indi?”, “operasyonel cüzdan kullanılmaz hale mi geldi?” gibi eşiklere duyarlı olabilir.
Saldırganın 1 ETH bırakması: Cüzdanı tamamen “ölü” göstermemek, bazı anlık boşalma alarmlarını tetiklememek, cüzdanı hala operasyonelmiş gibi göstermek, hatta gerektiğinde sonraki çağrılar için kontrat içi davranışı daha kontrollü sürdürmek
amacına hizmet ediyor olabilir.
EIP-7702'de hacker'ın kendi hesabından gönderdiği sweep() işleminin gas ücretini Binance 14 değil, hacker ödüyor. Yani geride bırakılan 1 ETH, saldırganın sweep() fonksiyonunu çalıştırması için gerekli değil.
Ancak bu 1 ETH ı cüzdanda bırakma modelini hacker tokenlar için yapmıyor , bunun nedeni nedir?
1 - Muhtemelen merkezi borsalarda sıcak cüzdanlarda sürekli bir fee için native token bulunmalı mantığından hacker yola çıktı , Ethereum ağı için ETH burada olmalı , ancak bu cüzdanın işleyebilmesi için bir token a ihtiyaç yok ,sadece ETH a ihtiyaç var, bu bir merkezi borsa işleyişi
2- Diğer bir nedenide ; Hesapta fee için bir kısım ETH olması durumunda Binance normal kullanıcı işlemlerine devam edebilirdi , fee olmaması durumunda merkezi borsalar o sıcak cüzdanı kullanmazlar , başka fee nin olduğunu cüzdanı kullanırlar . Burada da tam bu gerçekleşmiş ve hack sonrası Binance kullanıcı işlemlerine devam etmiş ve yine gelen tokenları hacker kendine transfer etmiştir , yani hacker burada tam isabet hedefini gerçekleştirmiştir
3- Neden 1 ETH da , 0.5 ETH değil ; Yine burada bir eşiğin olabileceğini hacker tahmin ediyordu , bu eşiği tam kestiremediği içinde işi şansa bırakmamak adına 1 ETH gibi yüksek bir tutarı bıraktı
🚨 Binance Hack: EIP-7702, 50 Nonce ve Mempool Güvenlik Botları Hakkında Yanlış Bilinenler
Binance saldırısının ardından EIP-7702 bir anda kripto dünyasının en çok konuşulan konularından biri oldu.
İlk başta saldırının nedeni EIP-7702'ymiş gibi X de tweet ler geldi , oysa zamanla anlaşıldı ki EIP-7702'de kırılmış bir kriptografik mekanizma yok. Saldırgan, mevcut bir Ethereum özelliğini saldırı aracı olarak kullandı. Ama bu özelliği kullanmasının çok ince nedeni vardı ; Binance ın güvenlik botlarını pass geçebilmek
Ancak bence asıl ilginç olan, saldırının kendisinden çok, X'te yayılan teknik yorumlar.
Özellikle hacker'ın neden 50 farklı EIP-7702 authorization nonce'u kullandığı konusunda birçok paylaşım eksik bir açıklamaya dayanıyor.
Hatta yapay zekalar bile çoğu zaman aynı açıklamayı tekrar ediyor.Son dönemde ilk kez AI lerin bile tam anlayamadığı bir olay görüyorum
Önce olaya bakalım.
29 Ekim 2026'da saldırgan, Binance 14 sıcak cüzdanını hedefleyen tek bir Type-4 transaction gönderdi. (Type-4 demek işlemin EIP 7702 ile yetkilendirme yapıldığını gösterir)
Bu işlemin içerisinde 50 farklı EIP-7702 authorization bulunuyordu.
Nonce aralığı: 18914775–18914824
Yalnızca 18914809 nonce'u geçerli oldu.
Sonuç olarak Binance 14, saldırganın zararlı akıllı kontratına delege edildi.
Tam 3 dakika 24 saniye sonra saldırgan, bu delegation üzerinden yaklaşık 167.464 ETH ve 63 farklı token bakiyesini tek işlemde boşalttı.
Peki neden 50 nonce?
50 tane aynı işlemi 50 kez tekrar göndermiş oldu
X'teki yaygın açıklama şu:
"Binance çok yoğun çalışan bir sıcak cüzdan. Transaction nonce sürekli değiştiği için hacker doğru nonce'u yakalamak amacıyla 50 farklı imza hazırladı."
Bu açıklama tamamen yanlış değil, ancak güvenlik açısından çok önemli bir ayrıntıyı gözden kaçırıyor.
EIP-7702 Type-4 işlemlerinde iki farklı nonce alanı bulunur:
transaction.nonce: İşlemi blockchain'e gönderen hesabın nonce'u.
authorization.nonce: Yetkilendirmeyi imzalayan EOA'nın nonce'u.
Buradaki kritik ayrım, iki alanın farklı hesaplara ait olabilmesidir. Ancak authorization nonce'unun bağımsız bir sayacı yoktur; EOA'nın normal account nonce'u kullanılır.
Hacker yüksek bir fee tutarı ile tek nonce ile işlem gönderip bunun işleme alınacağını garanti edebilirdi ki bunun tek istisnası Binance ın mempool u izleyen karşı botları varsa bu ihtimal patlar. Hacker da zaten bu ihtimal nedeniyle 50 nonce ile işlem gönderdi. Ama Binance ın hiçbir güvenlik botu bu konuda olmadığıda anlaşıldı (Şayet olsaydı, Etherscan Authorization kısmında karşılıklı nonce çarpışmalarını göreceğimiz fail nonce işlemleri mutlaka olurdu )
Asıl dikkat çekmek istediğim konu ise MEMPOOL SECURITY.
Mempool'da saldırı ve savunma botlarıyla yarışanlar bu mekanizmanın neden önemli olduğunu bilir.
Bir güvenlik botunun, zararlı EIP-7702 yetkilendirmesini pending aşamasında tespit ettiğini düşünün.
Savunma botu koruyucu işlemlerle Binance cüzdanının nonce'unu artırıp saldırganın imzasını geçersiz kılmaya çalışabilir.
Peki saldırgan yalnızca tek nonce yerine 50 ardışık nonce için önceden imza hazırlamışsa?
Savunma botu nonce'u artırsa bile saldırganın elinde yeni nonce'a karşılık gelen geçerli bir authorization bulunabilir ve bu tek bir tx de 50 tane rezerve edildiği için savunma botları çaresiz kalır
Yani 50 nonce'luk bu yöntem, yalnızca yoğun işlem trafiğinden kaynaklanan nonce belirsizliğini yönetmez. Aynı zamanda nonce artırmaya dayalı mempool savunmalarına karşı dayanıklılık sağlar.
Üstelik authorization'ların azalan nonce sırasıyla yerleştirilmesi de önemli. Böylece listedeki yalnızca mevcut nonce ile eşleşen yetkilendirme uygulanır.
İşte çoğu analizin yeterince üzerinde durmadığı teknik detay bu.
Elbette bu mekanizma, saldırganın özellikle güvenlik botlarını hedeflediğini tek başına kanıtlamıyor. Ancak botlarla yaşanabilecek bir nonce yarışına karşı sağladığı avantaj çok açık.
Bu yukarıdaki teknik detaylarda AI ler şuan eksik bilgi veriyor ve güvenlik politikaları nedeniyle zaten sohbeti biryerde kesiyorlar
Peki Binance'ın güvenlik sistemi?
Zararlı delegation blockchain'e yazıldıktan sonra fonların boşaltılmasına kadar yaklaşık 17 Ethereum slotu geçti.
Burada artık EIP-7702'den ziyade Binance'ın gerçek zamanlı güvenlik altyapısını sorgulamak gerekiyor.
Binance'ın sıcak cüzdanları için Type-4 transaction izleme, yetkisiz delegation tespiti ve otomatik emergency revocation mekanizmalarının olmadığı anlaşılıyor (Çalışmadığı veya başarısız olduğu bir durumda yok çünkü sadece EIP-7702 ye özel bu tür önlemler çalışsaydı bunları fail olarak görebilirdik)
Sonuç olarak:
EIP-7702 bu saldırının kök nedeni değil, saldırganın kullandığı teknik araçlardan biri.
50 nonce ise sadece bir sayı dizisi değil; doğru nonce'u yakalamanın yanı sıra nonce tabanlı savunma müdahalelerine karşı da avantaj sağlayan bir strateji.
Blockchain güvenliğinde bazen farkı yaratan şey Solidity kodunu bilmek değil, mempool'da saldırganla savunma botunun nasıl yarıştığını anlamaktır.
🔗 Saldırı işlemi:
etherscan.io/tx/0x53bd38b816…
Yıllık milyarlarca dolar gelir elde ettiği tahmin edilen ve çok büyük miktarda müşteri varlığı saklayan Binance'ın, teknik siber güvenlik harcamaları, kritik cüzdan denetimleri ve araştırmacı ödüllerine ilişkin programları çok zayıf
Donald Trump, Çin teknoloji ithalatına %100 gümrük vergisi getirileceğini açıkladıktan sonra merkezi borsa @binance da neler oldu?
Ben olaya yatırım açısından değil, tamamen teknik, güvenlik ve kod mimarisi açısından bakacağım.
Kaldıraçlı vadeli işlemlerin doğası gereği sistemsel olarak hataya, manipülasyona ve otomatik tasfiye zincirlerine açık olduğunu unutmamalıyız; bu yüzden vadeli ve kaldıraçlı işlemlerin kesinlikle kullanılmaması gerektiğine inanıyorum.Üstelik bu sadece bir görüş değil, bu sistemlerin kod denetimini bizzat yaptığım için, yapısal riskleri ve güvenlik açıklarını doğrudan gözlemledim.
Şimdi gelelim detaylara;
Kriz sırasında özellikle üç varlık, aynı anda Binance üzerinde anormal şekilde çakıldı:
▶️USDe: $1.00 → $0.6567
▶️wBETH: $3,813 → $430
▶️BNSOL: $200 → $34.9
Diğer borsalarda bu varlıklar neredeyse sabit kaldı.
Bu, klasik panikten çok Binance e özel bir çöküşün göstergesi.
wBETH %89, BNSOL %82 düştü; emir defterlerinde alıcı kalmadı.Bu andan itibaren marjin sistemleri “teminat değerini yanlış ölçmeye” başladı.
Binance’in algoritmaları fiyatı temel değer sanınca tasfiyeler zincirleme hale geldi.
Stake edilmiş token’ları temsil eden wrapped varlıklar (ör. wBETH) çökmeye başladı.
Normalde ETH’ye eşit değerde olan wBETH, 3.800 $ → 430 $ düştü.
Temel değer değişmedi , sadece teklif kalmamıştı.
Binance’in marjin algoritması, fiyatı “gerçek değer” sandı ve milyonlarca dolarlık zorunlu tasfiye tetikledi.
Kısa süre içinde toplam tasfiye hacmi 10 milyar $’ı aştı.
Market maker’lar tamamen çekildi, Binance fiyatları diğer borsalardan koptu.
Likidite sağlayıcılar, Binance erişimi koptuğu için pozisyon koruyamadı.Kimse fiyat göremiyor, teklif veremiyordu.
Bu da “likidite boşluğu” yarattı fiyatı kurtarabilecek aktörler sahadan çekildi. Her sistem, koruma mekanizmasının silaha dönüştüğü noktaya geldi ve tek tek tasviyeleri getirdi.
Binance deki krizin teme nedeni: Spot fiyata göre işlem yapmasıydı. Spot fiyat yerine temel (underlying) oranına göre fiyatlama yapılmalıydı. Ama tek neden bu görünmüyor
Binance ın hataları büyük tutarların kaybedilmesi ile sonuçlandı, bu hatalar nelerdi?
1️⃣ Fiyatlama Mekanizması Hatası “Mark-to-Spot”
Binance, wrapped token’lar (örneğin wBETH, BNSOL) gibi türev varlıkların değerini spot fiyatına göre belirliyordu.
Yani: “Bir wBETH’in değeri = wBETH/USDT emir defterindeki son fiyat.”
Normalde bu normal de doğru bir politika ta ki likidite çökene kadar.
O gece wBETH’in spot fiyatı 430 $’a düştüğünde,
Binance bunu “teminat değeri 430 $” olarak gördü.
Bu hatalıydı çünkü: wBETH aslında 1:1 oranla ETH’ye bağlıydı (yaklaşık 3.800 $ değerinde).
Ama Binance sistemi “fiyat = değer” varsayımıyla teminatları %90 eksik hesapladı.
2022 deki FTX krizinde de aynı fiyatlama mekanizması sorunu olmuştu, Binance tarihten de ders almamış,
2022 de Binance’in 430 $ wBETH vakası gibi,
FTX de FTT’nin 22$ → 2$ çöküşünde tüm teminat zincirini yok etti.
Ders:“Teminat olarak kullandığın şeyin fiyatını sen belirliyorsan, o teminat değildir.”
2️⃣ Zayıf Emir Defteri ve Likidite Konsantrasyonu
Binance, bazı paritelerde (özellikle wBETH/USDT, BNSOL/USDT) tek likidite sağlayıcılara bağımlıydı.
O gece:Birkaç büyük market maker çekildiğinde,
Emir defteri “boşaldı” , yani fiyatı dengeleyecek alıcı kalmadı.
Sonuç:%80–90’lık fiyat düşüşleri oluştu; ama bu, piyasa değeri çöküşü değil likidite boşluğu idi.
Binance’in “Market Depth Safeguard” mekanizması (derinlik kontrolü) devreye girmedi.
Diğer borsalarda fiyatlar sabit kalırken Binance’te çöküş sürüyordu.
Binance 2021 de tamda bu sorunu yaşamıştı ( “BNB/USDT Mayıs 2021 Mini Crash" Olayı) ancak ders almamış
Olay:BNB 680$’dan 220$’a saniyeler içinde düştü.
Sebep: tek bir büyük market maker’ın (Jump veya Wintermute olduğu tahmin ediliyor) API bağlantısını kaybetmesi.Sonuç:Diğer borsalarda BNB 450–480$ aralığında kaldı.Binance’te emir defteri 100ms boyunca “boş” kaldı.Bu süre, yüksek frekanslı sistemler için bir “karadelik” etkisi yarattı.
3️⃣ Marjin Sisteminin Körlüğü — “Teminat = Fiyat” Varsayımı
Binance’in marjin algoritması “fiyatla değeri” eş tuttu.
Bir varlık anlık olarak düşerse, sistem anında kullanıcıyı tasfiye eder. Hiçbir gecikme toleransı (latency buffer) veya fair-value oracle yoktu.
Sonuç:USDe’nin spot fiyatı $0.65’e inince, marjin sistemi bunu gerçek değer sandı ve USDe teminatlı binlerce pozisyonu tasfiye etti. Oysa protokolün kendi verisine göre USDe hâlâ 1$ değerindeydi.
Binance’in hata payı yoktu; algoritmalar körü körüne emir uyguladı. Çünkü binance hiçbir şekilde riski kendisi almayacak şekilde sistemini tasarladığı görünüyor, tüm olası riskleri kullanıcıların üzerinde olacak şekilde sistem tasarımı dikkat çekiyor
4️⃣ Koruma Mekanizması Eksikliği — “Circuit Breaker” Yokluğu
Geleneksel borsalarda büyük fiyat anomalileri yaşandığında devre kesiciler (circuit breakers) çalışır.
Binance’te böyle bir mekanizma yok olduğunu anladık
Yani fiyat 3.800 $ → 430 $ olduğunda sistem hiçbir frene basmadı.
Sonuç:Tasfiye motoru, order book boşken bile emir gönderdi.
Bu, “tasfiye satışı → fiyat düşüşü → yeni tasfiye” döngüsünü oluşturdu.
5️⃣ Önceden Bilinen Açık Pencereyi Kapatmamak
Binance, 6 Ekim’de bu üç varlık için fiyatlama mekanizmasını değiştireceğini duyurmuştu.
Yeni sistem 14 Ekim’de yürürlüğe girecekti.
Yani 8 günlük bir “zafiyet penceresi” oluştu.
Saldırı (veya manipülasyon) 10–11 Ekim gecesi, bu pencerenin tam ortasında gerçekleşti.
Sonuç: Bu bilgi herkese açıktı → potansiyel manipülatörler,hangi paritelerin zayıf olduğunu biliyordu.
Binance “önceden duyurduğu zayıflığı” güvenlik önlemi almadan açıkta bıraktı.
6️⃣ Market Maker Koordinasyonu Eksikliği
Binance’in market maker’ları, sistem çökünce
API’lere bağlanamadı, veri akışı koptu.
Sonuç ; Likidite bir anda kayboldu. Binance’teki fiyatlar diğer borsalardan tamamen koptu
7️⃣ Risk Yönetimi Eksikliği (Insurance Fund + Hedging)
Binance’in Insurance Fund sistemi tasfiyelerdeki zararı dengelemek için var Ancak bu olayda fon devreye girse bile zararı zamanında absorbe edemedi ve piyasa düşüşü sırasında hedge mekanizmaları yetersiz kaldı.
Sonuç: Fonların büyük kısmı tasfiye dalgası geçtikten sonra aktive oldu çok geçti.
Özetlersek;
Birçok blockchain mühendisinin tahminlerine göre; İdeal tasarımlarla yaklaşık 5–8 milyar USD kadar tasfiye engellenebilirdi diyebiliriz, buda olaydaki toplam zararların %25–40 arasına denk geliyor
Merkeziyetsiz borsaların @Uniswap , @aave vb sistemleri çok iyi çalıştığı bir krizde , merkezi bir borsanın patlamasıda tesadüf değildi
Böyle bir borsa, bir borsa değil; kendi varlığını korumak üzere inşa edilmiş dev bir makinedir aslında, kodları kullanıcıyı değil sistemi kurtarır, hataları telafi etmez çünkü onları “piyasa davranışı” olarak tanımlar, ve her çöküşte insanların kayıplarını platformun istikrar fonuna dönüştürerek kendi sürdürülebilirliğini besler.
Yıllık geliri 10-15 milyar USD olan Binance , o gece sadece likiditeyi değil, güveni de kaybetti.
Hacker neden klasik fon transferi yerine EIP7702 ile transfer yaptı?
Öncelikle ; Hack in EIP7702 Ile bir ilişkisi yok, 7702 sadece fonların dışarı cikarilma yöntemi olarak kullanılması
Bence saldırgan şu güvenlik boşluğundan faydalanmış olabilir:
Binance klasik ETH transfer, ERC20 transfer ve yüksek tutarlı çıkışları izliyor olabilir ki yüksek olasılıkla
Ancak bir EOA'nın 0xef0100 + delegateAddress koduyla başka kontrata yönlendirilmesi için aynı düzeyde otomatik müdahale bulunmuyor olabilir , bu yokmuş anlamış olduk .
Saldırgan doğrudan para transferi yerine önce delegation kurarak klasik transfer kontrollerinin dışında bir yol oluşturmuş.
🚨 Binance Hack: 3 Dakika 24 Saniye Boyunca Güvenlik Nerede?
Binance saldırısında dikkat çekici bir teknik güvenlik zaafiyeti var.
Saldırgan, 50 farklı nonce içeren EIP-7702 authorization işlemi göndererek Binance'ın sıcak cüzdanını zararlı bir akıllı kontrata yönlendirdi.
50 yetkilendirmeden yalnızca biri geçerli oldu.
Ancak asıl skandal bundan sonra başlıyor.
Saldırgan, yetkilendirmeden tam 3 dakika 24 saniye sonra ayrı bir "sweep()" işlemiyle cüzdanın varlıklarını boşalttı.
Bu süre yaklaşık 17 Ethereum slotuna karşılık geliyor.
Peki Binance'ın gerçek zamanlı güvenlik botları neredeydi?
EIP-7702'de yetkilendirmeler nonce kontrolünden geçer. Güvenlik botu cüzdanın nonce'unu değiştirebilseydi, saldırganın bazı imzaları geçersiz kalabilirdi.
Fakat mevcut on-chain analizlerde saldırıyı engelleyen etkili bir karşı müdahale görülmüyor.Olsaydı fail nonce olarak authorization liste görülürdü, oysa hacker adresi dışında fail nonce authorization liste yok
Binance gibi dünyanın en büyük borsalarından birinin sıcak cüzdanında, zararlı bir delegation'ın 3 dakika boyunca aktif kalması ve ardından fonların boşaltılabilmesi ciddi bir güvenlik başarısızlığıdır.
Bir saldırıyı tespit etmek başka, otomatik olarak durdurabilmek başka.
Buradaki temel soru şu:
Binance'ın EIP-7702 delegation değişikliklerini izleyen ve gerektiğinde anında müdahale eden etkin bir koruma mekanizması neden devreye girmedi?
🔗 Authorization TX:
etherscan.io/tx/0xad99264d55…
Binance hem cüzdan güvenligi hemde diğer konularda güvenlik mekanizmalarına ciddi yatırım yapmalı
Geçmişte de farklı kısımlarda güvenlikte sınıfta kalmıştı
teapawt.org/0xSmartContract/status…
🚨 Binance Hack: 3 Dakika 24 Saniye Boyunca Güvenlik Nerede?
Binance saldırısında dikkat çekici bir teknik güvenlik zaafiyeti var.
Saldırgan, 50 farklı nonce içeren EIP-7702 authorization işlemi göndererek Binance'ın sıcak cüzdanını zararlı bir akıllı kontrata yönlendirdi.
50 yetkilendirmeden yalnızca biri geçerli oldu.
Ancak asıl skandal bundan sonra başlıyor.
Saldırgan, yetkilendirmeden tam 3 dakika 24 saniye sonra ayrı bir "sweep()" işlemiyle cüzdanın varlıklarını boşalttı.
Bu süre yaklaşık 17 Ethereum slotuna karşılık geliyor.
Peki Binance'ın gerçek zamanlı güvenlik botları neredeydi?
EIP-7702'de yetkilendirmeler nonce kontrolünden geçer. Güvenlik botu cüzdanın nonce'unu değiştirebilseydi, saldırganın bazı imzaları geçersiz kalabilirdi.
Fakat mevcut on-chain analizlerde saldırıyı engelleyen etkili bir karşı müdahale görülmüyor.Olsaydı fail nonce olarak authorization liste görülürdü, oysa hacker adresi dışında fail nonce authorization liste yok
Binance gibi dünyanın en büyük borsalarından birinin sıcak cüzdanında, zararlı bir delegation'ın 3 dakika boyunca aktif kalması ve ardından fonların boşaltılabilmesi ciddi bir güvenlik başarısızlığıdır.
Bir saldırıyı tespit etmek başka, otomatik olarak durdurabilmek başka.
Buradaki temel soru şu:
Binance'ın EIP-7702 delegation değişikliklerini izleyen ve gerektiğinde anında müdahale eden etkin bir koruma mekanizması neden devreye girmedi?
🔗 Authorization TX:
etherscan.io/tx/0xad99264d55…
🚨 Binance Hack: 3 Dakika 24 Saniye Boyunca Güvenlik Nerede?
Binance saldırısında dikkat çekici bir teknik güvenlik zaafiyeti var.
Saldırgan, 50 farklı nonce içeren EIP-7702 authorization işlemi göndererek Binance'ın sıcak cüzdanını zararlı bir akıllı kontrata yönlendirdi.
50 yetkilendirmeden yalnızca biri geçerli oldu.
Ancak asıl skandal bundan sonra başlıyor.
Saldırgan, yetkilendirmeden tam 3 dakika 24 saniye sonra ayrı bir "sweep()" işlemiyle cüzdanın varlıklarını boşalttı.
Bu süre yaklaşık 17 Ethereum slotuna karşılık geliyor.
Peki Binance'ın gerçek zamanlı güvenlik botları neredeydi?
EIP-7702'de yetkilendirmeler nonce kontrolünden geçer. Güvenlik botu cüzdanın nonce'unu değiştirebilseydi, saldırganın bazı imzaları geçersiz kalabilirdi.
Fakat mevcut on-chain analizlerde saldırıyı engelleyen etkili bir karşı müdahale görülmüyor.Olsaydı fail nonce olarak authorization liste görülürdü, oysa hacker adresi dışında fail nonce authorization liste yok
Binance gibi dünyanın en büyük borsalarından birinin sıcak cüzdanında, zararlı bir delegation'ın 3 dakika boyunca aktif kalması ve ardından fonların boşaltılabilmesi ciddi bir güvenlik başarısızlığıdır.
Bir saldırıyı tespit etmek başka, otomatik olarak durdurabilmek başka.
Buradaki temel soru şu:
Binance'ın EIP-7702 delegation değişikliklerini izleyen ve gerektiğinde anında müdahale eden etkin bir koruma mekanizması neden devreye girmedi?
🔗 Authorization TX:
etherscan.io/tx/0xad99264d55…
🔍 @binance Hack: Hacker Neden 50 Farklı EIP-7702 Nonce'u Kullandı?
Binance saldırısındaki en ilginç teknik detaylardan biri, hacker'ın tek bir işlemde 50 farklı EIP-7702 yetkilendirmesi kullanmasıydı.
Önce EIP-7702 nedir?
Ethereum'da normal bir cüzdanın (EOA), başka bir akıllı kontratın kodunu kendi hesabı üzerinden çalıştırmasını sağlayan yetkilendirme mekanizmasıdır.
Nonce nedir?
Her hesabın işlemlerini sıralayan bir sayaçtır. EIP-7702 yetkilendirmesinin geçerli olabilmesi için imzalanan nonce'un hesabın güncel nonce değeriyle eşleşmesi gerekir.
Peki hacker neden 50 farklı nonce kullandı?
Burada dikkat çekici bir olasılık var: Binance'ın olası karşı güvenlik botlarını (defender bots) aşmak.
Normalde bir güvenlik botu, mempool'da zararlı bir EIP-7702 yetkilendirmesini tespit ederek hacker'dan önce koruyucu bir işlem gönderebilir.
Bu işlem cüzdanın nonce'unu artırırsa hacker'ın tek nonce'a bağlı yetkilendirmesi geçersiz kalabilir.
Hacker ise 50 ardışık nonce'a sahip yetkilendirmeyi tek bir işlemde göndererek bu riske karşı önlem almış olabilir.
Ancak asıl dikkat çekici nokta şu:
On-chain işlem kayıtlarında Binance tarafından gönderilmiş herhangi bir karşı güvenlik işlemi veya nonce müdahalesi görülmüyor.Şayet olsaydı karşı saldırıyı fail nonce ile teyit edebiliyoruz, birçok cüzdan kurtarmada hackerlar da bununla karşılaştım
Yani saldırı sırasında Binance'ın cüzdanı koruyacak etkin bir karşı bot müdahalesi bulunmuyordu.
Bu, dünyanın en büyük kripto borsalarından Binance için son derece ciddi bir güvenlik eksikliğidir.
Sonuç: Hacker, 50 nonce ile olası bir savunma yarışına hazırlanmış olabilir. Ancak görünen işlem akışında Binance tarafından herhangi bir karşı müdahale gerçekleşmedi.
Milyarlarca dolarlık varlık yöneten bir sıcak cüzdanda EIP-7702 yetkilendirmelerinin gerçek zamanlı tespit edilip engellenememesi, başlı başına sorgulanması gereken büyük bir güvenlik zaafiyetidir.
Bu güvenlik sorunlarının çözümü çok basit : "Hacker gibi düşünmek "
İyi okul mezunu mühendisler yerine hacker gibi düşünenler ancak güvenlik sorunlarında hackerların önünde olabilir
🔍 @binance Hack: Hacker Neden 50 Farklı EIP-7702 Nonce'u Kullandı?
Binance saldırısındaki en ilginç teknik detaylardan biri, hacker'ın tek bir işlemde 50 farklı EIP-7702 yetkilendirmesi kullanmasıydı.
Önce EIP-7702 nedir?
Ethereum'da normal bir cüzdanın (EOA), başka bir akıllı kontratın kodunu kendi hesabı üzerinden çalıştırmasını sağlayan yetkilendirme mekanizmasıdır.
Nonce nedir?
Her hesabın işlemlerini sıralayan bir sayaçtır. EIP-7702 yetkilendirmesinin geçerli olabilmesi için imzalanan nonce'un hesabın güncel nonce değeriyle eşleşmesi gerekir.
Peki hacker neden 50 farklı nonce kullandı?
Burada dikkat çekici bir olasılık var: Binance'ın olası karşı güvenlik botlarını (defender bots) aşmak.
Normalde bir güvenlik botu, mempool'da zararlı bir EIP-7702 yetkilendirmesini tespit ederek hacker'dan önce koruyucu bir işlem gönderebilir.
Bu işlem cüzdanın nonce'unu artırırsa hacker'ın tek nonce'a bağlı yetkilendirmesi geçersiz kalabilir.
Hacker ise 50 ardışık nonce'a sahip yetkilendirmeyi tek bir işlemde göndererek bu riske karşı önlem almış olabilir.
Ancak asıl dikkat çekici nokta şu:
On-chain işlem kayıtlarında Binance tarafından gönderilmiş herhangi bir karşı güvenlik işlemi veya nonce müdahalesi görülmüyor.Şayet olsaydı karşı saldırıyı fail nonce ile teyit edebiliyoruz, birçok cüzdan kurtarmada hackerlar da bununla karşılaştım
Yani saldırı sırasında Binance'ın cüzdanı koruyacak etkin bir karşı bot müdahalesi bulunmuyordu.
Bu, dünyanın en büyük kripto borsalarından Binance için son derece ciddi bir güvenlik eksikliğidir.
Sonuç: Hacker, 50 nonce ile olası bir savunma yarışına hazırlanmış olabilir. Ancak görünen işlem akışında Binance tarafından herhangi bir karşı müdahale gerçekleşmedi.
Milyarlarca dolarlık varlık yöneten bir sıcak cüzdanda EIP-7702 yetkilendirmelerinin gerçek zamanlı tespit edilip engellenememesi, başlı başına sorgulanması gereken büyük bir güvenlik zaafiyetidir.
Bu güvenlik sorunlarının çözümü çok basit : "Hacker gibi düşünmek "
İyi okul mezunu mühendisler yerine hacker gibi düşünenler ancak güvenlik sorunlarında hackerların önünde olabilir
Binance hack'ine dair ilginç bir not:
Hack işleminde direkt bir privatekey hırsızlığı yerine EIP7702 yetkilendirmesi ile yapıldıgı anlaşılıyor
. Yani Evm de cüzdanların daha akıllı hale gelmesi için bir yetki modelini kullanıyor
Hack işlemi sırasında 50 tane 7702 yetkilendirmesi gönderdi, her biri art arda gelen bir nonce ile.
Bunlardan sadece biri bir işlem için doğru ve geçerli nonce.
Bu sekilde 50 tane gönderme nedeni ; Güvenlik amaçlı aynı anda hackerın işlemini mempool da görüp hacker dan önce işlem yapacak güvenlik botları olabileceği için, hacker işini şansa bırakmamak için böyle bir yöntem denedi
Ancak tx kayıtlarına göre Binance ın böyle bir güvenlik karşı botu zaten yoktu, boşuna 50 tane göndermiş, burada Binance ın ilk teknik güvenlik zaafiyeti olduğunu görüyoruz
ok safe to say binance is pwned
The biggest assets were approximately:
• 1.615B USDT
• 62.6M RLUSD
• 29,934 wBETH
• 11,372 XAUt
• 6.19M UNI
• 198.4M ENA
• 7.175T PEPE
• 27.8M USD1
• 2.26M LINK
• 127,853 AAVE
about $2.5B at the explorer’s prices.
1. The attacker deployed a delegate contract, 0x63e842b0...73e9c6fAe, from the relayer at 15:59 UTC.
2. About four hours later, the relayer submitted an EIP-7702 authorization transaction
That installed the malicious 7702 delegate code on Binance 14.
3. The relayer then made a call to Binance 14, executing the delegate code, and transferring Binance 14’s ETH and token balances.
4. The calldata is labeled sweep(address, address[]). The second argument is a list of recognizable token-contract addresses plus the zero-address (eth).
5. The same relayer later used the same delegate to move 780M USDC from Binance Hot Wallet 34 into the same pool
• The relayer 0x7C... was funded by three Tornado Cash 0.1 ETH withdrawals over the prior two days.
• The same pool also received 28,005.6 ETH from Binance 16 24 seconds after the main sweep.
• The pool then forwarded 195,460 ETH to a fresh, unlabeled EOA
• That EOA has only one transaction and currently holds the 195,460 ETH.
What's a bit unclear is why the relayer was needed in the first place. If they had the private keys to the Binance wallets, they could have just sent the assets out in an atomic bundle without needing a relayer at all.
So it seems likely that they didn't have the private keys and instead just had the 7702 auth signatures, which must have been phished somehow.
I think we can go ahead and assume DPRK.
5.6 milyar Usd ile kripto tarihinin en büyük hack i gerçekleşti
Her platform hacklenebilir ancak Binance ayrı bir klasmandaydı güvenlik anlamında, bu kalede yıkıldı
BREAKING: World's largest crypto exchange Binance hacked with over $5.6 billion stolen:
• $1.45 billion $BTC
• $875 million $ETH
• $234 million $TRX
• $50 million $XAUT
• $1.57 billion $USDT
• $823 million $USDC
• $75 million $WBETH
• $88.5 million $RLUSD
+ $447.5 million additional cryptocurrencies
This is the largest hack in crypto history.
Kripto borsası Bybit'in 1.5 Milyar USD lik soygunu 21 Şubat 2025 tarihinde kripto tarihinin en büyük saldırılarından biriydi
401.347 ETH + stETH/cmETH/mETH = 1,46 milyar $ tek soğuk cüzdandan çekildi. Bybit’in kendi sistemine hiç girilmedi.
Hack şu şekilde gerçekleşti ;
1 - Safe{Wallet} geliştiricisinin macOS’u ele geçirildi
2 - AWS session token’ları çalındı
3- Frontend’e zararlı JS enjekte edildi
4- İmzalayıcılar kendi donanım cüzdanlarıyla işlemleri imzalarken , normal transfer sandılar ancak imzaladıkları işlemler zararlı js enjekte edilmiş bir frontend e sahip siteydi
Normal finansal piyasalarda sadece halkın güvenini kullanarak milyarlarca usd çalınabiliyorken , kripto da bu iş bu kadar basit değil 🫡
Saldırganlar tüm saldırı ve paraları aklama sürecinde kendilerini nasıl gizledi?
VPN ve Kali Linux kullanımı : AWS erişimleri ExpressVPN IP’leri + Kali Linux ile yapıldı.
ExpressVPN: ExpressVPN’in büyük sunucu ağı, TrustedServer mimarisi ve iddia edilen no-logs politikası var. Çıkış IP’leri genellikle residential veya daha az “VPN” damgalı olabiliyor, bu da AWS gibi servislerde anomali alarmlarını azaltıyor.
Saldırgan grup olan Kuzey Koreli Lazarus daha çok "Astrill VPN" yoğun kullanılıyor.
Devlet destekli olmayan basit saldırgan gruplar kriptoda genelde "Tor Exit Node" kullanıyor
Kali Linux : Bu linux offensive security / pentest için hazırlanmış Debian tabanlı bir dağıtım. AWS CLI, Boto3, Metasploit, çeşitli exploit araçları ön yüklü geliyor. Saldırganlar ve pentest yapan güvenlikçiler genellikle Kali’den çalışıyor çünkü araç seti hazır. Bybit olayında AWS erişim loglarında "distrib#kali.2024" etiketi görülüyor ki buda Kali linux un kullanıldığını kanıtlıyor
"Poseidon Agent "kullanımı : Hackerlar, gizlice girdikleri Bybit yetkilisinin macOS unda işlemler yapabilmek ve uzaktan yönetebilmek için Poseidon agent’ı (Golang tabanlı) kullandılar
Neden: Geliştiricinin ele geçirilmiş laptop’ında kalıcı erişim, credential çalma ve komut çalıştırma için. Poseidon özellikle macOS’ta gizlilik ve post-exploitation yetenekleri sunuyor. Mandiant ve Elastic raporlarında grubun Mythic Poseidon kullandığı açıkça belirtiliyor.
Önceki operasyonlarda da benzer yöntemi tercih ediyorlardı.
Ne yaptılar: AWS session token’larını, browser cookie’lerini ve diğer credential’ları çaldılar. Bash history temizleme ve malware silme işlemlerini de buradan yönettiler.
"THORChain "kullanımı : ThorChain Cross-chain swap protokolü. ETH → BTC veya BTC -> ETH dönüşümlerini yapabileceğiniz bir köprü. Saldırganlar çaldıkları ETH’yi THORChain üzerinden BTC’ye çevirdiler.Bu sayede: Ethereum izi kırıldı, Bitcoin ağına geçildi,
Neden: Tornado Cash yaptırımlarından sonra Lazarus’un tercih ettiği ana köprü aracı haline geldi. Merkezi olmayan, hızlı ve büyük hacimli işlem yapabiliyor. On-chain izi zincir değiştirerek kırıyor.
Bybit verilerine göre %86 sı (yaklaşık 440 bin ETH) BTC’ye çevrildi. Binlerce cüzdana dağıtıldı (ortalama 1,4 BTC). THORChain node’ları bu işlemlerden milyonlarca dolar fee kazandı.
"Mikser"kullanımı : Bybit hackinde aşağıdaki mikserler kullanıldı
1- Wasabi Wallet (Bitcoin CoinJoin): Bitcoin için açık kaynaklı privacy cüzdanıdır; CoinJoin ile işlemleri karıştırır. Bybit fonlarından $247 milyon işledi, tahmini $2.5 milyon fee aldı.
2- CryptoMixer: Bitcoin tabanlı merkezi mixing servisidir; Kripto paraları havuzda karıştırıp farklı adreslere gönderir. Bybit’te ikincil kullanım gördü
3- Railgun: Ethereum ve EVM zincirlerinde zk-SNARK ile gizlilik sağlayan protokoldür. Bybit’ten ~$1.7 milyon işledi, tahmini $17 bin fee aldı
4- Tornado Cash: Ethereum’da zk ile çalışan eski mixing protokolüdür. Bybit’ten ~$2.5 milyon işledi, tahmini $25 bin fee aldı
5-Cryptomixer: Bitcoin için merkezi mixing servisidir; rastgele dağıtım yapar. Bybit’te 20 milyon usd lik işlem yaptı, tahmini $100 bin fee aldı
6- Jambler: Bitcoin tabanlı mixing servisidir. Bybit’te kullanıldı
7- eXch: KYC’siz anonim instant swap servisidir. Bybit fonlarından $94 milyon işledi, tahmini $1.4 milyon fee kazandı.
"OKX Web3 DEX Aggregator" kullanımı : Bybit CEO su Ben Zhou’ya göre Bybit’in 1,5 milyar dolarlık hack’inden yaklaşık 100 milyon dolar (40.233 ETH) OKX Web3 DEX aggregator’ünden geçti ve bu fonların önemli kısmı artık izlenemiyor.
Neden tercih edildi: Likiditeyi birçok protokole dağıttığı için rotanın tek bir DEX’te görünmesini engelliyor. OKX daha sonra aggregator’ünü kötüye kullanımı önlemek için geçici olarak durdurdu.
"Pump.fun" kullanımı : Bu, aklama sürecindeki en yaratıcı yöntemdi. Bybit fonlarıyla bağlantılı bir adres, Pump.fun üzerinde “QinShihuang” adlı bir memecoin çıkardı. @zachxbt dahil araştırmacılar, token’ı muhtemelen Lazarus adına aklama yapan bir aktörün çıkardığını belirtti. Pump.fun, token’ı frontend’inde engelledi.
Mantık şöyle işliyor: Kirli SOL ile bir token yaratılıyor. Habersiz alıcılar bu token’ı temiz SOL ile satın alıyor. Sonuçta kirli paranın değeri temiz likiditeye dönüşmüş oluyor.
"OTC ve yeraltı bankacılığı (son çıkış) kullanımı :
Zincir üzerindeki her aşamanın sonunda paranın gerçek dünyaya, yani nakde çıkması gerekiyor.
@zachxbt’nin Ekim 2026'da açıkladığı sızma operasyonu, bu son aşamayı gün yüzüne çıkardı. Fonlar USDT-Tron’a çevriliyor, ardından Hong Kong ve Çin merkezli OTC ağları üzerinden nakde dönüştürülüyordu.
OTC (Over-the-Counter), “tezgâh üstü” ya da borsa dışı işlem demek. Alıcı ile satıcı açık bir borsanın emir defterini kullanmadan, doğrudan ya da bir aracı üzerinden anlaşıp alım satım yapar. Yaniborsa dışında, kimlik sormadan kriptoyu nakde ya da banka transferine çeviren kayıt dışı aracılar bunlar
📍Bugün Neredeyiz?
Aradan yaklaşık 20 ay geçti. Bybit’in açıklamasına göre:
▶️ 48,4 milyon dolar geri alındı.
▶️30,5 milyon dolar 28'den fazla borsa ve saklayıcıda donduruldu.
▶️Bu ikisi toplamda çalınan miktarın yalnızca yaklaşık %5'i ediyor.
