Bankacılık
Lurk bankacılık Truva Atı’nın yaratıcılarının yargılanmasında nihayet sona gelindi. Grup, çok sayıda yetkilinin ve uzmanlarımızın yardımıyla eşi benzeri görülmemiş bir ortak operasyon sonucunda durduruldu. Suçlular 2016 yılında tutuklandı ancak soruşturma ve dava beş yıl daha sürdü. Bu süre, daha önce hiç karşılaşılmayan sayıda şüpheli ve mağdur olduğu düşünüldüğünde pek de şaşırtıcı değil. Lurk grubu üyeleri o kadar çoktu ki otobüs ile mahkemeye götürülmek zorunda kaldılar. Ve dava dosyası 4000 cildi (bir cilt = 250 sayfa) buldu. İş miktarı muazzam ve zaman alıcıydı, şüphelilerle ilgili her kayıt ve ifade en ince ayrıntısına kadar incelendi ancak 2018’de 27 sanık yargılandı.
Kaspersky, grubun faaliyetlerini 2011’den beri izliyor. Lurk’u ilk kez 2013’te şirkete katıldığımda duydum. Kendi kendime şöyle düşündüğümü hatırlıyorum: “Onları yakalarsan kolayca emekli olabilirsin. Kariyerinin tamamlanmış olduğunu düşün.” Zamanın olağan siber suçlularıyla karşılaştırıldığında, hem teknik hem de organizasyonel olarak gerçekten karmaşık görünüyorlardı. Bununla birlikte, bugün Lurk ile karşılaşsaydım, muhtemelen daha az etkilenirdim ve onları en iyi uygulamaları takip eden bir grup olarak görürdüm.
Mahkeme kararı, geriye dönüp grubun siber suç faaliyetlerinde neyin bu kadar özel olduğuna bakmak için iyi bir neden.
Kötü amaçlı yazılım bulaştırma yöntemi
Konuya kötü amaçlı yazılımı bulaştıran saldırı vektörüyle başlamalıyız. Saldırganlar, birkaç iş medyası internet sitesine güvenlik açığından faydalanma kitine yönlendirme göndererek bir watering-hole taktiği kullandılar. Yöntemin kendisi yeni değildi ancak bu olayda, yazılımın bulaşması için kurban (her zaman bir muhasebeci), öğle yemeği molası sırasında (ve sadece o anda) siteyi ziyaret etmek zorundaydı. Güvenlik açığından yararlanma kiti, bilgisayara yalnızca casusluk için kullanılan bedensiz bir Truva atı indiriyordu.
Siber suçlular önce makinede hangi programların çalıştığını, bankacılık yazılımı veya herhangi bir araştırma yazılımı izi olup olmadığını ve makinenin hangi alt ağlarda çalıştığını inceliyorlardı (öncelikli odak noktası bankacılık ve devlet ağlarıydı). Başka bir deyişle, bilgisayarın “ilgi çekiciliğini” değerlendiriyor ve kötü amaçlı yazılımı kime bulaştırmak istediklerini tam olarak biliyorlardı.
Ana kötü amaçlı yazılım, yalnızca bilgisayar gerçekten ilgi çekiciyse bulaştırılıyordu. Aksi takdirde, her ihtimale karşı ele geçirebilecekleri tüm şifreleri çalar ve kötü amaçlı yazılımı kurbanın makinesinden kaldırırlardı.
Komuta ve Kontrol Merkezi (C&C) ile iletişim
Truva atı ile komuta ve kontrol (C&C) sunucusu arasındaki bilgi alışverişi süreci de oldukça ilgi çekiciydi. Zamanın Truva atlarının çoğu, sabit kodlanmış C&C adresini içeriyordu. Yazılımı yazan kişiler basit bir alan adı belirlemişler ve gerekirse sunucunun IP adresini değiştirme seçeneğini kendilerine bırakıyorlardı: Yani, ana C&C adresi üzerindeki kontrolü kaybederlerse, yedek bir C&C ile değiştirebilme imkanına sahiplerdi. Bunların hepsi, oldukça ilkel bir güvenlik mekanizmasından ibaretti. Lurk bu konuda oldukça farklıydı: Grup bir casus romanına yakışır bir yöntem kullandı.
Bir iletişim oturumundan önce Lurk, C&C sunucusunun adresini hesaplıyordu. Siber suçlular Yahoo’ya gidiyor ve belirli bir şirketin hisse fiyatına bakıyordu (araştırmamız sırasında bu McDonald’s’tı). Hisse senedinin belirli bir zamandaki değerine bağlı olarak, bir alan adı oluşturup, ona erişim sağladılar. Yani siber suçlular Truva atını kontrol etmek için o andaki hisse fiyatına baktı ve bu rakamlara göre bir alan adı kaydettiler. Başka bir deyişle, C&C sunucusu için hangi alan adının kullanılacağını önceden bilmek imkansızdı.
Bu, şu soruyu gündeme getiriyor: Algoritma Truva Atı’na gömülüyse, bir araştırmacının böyle bir dizi oluşturmasını, siber suçlulardan önce bir alan adı kaydetmesini ve Truva Atı’nın bu alan adına bağlanmasını beklemesini engelleyen neydi? Ne yazık ki, Lurk’un yaratıcıları bu konuda önlem almıştı. Bunun için asimetrik kriptografi kullandılar. Yani bir anahtar çifti oluşturuldu, bunun üzerine C&C sunucusuna erişen bot, gerçekten sahibine ait olup olmadığını kontrol etmek için (dijital imzayı doğrulayarak) ortak anahtarı kullanıyordu. Gizli anahtar bilinmeden bunu yapmak imkansızdır. Bu nedenle, yalnızca gizli anahtarın sahibi botlardan istek alabilir ve komut verebilir; dışarıdan hiçbir araştırmacı C&C sunucusunu taklit edemez. O zamanlar diğer siber suçlular bu koruma yöntemini kullanmıyordu, dolayısıyla sunucuda bir özel anahtar koruması tespit edersek, bunun bir Lurk saldırısı olduğundan emin olabiliriz.
Organize altyapı
Lurk’un süreçlerini oluşturmasından ayrıca bahsetmek gerekiyor. O zamanlarda diğer siber suç grupları rastgele bir grup forum kullanıcısıysa (biri programlamayı yapıyor, diğeri parayı dağıtıyor, üçüncüsü de koordinatör olarak görev alıyordu), Lurk bu yapının tam tersine, neredeyse tam kapsamlı bir BT şirketi gibiydi. Grubu, başka bir siber suçlu grubuyla kıyaslamak yerine büyük bir yazılım şirketiyle karşılaştırmak daha doğru olur. Dahası, örgütsel düzeyde kurdukları yapı, bugüne kadar birçok grup için bir model olmaya devam ediyor.
Lurk, yöneticileri ve İK personeli ile son derece organize bir altyapı oluşturan gerçek profesyoneller (büyük olasılıkla güçlü geliştirme deneyimine sahip) tarafından yönetiliyordu. Çoğu suç çetesinin aksine, çalışanlarına gelirden pay vermek yerine maaş ödediler. Hatta o günlerde hiç duyulmamış haftalık brifingler bile veriyorlardı. Kısacası, örnek bir canavar şirketti.
Bilgiye erişimi kısıtlamak için açıkça yapılandırılmış rol tabanlı bir sistemleri bile vardı. Tutuklandıktan sonra bazı grup üyeleri ancak patronlarının yazışmalarını okuduklarında kendilerine adil davranılmadığını anlayabildiler.
Tüm faaliyetlerini, bugün birçok BT şirketinden çok daha fazla şekilde, titizlikle belgelediler. Elbette bunun soruşturmaya büyük faydası oldu. Ve belki de sonunda onların çöküşüne yol açtı: İzlediğiniz yol ne kadar sistematik olursa, takip etmesi de o kadar kolay olur. İşte bununla ilgili bazı örnekler.
Bilgi tabanları
Lurk grubu, açıkça projelere ayrılmış ayrıntılı bir bilgi tabanı oluşturmuştu. Her projeye yalnızca belirli bir grup insan erişilebiliyordu, yani bir projedeki katılımcılar diğerinin faaliyetleri hakkında bilgi sahibi değildi. Projeler, son derece teknik olandan organizasyonel olana kadar kapsam bakımından büyük farklılıklar gösteriyordu. Ve teknik projeler de farklı seviyelere ayrılmıştı. Örneğin Truva atı geliştiricileri bilgi tabanında, antivirüslerin nasıl atlatılacağı, yazılımın nasıl test edileceği vb. gibi yalnızca ilgili konularda erişime sahipti. Ayrıca büyük şirketlerdeki gerçek güvenlik düzenlemelerine benzer şekilde operasyonel güvenlikle ilgili genel veri tabanları da vardı. Bunlar, Lurk çalışanlarının tespit edilmekten kaçınmak için iş istasyonlarını nasıl kurmaları gerektiği ve anonimleştirme araçlarının nasıl kullanılacağı hakkında bilgi sunuyordu.
Bilgiye ulaşım
Siber suçluların Lurk’un bilgi kaynağına erişmek için birkaç VPN aracılığıyla bir sunucuya bağlanması gerekiyordu. O durumda bile sadece bot yönetimine erişim sağlayabiliyorlardı. Ardından, her çalışanın kendi sertifikası ve farklı haklara sahip kendi hesabı oldu. Başka bir deyişle, uzaktan çalışma için kurulmuş düzenli bir kurumsal ağ gibiydi. Genel olarak, 2FA eksikliği olmasaydı, örnek bir şirket olarak kabul edilebilirlerdi.
Fiziksel olarak tüm sunucular farklı veri merkezlerinde ve farklı ülkelerde bulunuyordu. Bir VPN aracılığıyla sanal düzeyde bunlardan birine ulaştığınızda, sunucunun gerçek IP adresini bilmeniz mümkün değildi. Grubu bulmayı bu kadar zorlaştıran şey büyük ölçüde buydu.
Geliştirme
Lurk grubunun düzgün şekilde oluşturulan kaynak kodu havuzları, otomatikleştirilmiş yapı ve çok adımlı test prosedürleri, bir üretim sunucusu, bir test sunucusu ve bir geliştirme sunucusu bulunuyordu. Aslında ciddi bir yazılım ürünü yapıyorlardı: Trojan için ürün, test ve geliştirici versiyonu bulunuyordu.
O zamanlar tipik bir Truva atının ortalama C&C sunucusu, botlardan gelen istekleri alabiliyor, bunları bir veritabanına kaydedebiliyor ve bunları yönetmek için bir yönetici paneli sunabiliyordu. Bütün bunlar tek bir sayfada etkili bir şekilde uygulanıyordu. Lurk, yönetici panelini ve veritabanını birbirinden ayrı uygularken, botlara yanıt gönderme mekanizması bir aracı hizmet tarafından tamamen gizleniyordu.
Güvenlik açığından yararlanma kitleri
Lurk’un her biri üç farklı isme sahip üç kiti bulunuyordu: geliştiricileri tarafından yapılan bir dahili kit; müşteriler ve ortaklara yönelik bir kit; bir tane de araştırmacılara verilen kit. Mesele şu ki, Lurk’un yazarları sadece kendi geliştirdikleri yazılımları kullanmakla kalmadılar, aynı zamanda diğer siber suçlulara açıktan yararlanma kitleri de sattılar. Ayrıca, “ortakların” sürümleri farklı kodlara sahipti — bu, onları başka çok popüler bir güvenlik açığından yararlanma kiti olarak gizleme girişimiydi.
Lurk’un çöküşü
Nihayetinde, siber suçluların kullandığı hilelerin pek faydası olmadı. Grubun çoğu üyesi tutuklandı. Ancak hasar verilmişti: Uzun kariyerleri boyunca saldırganlar yaklaşık 45 milyon dolar çalmayı başardılar. Uzmanlarımız, neredeyse altı yıldır yöntemlerini inceliyorlardı (bu, tesadüfen, siber suçları yenmek için kullanmaya devam ettiğimiz değerli bir deneyim sağladı).
Bu hikayeden işleriyle ilgili ders çıkarmak isteyenlere bu gönderiyi okumalarını öneriyoruz. Ayrıca Securelist yazımızda ayrıntılı bir teknik analiz de bulunuyor.
İpuçları