SiberKapan'ın HoneypotKapan ağı, gerçek saldırı trafiğini yakalamak için birden fazla sunucuda eş zamanlı çalışan SSH honeypot sensörlerinden oluşuyor. Ağustos ayı başında yakaladığımız iki farklı örüntü, honeypot verisinin tek başına değil, birden fazla sensör arasında karşılaştırıldığında nasıl daha değerli hale geldiğini gösteren iyi bir örnek.
Örüntü 1: Artan Parola Denemeleri
195.178.110.x adresinden gelen bir saldırgan, SSH honeypot'umuza art arda dört farklı parola denemesi yaptı: 21, 321, 4321, 54321. Bu, rastgele bir deneme değil — klasik bir sözlük saldırısı deseni: her adımda bir önceki denemenin başına bir hane ekleyerek ilerleyen, IoT ve zayıf yapılandırılmış Linux cihazlarını hedefleyen botnet'lerde sıkça görülen bir teknik.
Daha ilginç olan kısım, giriş "başarılı" olduktan sonra gerçekleşti. Saldırgan, sistemin işletim sistemi ve mimarisini tespit etmek için art arda beş farklı yöntem denedi — uname komutunun birkaç varyasyonu, /proc dosya sistemi okuma, ve busybox varlığı kontrolü dahil. Bu çoklu-fallback yaklaşımı, saldırganın hedef sistemin tam olarak ne olduğunu bilmeden, olası tüm senaryolara karşı hazırlıklı bir script kullandığını gösteriyor — yani bu muhtemelen elle değil, otomatik bir botnet aracı tarafından yürütülüyor, doğru payload'u seçebilmek için önce ortamı "keşfediyor".
Örüntü 2: Çapraz Sunucu Persistence Kampanyası
Asıl dikkat çekici bulgu, iki farklı honeypot sunucumuzda (103.114.147.x ve 103.187.165.x üzerinden gelen bağlantılarda) birebir aynı komutun çalıştırıldığını görmemizdi:
cd ~; chattr -ia .ssh; lockr -ia .sshBu komut, .ssh dizinindeki immutable (değiştirilemez) bayrakları kaldırıp dizini kilitliyor — tipik bir persistence hazırlığı, saldırganın kendi SSH anahtarını sisteme yerleştirip kalıcılık sağlamaya çalıştığının işareti. Komutun kendisi kadar önemli olan, iki bağımsız kaynaktan gelen saldırıların birebir aynı komut dizisini, aynı sırayla çalıştırmasıydı. Ardından saldırganlar kendi eklediklerini varsaydıkları kimlik bilgileriyle (örneğin 345gs5...34 gibi bir parola) yeniden bağlanmayı deneyerek "kendi kendini test etti" — yani komut setinin çalışıp çalışmadığını doğrulayan bir adım.
Bu, iki saldırganın tesadüfen aynı fikri bulması değil; aynı botnet kampanyasının, aynı script'i, farklı hedeflere karşı çalıştırdığının imzası.
Neden Önemli
Tek bir sunucuda çalışan izole bir honeypot, bu tür bir korelasyonu hiçbir zaman göremez — sadece "bir saldırı oldu" der. SiberKapan'ın honeypot ağı birden fazla sunucuda eş zamanlı çalıştığı ve tüm veriler merkezi olarak tek bir platformda toplandığı için, aynı kampanyanın farklı hedeflerdeki izini yan yana koyup karşılaştırabiliyoruz.
Bu tespitler, standart bir "sahte shell" honeypot mimarisiyle (Cowrie tarzı, gerçek dosya sistemi veya komut çalıştırma erişimi olmadan) yakalandı — saldırgan komutları güvenli bir ortamda gözlemleniyor, gerçek bir sistem asla risk altına girmiyor. Yakalanan göstergeler doğrulama sürecinden geçtikten sonra SiberKapan'ın MISP feed'ine ve diğer entegrasyonlara otomatik olarak akıyor.
SiberKapan's HoneypotKapan network consists of SSH honeypot sensors running simultaneously across multiple servers to capture real attack traffic. Two patterns we caught in early August are a good example of how honeypot data becomes far more valuable when compared across sensors rather than viewed in isolation.
Pattern 1: Incrementing Password Attempts
An attacker from 195.178.110.x made four consecutive password attempts against our SSH honeypot: 21, 321, 4321, 54321. This isn't random guessing — it's a classic dictionary-attack pattern, prepending one digit to the previous attempt each time, commonly seen in botnets targeting IoT devices and poorly configured Linux systems.
The more interesting part happened after the "successful" login. The attacker ran five different fallback methods in sequence to fingerprint the system's OS and architecture — several variations of the uname command, reading from /proc, and checking for the presence of busybox. This multi-fallback approach suggests the attacker doesn't know in advance exactly what the target system is, and is running a script prepared for every possible scenario — meaning this was almost certainly executed by an automated botnet tool "reconnoitering" the environment before selecting the right payload, not a human operator.
Pattern 2: A Cross-Server Persistence Campaign
The real finding was seeing the exact same command executed on connections from two different honeypot servers (via 103.114.147.x and 103.187.165.x):
cd ~; chattr -ia .ssh; lockr -ia .sshThis command removes immutable flags from the .ssh directory and locks it — a typical persistence setup, signaling that the attacker is trying to plant their own SSH key for continued access. What matters as much as the command itself is that two independent sources ran the exact same command sequence, in the exact same order. The attackers then attempted to reconnect using credentials they assumed they'd just planted (a password resembling 345gs5...34) — effectively self-testing whether their setup worked.
This isn't two attackers coincidentally having the same idea — it's the fingerprint of a single botnet campaign running the same script against different targets.
Why This Matters
An isolated honeypot running on a single server would never see this correlation — it would only register "an attack happened." Because SiberKapan's honeypot network runs simultaneously across multiple servers with all data centralized on one platform, we can place the footprint of the same campaign against different targets side by side and compare them.
These detections were captured through a standard "fake shell" honeypot architecture (Cowrie-style, with no access to a real filesystem or command execution) — attacker commands are observed in a safe environment, and no real system is ever put at risk. Once verified, captured indicators flow automatically into SiberKapan's MISP feed and other integrations.